Live data from Hacker News

Choosing Nim out of a crowded market for systems programming languages

forum.nim-lang.org

171–180 of 271 posts

Re: Choosing Nim out of a crowded market for systems programming languages

#171
post #134

Earlier quoted context omitted.

I have mixed experiences. The evangelism on HN and reddit can be stifling. Particularly the overemphasis on "safety". The community on discord was very helpful though, when I was struggling. I feel like the community is large enough that you can find a lot of more normal people using it, and just avoid the zealots.

I don't think safety or correctness can be over-emphasized.

I'd say it definitely can, 99% of tasks in programming can be done with a garbage compiler after all.

Different conversation though.

Re: Choosing Nim out of a crowded market for systems programming languages

#172

biggest con of Nim - no one uses it, so you will probably hit a toolchain/compiler error which will be very frustrating too similar to Go to not go with the 100x community size Go brings with it

It's far more enjoyable than Go. I use Go at work, Nim at home. A smaller community, of course without Google's backing, but it is growing.

Re: Choosing Nim out of a crowded market for systems programming languages

#173

Earlier quoted context omitted.

I have mixed experiences. The evangelism on HN and reddit can be stifling. Particularly the overemphasis on "safety". The community on discord was very helpful though, when I was struggling. I feel like the community is large enough that you can find a lot of more normal people using it, and just avoid the zealots.

Yeah, the way I sometimes describe this is that Rust social media can be pretty toxic, but the actual Rust community is generally very friendly and supportive. The problem is that a lot of people confuse the two.

I should definitely say, if I'm talking about the "community," I mean real people not anonymous Twitter accounts.

Re: Choosing Nim out of a crowded market for systems programming languages

#174
post #57

Would have liked to see an opinion on the large number of memory management techniques for Nim [1]. Seven types(!) ranging from GC's to manual. Surely this makes reasoning of performance very hard. Where do you focus - your program or the memory management options. Perhaps in practice everyone has settled on one of them(?) [1] https://nim-lang.org/1.4.0/gc.html

I'm curious about this too. If Nim managed to design a system that gives you more flexibility without adding more complexity, that would be pretty stellar.

Re: Choosing Nim out of a crowded market for systems programming languages

#175
post #94
post #41

I have done non-trivial things both in Rust and Nim. For big projects Rust seems a little more robust, but for medium and small projects Nim is an order of magnitude faster to develop for. There are still many rough edges, but it's exactly the tradeoffs I would personally pick for my one person small business making tools for artists. So far I have been using Rust and it's alright, but looking very much into Nim to s…

> looking very much into Nim to see if I can replace Rust because of the high cognitive load to keep all of the Rust stuff in my head, as I don't really need safety. Personally I find that Rust has less cognitive load, because so much of what you'd generally worry about in other languages is covered by language features in Rust: static typing, algebraic data types, etc

Well, one thing that makes Rust harder is tooling. I don't seem to get around its code completion, at least in VSCode, and the docs, while mostly good, are hard to understand sometimes

I personally don't like that "structures with methods" way of doing things in Rust/Go but maybe that's just about getting accustomed

Re: Choosing Nim out of a crowded market for systems programming languages

#176
post #153

Earlier quoted context omitted.

Kind of an ironic reply - naming 10 Rust features and libraries vs. an `if` check in Go to argue that Rust has simpler ergonomics for throw-away code.

My response covered the gamut from throw away code up to error handling in professionally written code, with a diversion through "null" handling. To reiterate, for throw away code (or tests) unwrap() and panic!() will work just fine.

> code up to error handling in professionally written code

Lol, if you knew how much python code runs the world without even checking for exceptions, or with a try/except/pass ... and the world keeps on spinning.

"professionally written code" made me chuckle

Re: Choosing Nim out of a crowded market for systems programming languages

#177

> Rust: I'm not afraid to admit it - Rust is just too complicated for use as an aging and cranky solo developer. ... > As someone who actually hates to code for coding's sake and wants to Get Sh!t Done, Rust is just antithetical to my relationship with computers. I don't want to have to think about the language, and that's all Rust wants you to think about. My guess: the author hasn't even tried it other than a curso…

Most of the bugs Rust catches are memory related bugs and some data races in concurrent code. In any GC language the first is solved and there are concurrency frameworks available that prevent similar data race issues. TFA's author is comparing against Nim, a GC language. And in my experience of 10k LOC of Rust it's the same as the author's. Also does every criticism of Rust have to have a prominent rebuttal? TFA bur…

Seems like Rust is hitting peak popularity right now so there are tons of people out there feeling slightly insecure about their new language and needing to defend it every time someone picks a competitor.

Re: Choosing Nim out of a crowded market for systems programming languages

#178
post #176

Earlier quoted context omitted.

My response covered the gamut from throw away code up to error handling in professionally written code, with a diversion through "null" handling. To reiterate, for throw away code (or tests) unwrap() and panic!() will work just fine.

> code up to error handling in professionally written code Lol, if you knew how much python code runs the world without even checking for exceptions, or with a try/except/pass ... and the world keeps on spinning. "professionally written code" made me chuckle

Yeah I'm done with the trolls here.

Re: Choosing Nim out of a crowded market for systems programming languages

#179
post #56

Earlier quoted context omitted.

They sound like someone that is attracted to chasing the high of the next technology to learn rather than picking a language like C/C++ that would have worked and given them way more career stability. Rather than mastering a bunch of programming languages they should have focused on one and built clout as a problem solver that doesn’t see a new shiny tool as a way to label their career. Boring popular language + focu…

Ugh, as a C++ programmer - for the love of god don't choose the language for career stability. Both the language and the ecosystem is horrible. Choose it if you need it work in the domain of your choosing. For me it happens to be the case. If you want to choose a career language go for any of the other TIOBE usual suspects. I completely agree that if you want to be a career programmer, focus on solving problems for b…

What's wrong with C++ stability? You think things are looking better in JS/Python world? They both changed tons and the knowledge you accumulate constantly needs to be tweaked and relearned.

Re: Choosing Nim out of a crowded market for systems programming languages

#180

> I feel inferior for not being fluent in OCaml I learned OCaml recently, on my own, for myself. It’s actually a pretty easily language to use and learn, but historically there weren’t EXCELLENT resources for learning it. There are now excellent resources, predominantly: https://cs3110.github.io/textbook/cover.html When OCaml 5 settles, its general applicability will be (imho) much larger. Do I recommend it for every…

OCaml is great. One of my favorite languages. I think the only thing hard about it is the fact that it is solidly FP, and that is not a familiar paradigm to many. One of these days I want to check out F# so I can use the whole .NET set of libs as well (the only bad thing about ocaml is the small ecosystem of libs). > These jokers in this thread “oh rust isnt hard! Ohhh they probably didnt try much.” Respectfully, get…

It's not _really_ a tutorial. But it's one of the best exploration of any language I've read.

https://cglab.ca/~abeinges/blah/too-many-lists/book/README.h...

Post reply on HN