Live data from Hacker News

Choosing Nim out of a crowded market for systems programming languages

forum.nim-lang.org

161–170 of 271 posts

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

#161

> Rust: I'm not afraid to admit it - Rust is just too complicated for use as an aging and cranky solo developer. I'm nearly 51 and currently learning Rust. The first 10 hours of it were horribly slow, but it isn't as steep of a learning curve as Optimal Control Theory.

Learning curve is straight up for many with the borrow checker, but once you are over that hump, and it comes pretty quick for most, Rust is no harder than any other language.

Easier than C or C++ for sure. But I definitely wouldn't say that Rust as easy as a GC'd language like Java or Go.

They have strictly less constraints to deal with, they can let you use the simplest pattern for the situation, and (in my experience) they have less superfluous refactoring sessions due to the overly conservative nature of the borrow checker. I like how Matt Welsh put it in https://mdwdotla.medium.com/using-rust-at-a-startup-a-cautio...:

> What really bites is when you need to change the type signature of a load-bearing interface and find yourself spending hours changing every place where the type is used only to see if your initial stab at something is feasible. And then redoing all of that work when you realize you need to change it again.

Perhaps you're instead speaking of a specific situation or kind of program where the borrow checker happens to be no harder than any other language?

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

#162

I really can’t understand where this idea that rust is ‘hard’ comes from. Everything that it formalizes is something that you should already be conscious of . If not, well… you have a different, bigger problem.

That absolute claim is simply not true. That's like saying that people need to avoid shared mutability in every program, which simply doesn't make sense for a lot of programs, especially if you have a garbage collector already.

It's only a useful tool that has some nice qualities in some settings. It's not some underlying truth of the cosmos, it's just a situationally useful way to do things.

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

#163
post #60

Earlier quoted context omitted.

That's true only in comparison to languages with manual memory management. Higher level languages spare you the burden of being conscious about these things, which means Rust is naturally going to be more difficult to work with than, oh, I dunno, Ocaml. From the other direction, coming from low-level languages: the other problem is that Rust's type system isn't powerful enough to express certain things that you, a co…

Memory things, sure. There is the whole concurrency/parallelism thing, though.

Pony is a great example of fearless concurrency without the borrow checker's difficulties.

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

#164

Earlier quoted context omitted.

Can you explain to us what's the bigger problem we should be addressing according to your opinion sir?

You’re creating lots and lots of bugs that will come back to haunt to at runtime (midnight on a Friday if the universe has its way).

Single ownership often introduces bugs of its own. In Java, I never need to create an Err if the thing my ID is "pointing" to isn't around anymore in whatever hash map the borrow checker made me store it in.

It's good in some cases, bad in others.

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

#165

Earlier quoted context omitted.

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…

> Also does every criticism of Rust have to have a prominent rebuttal? Ha, sorry - I just really love Rust and want others to at least try it. I passed on it for _years_ because I thought like the OP (I used to code in Scala - I personally find THAT takes cognitive load to remember all the features. Rust feels small to me in comparison). Rust made me LOVE to code again and I just think there must be others out there…

Maybe you should try a language where people get a lot of work done in the day to day ? E.g: Python, Go...

It seems crazy to me someone who code in Scala, now loves Rust. Brains are really something else :)

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

#166

Earlier quoted context omitted.

I'm close in age to you but that was one part of the article that resonate w me. I'm often writing little scripts for my computer or things that a dozen people will use, if I'm lucky. If the program 'crashes' it barely matters. It feels like, in Rust, I have to carefully choose my data type and use the applicable methods (not always intuitive), whereas in Nim or Go, I can basically just slap something together and th…

I mean "unwrap()" and "panic!() are right there for "blow up and don't care", if you're really just doing throwaway scripting that should be enough. And the "?" operator is way more ergonomic for throwing actual errors up a level than all the boilerplate in Go. The pattern matching with `match` `if let` and `let else` are pretty easy to use to unwrap Result and Option enums. And then the "anyhow" or "thiserror" crate…

Not sure if you're being sarcastic or serious

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

#167
post #46

Earlier quoted context omitted.

The Rust community is however, an excellent community to be part of. And it's future proof. Everyone knows Rust is the future. I'd say, for most college students, Rust would be the one you'd advise today.

> The Rust community is however, an excellent community to be part of. I honestly haven't found this to be the case. There is a constant denial that some people might find Rust difficult (with a very strong implication that if they do, it's because of inferiority on their part), and extreme thin-skinnedness towards even the possibility that Rust might not be for everyone. Indeed, a bluff assertion that it is for ever…

I've experienced this as well. Any disagreement always comes down to "you just haven't used it enough". I let myself take that gaslighting for years before I decided to just not go to the Rust servers any more.

And then when you question any of the classic Rust axioms (such as safety or speed being only desirable rather than an absolute commandment) a lot of them tend to get rather hostile. It's not a pleasant crowd if you don't think 100% like they do.

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

#168

Earlier quoted context omitted.

> I have encountered many situations where perfectly reasonable, zero copy, memory management that would be completely normal, fast and safe in C So you think. It doesn't matter how smart you think you are, statistically speaking you're not smarter than a compiler.

I think you are overestimating the expressive power of lifetime annotations in rust, and how smart the borrow checker is

Anything you can express in C, you can in Rust. When it comes to pointer tricks you might have to use unsafe, but that is part of the language.

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

#169

Earlier quoted context omitted.

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…

The doubly linked list thing strikes me as more of an illustration of cultural differences between C programmers an the rest of the world than as a straightforward criticism of Rust. I've no doubt that doubly linked lists are an awkward hassle to implement in Rust. But the same is true in functional languages, and you never hear people criticizing, e.g., Haskell over this. I have a couple guesses as to why that is, b…

It's not just doubly linked lists. They're just a basic example of borrow checking not being able to handle a lot of easy patterns that are perfectly safe in other languages.

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

#170
post #153

Earlier quoted context omitted.

I mean "unwrap()" and "panic!() are right there for "blow up and don't care", if you're really just doing throwaway scripting that should be enough. And the "?" operator is way more ergonomic for throwing actual errors up a level than all the boilerplate in Go. The pattern matching with `match` `if let` and `let else` are pretty easy to use to unwrap Result and Option enums. And then the "anyhow" or "thiserror" crate…

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.

Post reply on HN