Live data from Hacker News

Choosing Nim out of a crowded market for systems programming languages

forum.nim-lang.org

141–150 of 271 posts

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

#141
post #111

Earlier quoted context omitted.

> would it really be too expensive to invest some time to learn it? I guess it depends on who you are. I find the complexity of Rust, and the community's cultural acceptance of said complexity, oozes out into every library to make every new thing you try to do seem like another incredibly hard slog. I had one try at Rust a couple of years ago, and gave up. I had another one in the first half of this year, this time i…

Thanks for sharing your experience. OP in particular seems like someone who is familiar with a variety of languages, hence my comment. In addition, given that their requirements lined up with what Rust is good at, the time investment would be worth it. When it comes to learning Rust in general, I think the difficulty and amount of time required depends on one’s background and overall learning style. If you are the ty…

> given that their requirements lined up with what Rust is good at

I would say the opposite.

OP stress on the C/C++ interoperability. In rust, you need to either

(1) wrap the API in something Rust-like / Borrowchecker-friendly - which need lots of planning ; or

(2) Do it with lots of unsafe code - which make the memory safety lots more complicated to reason about

For memory safety, you can get it from any GC language without extra mental load.

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

#142

Earlier quoted context omitted.

I have written around 30k+ lines of rust by now, and I have to agree with OP. I have encountered many situations where perfectly reasonable, zero copy, memory management that would be completely normal, fast and safe in C, it basically impossible to replicate in Rust (or at least I am not clever enough to figure it out). Are there other ways to structure the data that work in Rust? Yes, of course. Do I like them comp…

I have written about 50K LoC of Rust, so fairly similar. I will agree that I have had occasional "lost days" with some very complex spots of code that would not have been a problem in a GC language. That said, I feel like I've made up for that at least 1.5-2x by my productivity and lack of bugs in other sections. That said, I can understand how it may not be for everyone. I love it, but there are some data structures…

[deleted]

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

#143

> 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…

I have written around 30k+ lines of rust by now, and I have to agree with OP. I have encountered many situations where perfectly reasonable, zero copy, memory management that would be completely normal, fast and safe in C, it basically impossible to replicate in Rust (or at least I am not clever enough to figure it out). Are there other ways to structure the data that work in Rust? Yes, of course. Do I like them comp…

Seeing some of the hassles with creating basic stuff like a linked list is part of the reason I have yet to use it seriously. I think I will eventually, but I certainly won't act like it doesn't come with a cost or that it always pays off.

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

#144

> 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…

[deleted]

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

#145

> 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 buried it in the appendix and the article is about a lot more languages than Rust, but here we are talking about Rust again. We all have our favorites, we don't have to stick out for them everywhere. Some people don't like Rust and that's okay.

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

#146
post #111

Earlier quoted context omitted.

> would it really be too expensive to invest some time to learn it? I guess it depends on who you are. I find the complexity of Rust, and the community's cultural acceptance of said complexity, oozes out into every library to make every new thing you try to do seem like another incredibly hard slog. I had one try at Rust a couple of years ago, and gave up. I had another one in the first half of this year, this time i…

Thanks for sharing your experience. OP in particular seems like someone who is familiar with a variety of languages, hence my comment. In addition, given that their requirements lined up with what Rust is good at, the time investment would be worth it. When it comes to learning Rust in general, I think the difficulty and amount of time required depends on one’s background and overall learning style. If you are the ty…

Your response seemed to fall into a category common amongst Rust enthusiasts, which is to assume anyone resistant to the lure is ipso facto lazy or misguided. Your own question was a hint at laziness. I have no idea how much effort the writer put into evaluating Rust. I doubt you do either.

I don't know why some of us find Rust difficult. Perhaps it just is, or isn't, or is for some people and not for others, or perhaps we are just thick. My suspicion is that there are more people who do than seem apparent, because they tend to get shut down by the very decorous implications of laziness or stupidity that are so characteristic of the Rust community.

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

#147

Earlier quoted context omitted.

Oh boy, that is so not true. Anything where the boundaries of the lifetimes are easily determined at runtime but unknown at compile time is extremely easy to model safely in C, and a nightmare in Rust. At least if you want the same level of performance and a similar modeling of the data

> Anything where the boundaries of the lifetimes are easily determined at runtime but unknown at compile time is extremely easy to model safely in C, I don't even know how to respond to this seriously. I guess just imagine me pointing to every blatant instance of this not being true.

In my experience, the vast majority of examples where that fails is because of two reasons: project evolution that doesn't spend time re-evaluting memory managemnt together with the new requirements on the data, or inexperienced C coders. So that goes to my last point in my original post, yes as an industry there are use cases where rust is better because of the provably safe memory management (let's forget unsafe for the moment). But as a language you _can_ safely model those situations in C esily. The problem is that the solution is not robust to change. If you don't agree with that it will be me who doesn't know how to take what you say seriously

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

#148
post #30

> [..] I decided that I need a safe, fast, and statically typed language that can be compiled and targeted to both mobile and desktop environments, as well as being made available to scripting languages via FFI. And you eliminated Rust because.. it’s too complicated? It meets these requirements to the letter! Since this is a greenfield effort, would it really be too expensive to invest some time to learn it? Anyways,…

I am curious about the safety, though.

This minimal example causes a segfault:

    type Foo = ref object
        a: int

    var foo: Foo = nil
    echo foo.a
which wouldn't be simply possible to type in safe Rust.

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

#149

> 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.

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" crates make it all more ergonomic.

The end result is something is much more readable than all the error handling in Go, while still being at least as safe if not more safe.

Plus you wind up playing with Monads without needing to know what the hell an endofunctor is.

And there's no null/nil, while Options have to be explicit and if you squint (because of the presbyopia) they look kinda like the nillable stuff in C# 8.0

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

#150

> 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…

> 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 who would feel the same if they just tried it.

> Some people don't like Rust and that's okay.

Agreed, I'm sure it isn't for everyone.

Post reply on HN