Live data from Hacker News

Choosing Nim out of a crowded market for systems programming languages

forum.nim-lang.org

191–200 of 271 posts

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

#191

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

In my experience, it depends heavily on the kind of thing you're writing. I could write some small programs in it, no problem: a rather complex, text-based calculator was easy and elegant to write with function arguments, a game server monitor, some tools for a cryptography course, an FFT analyzer that reads from WAV or AIFF, etc. Then I tried to port my rather efficient Earley parser (https://en.wikipedia.org/wiki/Earley_parser) from C. Constructing the item set efficiently wasn't that hard, but constructing the forest (set of syntactic trees) was. In C, it was basically free by using some pointer sharing, but I couldn't get that done in Rust. Perhaps there's some clever trick I couldn't think of, but I couldn't get it anywhere near C's speed. And since the ultimate goal of that parser includes further memory shenanigans (unification of results yielded by the rules), I dropped the project.

At my job, I'm writing in Go. I fairly sure I could easily port the C code to that. It would probably run a bit slower, but the algorithm and data structures would be readable, and extendable.

So: it depends.

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

#192

Earlier quoted context omitted.

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.

The easy pattern of graph structures is handled by the easy implementation of adjacency lists, which is how you should have been implementing it in other languages too. The specific incompatibility is with the naïve hand-implementations of these structures; the specific thing Rust does not optimize for is toy code.

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

#193

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

Can we please not do this? It's fine to give a different viewpoint, but it's surprisingly common that whenever someone says anything bad about Rust, a Rust user comes in to say that they just haven't used it enough. It's like saying "If you don't like my favorite movie, you just haven't watched it enough."

> It's like saying "If you don't like my favorite movie, you just haven't watched it enough."

It took you average movie time to learn whole entirety of language? Wow!

And without sarcasm, yes, sometimes it is the case.

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

#194

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

Can we please not do this? It's fine to give a different viewpoint, but it's surprisingly common that whenever someone says anything bad about Rust, a Rust user comes in to say that they just haven't used it enough. It's like saying "If you don't like my favorite movie, you just haven't watched it enough."

It's not even the right category of criticism. The author talks about 'mathematical purity' which is something Rust sneers at. Spend just a little while with Rust and you can see that when the language is getting in your way, the driving direction it is pushing you in is towards code that will be maintainable. Which is still not about getting shit done, and is still a valid axis to prefer Go's rapid development cycle on, but if you cannot name the distinction then it is hard to believe you have spent enough time with the language to properly observe it.

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

#195

Earlier quoted context omitted.

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.

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

What’s the problem here in Rust?

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

#196
post #65

Earlier quoted context omitted.

Yeah, I wrote an equivalent service in Java and Nim, and I just couldn't get Nim to perform as well as Java, and it wasn't even easy to write. Random segfaults, depending on memory manager used, random libraries requiring different memory managers, ORC being talked about a lot despite causing random segfaults, and so on. I really want to love Nim.

Author's take on Java is really funny. "..the JVM's largesse isn't aging particularly well. It will die with my generation's retirement." I call this fundamental blindness considering the JVM is improving dramatically year after year - now even supports lightweight concurrency like Go in 2022. Java will still be alive and kicking when no one alive even remembers Nim.

Not only Java, but major JVM languages as well (Clojure, Kotlin, Scala).

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

#197

The best language to learn and use right now for systems programming is C/C++. It is by far the most marketable skill with 99.999999% of all low level systems written in C or C++. Large scale systems used by companies that pay top salaries for developers (Google/Meta) are written in C++. There is more material out there for learning and mastering these languages than any other language save maybe Python or JavaScript…

> Large scale systems used by companies that pay top salaries for developers (Google/Meta) are written in C++.

And you of course have some stats that prove C/C++ pays better at FAANG than more pleasant languages?

> There is more material out there for learning and mastering these languages

Really? C++? Maybe I’m looking at the wrong places, but outside of huge Stroustrup books, and a couple of gems like Effective C++, there’s not much high quality content out there.

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

#198

Earlier quoted context omitted.

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.

The easy pattern of graph structures is handled by the easy implementation of adjacency lists, which is how you should have been implementing it in other languages too. The specific incompatibility is with the naïve hand-implementations of these structures; the specific thing Rust does not optimize for is toy code.

You know nothing of what I'm programming. You don't know when, whether, or how my program accesses or deletes data. You don't know what domain I'm in, whether I'm on a team, or what our priorities must be.

And yet, you proclaim that your approach is how I should always do it in any language, in any situation.

It strikes me as particularly convenient, seeing as that's the only approach that the borrow checker can reason about.

To make it more concrete: if we apply your solution everywhere we run into this problem with the borrow checker, it can flatten a lot of our program's (non-temporary) state into basically relational tables. Sometimes that's okay, but for a lot of situations it can be bad for encapsulation, velocity, and modularity.

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

#199
post #183
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…

> With Rust I have no idea what to use after trying 5 different libraries. Seems like GTK is the pretty clear frontrunner? https://www.areweguiyet.com/

While GTK is a gui library, it is not a rust gui library. The GTK you link to is simply rust bindings for the GTK library.

The most popular rust gui library at the time of writing seems to be egui with 489k downloads.

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

#200

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

Your argument vs OP that tried rust, is that they should try rust until they agree with you?
Post reply on HN