Get the top HN stories in your inbox every day.
127
pitaj
> 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
moldavi
I'm sometimes a bit confused when people say that Rust has less cognitive load. I assume that's compared to something like C or C++, right?
I've used Rust and (imperative-style) Scala a lot, and I have to say, Scala is way easier since it doesn't have to deal with the borrow checker, but it still has an amazing type system.
Nim is statically typed and has algebraic data types, so I imagine it's also as easy as Scala, easier than Rust.
mumblemumble
I think that it has to be?
I like Rust well enough, but thinking about memory management is a reasonably large effort that I generally don't have to make in most languages. Rust, in not having a GC, strictly adds to that load compared to most languages out there. The exceptions are languages like C, C++, and assembler, and there I agree that Rust seems to make things a fair bit easier.
(Though, disclaimer, I never got around to learning modern C++, which I gather is a huge improvement over the style of C++ I do know.)
I'd be willing to accept, though, that Rust's lack of full-blown OO features, and its strict controls on mutation, often makes things easier in large shared codebases. Perhaps not letting people do some particularly wild things that I'm used to seeing in Java and C# at my day job. I'm not in a position to have a worthwhile opinion on that claim, though.
insanitybit
Imagine if someone said "I've used Python and Scala and Python is way easier since I don't have to deal with a type system". That's where people are coming from.
The borrow checker isn't a hindrance, it's an aid. Rust gives me syntax to describe lifetimes and a tool to check that syntax.
raverbashing
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
dilawar
I agree but I tool functional programming course in college. It was hard! Someone who may not have invested enough in leaning basics of FP, I can totally see why Rust feels like a hard language. During the prototyping phase, I also avoid lifetimes and other esoteric features and often use unhealthy amount of Arc and Rc.
Nothing beats Cargo and company and loves compiler messages. Have used NIM as python replacement, and while language is great and nim batteries are decent, the ecosystem is not there. But who would use nim as python replacement!?
sph
How would functional programming help with Rust? I am fluent in both, and having map and reduce in the Iterator trait does not make Rust anything like a functional language.
etra0
I recently tried Nim for the first time, and although is simpler, the model with values vs refs was a little more complicated than needed imo, and the 'easy C interactivity' wasn't as simple as with, let's say, Zig, where you'd simply do `@cImport`.
It's still fun though, and I appreciate the minimal visual noise while writing it.
throwup
It looks like gintro is a GTK binding - the Rust equivalent would be gtk-rs. https://www.gtk.org/docs/language-bindings/rust/
I'm curious whether you tried gtk-rs and if so what problems did you have?
culi
> With Rust I have no idea what to use after trying 5 different libraries.
Seems like GTK is the pretty clear frontrunner?
aew4ytasghe5
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.
cdaringe
> 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 everything? No. But you wont hit segfaults like you will in go, and you certainly wont wrastle the compiler like you will rust. Haskell and OCamls lack of fluent programming make them less easy to program in (read: slower iteration), if you get your design right, your final product is just a real treat :chefs_kiss:. Some newer fp langs do have fluent style syntaxes, which are
The ocaml debugging experience stinks, and the lack of builtin (de)serializers for custom/composite types is very obnoxious, to put it kindly. Still, it’s not the obscure thing everyone loves to say about it. Really, its not.
These jokers in this thread “oh rust isnt hard! Ohhh they probably didnt try much.” Respectfully, get outta here. I love rust. Taken the doubly linked list tutorial? How about needed to use anything with Pin? Rust requires a huge surface area of foundational knowledge to be productive, full stop—the author is absolutely within his right to make this very fair claim about rust being onerous, relative to his candidate pool
nu11ptr
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 outta here. I love rust. Taken the doubly linked list tutorial? How about needed to use anything with Pin? Rust requires a huge surface area of foundational knowledge to be productive, full stop—the author is absolutely within his right to make this very fair claim about rust being onerous, relative to his candidate pool
Rust is not an easy language, but I find it strange that people take the hardest parts and act like it is most of what it is about (I can count on one hand how many times I've had to directly interact with Pin). The things you mention aren't things I spend any time on, and I write Rust nearly 12 hours a day.
P.S. - Is there actually a double linked list tutorial? What an _awful_ way to learn Rust. That is like starting at the very end of what you should be learning and then working forward. No wonder it scared people away.
mumblemumble
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, but I'm guessing the main one is that Rust being touted as a C replacement results in people assuming that Rust should be amenable to the same kind of (for lack of a better way to put it) hyper-imperative approach to problem solving that C basically forces upon people.
But I'm also pretty sure that I've never, in my 30 years of programming, used a doubly linked list in anger in a language that wasn't C. (Maybe Pascal?) I have never used Rust in anger, either, but, based on my little bit of dabbling, it seems like yet another language where I would be likely to choose any number of different data structures first. I certainly wouldn't be implementing my own in any case. These days, implementing doubly linked lists from scratch seems to be very nearly the sole province of C programmers and undergraduates.
moldavi
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.
speed_spread
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...
TylerE
Ocaml is a (mostly) good to great language with horrible tooling that completely kills any desire I have to work with it.
ezquerra
I recently started using nim for some little side projects and I am having so much fun. Somehow they’ve managed to combine the strengths of high level languages such as python with those of low level, systems languages like C with few (if any) of the drawbacks. It’s pretty amazing to be honest.
Programming in nim feels a lot like programming in a statically typed Python, except that you get small, fast, single file executables out of the box.
Compared to C++ you don’t need to worry about memory allocations too much except when you really want to, and when you do it is much simpler than in C or C++. It is also much easier to control mutability and the type system is much better. Also you can use most of the language at compile time in a much more elegant way than in modern C++.
Another surprising thing is that while the ecosystem is obviously much smaller than on more popular languages, the fact that it has a built-in package manager gives you access to it much more easily than in C++. There are a lot of high quality packages (such as datamancer, arraymancer and ggplotnim) which makes nim very productive in a lot of domains.
That’s not even including advanced things such as nim’s excellent macro system which I personally don’t use (but which enable some of the best nim libraries).
Oh, and I _love_ nim’s uniform function call syntax. Every other language should copy that feature.
I almost forgot to list the drawbacks. The main one of course is that it is not the most popular language (but the ecosystem is big enough that I didn’t find it is a big problem for my use case in practice). Other than that the editing and debugging experience could be improved. There is a decent VS Code plug-in (look for the one made by “saem”) but it is just OK, not great. There is some integration with gdb but it is a bit rough. I usually end up adding logs when I need to debug something.
whage
The author seems to be very knowledgeable about the different aspects of programming. Whether you agree with his opinions or not, this article I think is a great starting point for learning about many interesting topics. Definitely bookmarked for later.
ilovecaching
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 + focusing on building stuff and solving problems are the key to actual career growth.
bitexploder
That assumes a whole lot about their goals. If everyone sticks with C++ we would never have nice things like Zig/Nim/Rust that are advancing the conversation about how we should be doing systems programming tasks with code. C++ is quite influences by a lot of this. Like, let emm hack and learn. Also I think Nim is a very productive language to be hacking in and much easier to get going with than C++.
idealmedtech
As they say, let people enjoy things
ilovecaching
That take detracts from the amazing work people have done over the decades to research and implement improvements to C and C++. We can innovate without throwing things away, even if it may seem boring to the uninitiated.
fsloth
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 business. But it can be done in any language nowadays.
weatherlite
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.
nine_k
Let's face it: C++ is pain. Even with all the improvements of the last 15 years.
Choosing something which us not C++ may be a long-term goal by itself.
mikebenfield
Have you considered there may be a reason why so many large tech companies are so eager to move away from C++?
fsociety
Perhaps they care more about exploration and learning rather than career growth and solving business problems.
dataflow
> Zig is truly compatible with C and will compile C code directly, since its compiler is actually written in C++.
I assume this was intended to say something else?
> Here's the brutal truth: I can't find anyone under the age of 41 in my field to say a single positive thing about D
IIRC the presence of the GC in D was (is?) its Achilles heel. Because the GC is infectious. As soon as your dependency needs it (and IIRC even parts of the standard library did/do), it becomes painful if not impossible for you to avoid it. Had it not had this fatal flaw, D might've fared much better.
randbox
> Because the GC is infectious. As soon as your dependency needs it (and IIRC even parts of the standard library did/do), it becomes painful if not impossible for you to avoid it.
Isn't this the same for Nim? The standard library doesn't provide pure functions for parsing strings, it provides functions which generate exceptions. Exceptions use the heap, it's hard to get programs to compile with the garbage collector turned off, so everyone just recommends using ARC.
dataflow
I don't know Nim, maybe it's the same? If it is I guess that would probably also explain why Nim hasn't replaced C or C++ either.
Though do note that (academic discussions notwithstanding) refcounting is not what people usually mean by GC in these contexts. Having to put up with refcounting is one thing (people already do it manually anyway), but having to put up with a generational or other complex GC is quite something else.
LAC-Tech
The issue with D is it still feels unpolished. Every time I try it - which is maybe once a year or so - the experience still feels weird and edge casey.
The idea that a GC is somehow a hindrance to language adoption doesn't make any sense to me at all. Doesn't stop people loving Go. But go has slick tooling.
dataflow
> The idea that a GC is somehow a hindrance to language adoption doesn't make any sense to me at all. Doesn't stop people loving Go.
I meant as a systems programming language. To replace C or C++ or such.
LAC-Tech
Yeah fair enough.
Though I have to say - are there really that many scenarios in 2022 where a GC is unacceptable? Hard real time systems, sure. Tight loops in a high performance game engine - I can imagine. But... web servers? Graphical apps? Daemons?
I think there is a sweet spot for natively compiled languages, with garbage collectors, but also let you have a tight control of memory layout. There's really not many in this category.
BenFrantzDale
I had one experience with Go. It was slow because the GC kept kicking in. So we won’t use Go again in favor of time-tested C++. GC is a major reason we are using C++ over Go. In my mind it’s a half-speed language. I’m also very put off by Rob Pike’s “Look, we replaced C++!” attitude when he somehow doesn’t seem to grok zero-cost abstractions. C++ has plenty of issues, but it doesn’t have GC and it goes further, providing standard allocators: both PMR for convenience and most use cases, and statically, for truly zero runtime cost.
funny_falcon
I haven't seen Go's hit larger than 25% in our production.
Usually that means we have to keep average CPU load below 70%. (Since GC cames once in several minutes, it is usually not seen in per-minute averages)
That is ok for us, since Go significantly boosts development compared to stricter language.
It is "marketplace" thing, so we have enough money to spend on additional 50% servers compared to "extremely efficient No-GC" solutions.
It all depends.
hbogert
Rob pike said they intended to replace c++, that didn't happen to his own accord.
Sander3Utile
It's main thing these days is its compile-time function executing and ‘design by introspection’.
Cyph0n
> [..] 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 wish OP the best with Nim. I’ve always found it to be an interesting language.
elcritch
The authors reasoning makes sense to me. Rust is powerful but also complicated and tends to encourage playing "language golf" as often as solving actual problems.
> there isn't a lot of reason to defer to Rust as an obvious choice outside of the usual focus on memory safety that dominates public opinion. 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.
Nim made me enjoy programming again, largely for these reasons. When I was younger I enjoyed mastering languages like C++ or learning complicated generics systems, but now I enjoy just building useful things with minimal fuss. I don't care as much about type soundness of my CTFE, just that I can parse a file at compile time to do something useful. Sure its on my to ensure my files are stable, but thats just part of programming.
> I don't want to have to think about the language, and that's all Rust wants you to think about. I see a lot of people attracted to Rust where there is no shortage of funding and developer focus tends to be competitive, often leaning towards academic purity over solving pressing customer facing problems. These aren't luxuries I have and, to be frank, is not the profile of developer that one should hire for in an early stage startup. Nim gets out of the way, and stays out of the way.
This is an interesting take.
Cyph0n
> tends to encourage playing "language golf" as often as solving actual problems.
Is this your perception, or are you actually seeing this being encouraged by the Rust community?
> This is an interesting take.
I personally don’t agree with OP’s take on Rust at all, but I respect their decision to use whatever language works best.
j16sdiz
Not GP.
In my experience, “language golf” is very popular in Rust, Scala and Haskell communities.
aussiesnack
> 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 intending it for a (personal/hobby) cli app. But again, just found it dispiriting. I wasn't baulking at a single tutorial. I read all the Rust book (and worked through about half of it in detail). I read Jim Blandy's book. Lots of tutorials etc. I went through all of Rustlings. And wrote the first phase of my cli app (it's trivial but fairly robust and I use it daily). I still found it damned hard to get anything done in Rust.
I haven't quite given up (mainly out of stubbornness and having some time on my hands), and plan to take up the 2nd phase of my one Rust app. But anyone who finds Rust to be tractable by just 'investing some time to learn it' is living in a different world from mine.
Cyph0n
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 type of person who wants to fully understand why things are the way they are before moving on, the process may likely slow down further. I think Rust is the kind of language where accepting things as they are at first will help you learn quicker. You can always circle back to dig in later.
For me personally, it took a couple of tries to “get” Rust. It definitely wasn’t straightforward to learn, but it wasn’t insanely complex either. Again, I think background and learning style contribute here.
Best of luck on your learning journey!
aussiesnack
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.
j16sdiz
> 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.
etra0
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
j-james
Reference and pointer types (annotated with `ref` and `ptr` respectively) are nillable. The compiler can provide null safety guarantees by annotating types with `not nil`: https://nim-lang.github.io/Nim/manual_experimental.html#not-.... So then your example would look like the following, and fail to compile.
type
Foo = ref object
Bar = Foo not nil
var bar: Bar = nil # error: type mismatch
echo bar.a
bet3lgeuse
Hi, article author, here. Down in one of your other replies, you state:
> The context for that question is important: OP had a set of requirements and Rust seemed to meet them.
The context as I presented it is perhaps unfairly narrow, and I've glossed over some of the non-technical requirements that constrain my choices. Time-to-market and funding levels are hyper critical - these are hard limits that have less riding on me-as-IC being the sole determinant of a positive outcome, and more on being able to hire the first team members should I meet my funding goals in 2023. Here in the EU, hiring rust devs is ultra-competitive, expensive, and open positions tend to sit unfilled for longer periods of time. There is a mercenary like attitude among experienced crypto developers that makes it difficult to recruit for projects. A developer who is good with rust and knows crypto well doesn't need you for a job - they're probably already looking for funding or considering a co-founder position with a biz person that's already snared a wealthy benefactor for advisory and seed funding. This makes building a founding team (vs a team of co-founders) very difficult in the space.
On the flip side, I can teach a good JVM / golang / python / NodeJS developer how to iterate in nim a lot faster than bringing them up to speed as a proficient rust developer.
My top considerations were among "productive" compiled languages: go, crystal, swift, even investigating mruby. These languages have considerably less cognitive surface-area in banging out pedestrian and proprietary IP code in a 7:1 ratio (not scientific, obvs). First, you need to quickly produce MVP and v1.0 products. Secondly, the follow-on to that is being able to support fast iteration to launch and prune features. This latter aspect is much more important than the zero-to-MVP phase, since the clock isn't really running until you're actively marketing a project and it's gaining (or losing) users. Rust is just not a good choice for the entire code base. It is, however, a great-to-good choice for low-level dependencies. Given it's flexibility, I think Nim can be both. We'll see.
There are two documents that haunt my thoughts over the course of decades being in tech startups. One of them is Paul Graham's "Beating the Averages". The other is Akin's Laws of Spacecraft Design.
One of Paul's reasons for using Lisp at Viaweb was, paraphrasing here for brevity, that choosing the defaults of your competitors is going to yield an average result, which will put you out of business. In my industry vertical, I do think that Golang is more that default than is rust. The evidence seems to point toward Go based teams being better at burning through VC (tongue firmly in cheek ;-) ), and that Rust is superior at embedding working technology whose code-paths touch every customer, every day.
My sincere hope is that Nim hits the sweet spot in the middle while eeking out some of the competitive advantages that Graham talks about. As the idiom goes, you takes your money, and you makes your bets.
http://www.paulgraham.com/avg.html
As for Akin, the full list has some doozies but the one that really sticks out to me in the context of startups is this:
40. (McBryan's Law) You can't make it better until you make it work.
https://spacecraft.ssl.umd.edu/akins_laws.html
cheers
nu11ptr
> 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 cursory glance. I don't feel at all the way the author does about Rust. I do somewhat about Haskell I admit, although I like it just fine, but Rust is very much a "get it done" language, not something for academics. The only exception to this is the borrow checker, which isn't near the impediment most people think it is, but it does take a little practice. I learned it at 45 without issue, just a little bit of time. At this point, I code Rust as fast as any other language (probably faster when including debugging time - I almost never have to debug my Rust code).
francasso
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 compared to the C one? No, not at all. Do I think that the additional memory safety that comes from Rust is worth it? In some use cases, yes
nu11ptr
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 you just have to code differently, and until you spend time thinking about how to do that, it would seem like wasted time you wouldn't get back.
My personality may also be a fit: I'm very much a measure twice, cut once kind of person. I tend write my algorithms in pseudo code and sketch my data structures on paper before I touch the keyboard, so even in my "get it done" language I don't immediately just start coding always.
undefined
easterncalculus
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.
insanitybit
If you were clever enough to write it safely in C I can guarantee you'd be clever enough to write it in Rust.
francasso
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
root_axis
> 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.
francasso
I think you are overestimating the expressive power of lifetime annotations in rust, and how smart the borrow checker is
moldavi
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."
pie_flavor
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.
aquariusDue
I kinda agree, it's weird to me how people make a big deal about the borrow checker as if it's an evil spirit gatekeeping your code.
And if you wanna go fast instead of writing maintainable code you surely can with stuff like unwrap(), clone(), Copy.
In a way I think most people expect to pick up Rust more easily because they have expertise in other languages and are surprised when Rust feels like learning to code again, basically turning some ingrained assumptions upside down.
It really is not the kind of language where you can glaze over the introduction chapter and churn a TODO app in the same afternoon in my opinion.
wiseowise
> 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.
Karrot_Kream
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.
vlunkr
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.
nu11ptr
> 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.
aprdm
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 :)
undefined
aew4ytasghe5
Your argument vs OP that tried rust, is that they should try rust until they agree with you?
greybox
Im currently writing a multiplayer game client (personal project) in nim +SDL2 which is comes with bindings for. Now and then I hit some obtuse compiler error messages, and the compilation times aren't the best. But honestly I'm glad I chose it over c++, which has been my default choice in the past. I wanted to try something new and I'm glad I stumbled across it at the right time
npalli
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(?)
elcritch
The default for the upcoming Nim 2.0 will be ORC. Its the default already on the dev branch since the Nim compiler was switched to use it. See Araq's talk from NimConf: https://youtu.be/aDi50K_Id_k?list=PLxLdEZg8DRwSQQaK0UVRd1Dae...
verdagon
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.
rich_sasha
I'm choosing between learning Nim or Rust. Nim frankly looks like the nicer of the two, but also less marketable and with smaller community.
Suck to say but it's true.
anyfactor
I honestly don't think your options should be between Nim and Rust. Nim has a very small community, and almost nobody is hiring for Nim experience. Going through Nim's forum, I think most developers tend to work on Nim projects alone.
If marketability is your priority, learn the popular languages like java, c, c++, golang etc. Even people hiring Rust developers usually have some leeway to hire someone who can learn Rust on the job.
The decision to learn a programming language comes down to three options:
- Popularity
- You are paid to learn
- You are passionate about it, and you don't expect to collaborate with anyone.
Number 3 is the reason why I am learning Nim.
rich_sasha
I think you are jumping to conclusions about my choices. Why do you explain to me how to decide when you don't know my objectives and constraints?
My main language is Python, to that I'd like to add a compiled, native code, fast-ish, statically typed language with good Python interop. That takes away JVM and .net languages and leaves, roughly, C++, Rust, Nim, maybe Go. I take Go off because I don't like it. I also can't stand modern C++. What does it leave me with?
anyfactor
> Why do you explain to me how to decide when you don't know my objectives and constraints?
You asked a question. You didn't provide any context. I took the initiative to answer the question based on the mere statement of "Nim vs Rust".
My intial feedback still holds true. Does your job require you to learn anything specific or do you want to learn anything just because?
> I take Go off because I don't like it. I also can't stand modern C++.
You are giving your personal opinion and without context. Why do you not like Go.... never mind. It is the weekend, try Nim and Rust both, see what you like.
undefined
PixyMisa
Nim is also easier to learn - if you know Python and any conventional statically typed language, it's a walk in the park. I was producing fast, working code in a couple of hours.
Learn Rust for your job, Nim for your side projects.
bitexploder
Something I long assumed about Rust before really getting started is that it is /slower/ to develop with. And at first that is definitely true because it introduces some pretty big, powerful, and constraining things. When you learn to work with these things and have taken your lumps discussing your code with `rustc` it is a lot of fun.
1.) Moves / borrowing / memory model 2.) Adopting a more functional style [to support 1.)]
My observation is that a lot of people /really/ want Rust to be imperative and treat it very imperatively they fight the borrow checker way more than if they adopt the idiomatic norms of Rust. There are some edge case data structures that can be a little painful and require some specialized knowledge, but once you are into Rust I don't even think it is unpleasant for side projects and general purpose hacking, but to get there it demands a higher level of mastery than most languages, but when you get there it can feel extremely productive.
syntheweave
Rust's sphere of necessary domain knowledge is higher than average. That's not a downside relative to the goal it has in mind, but it is a trade-off. When you're an indie developer working on a side project, there's a strong impulse to let go of a lot of the specific quality controls and customizations that you can use in a team setting where you're paid to know how to operate the inner workings, and instead look for something that is "prosumer" and lets you hack out a solution.
It's kind of the difference between "I want to make a camera" and "I want to mod a camera". Making means controlling the design from the beginning, and Rust is one of the best available tools for that. But modding is more like what you do when you want to bodge together some pieces of I/O and data processing. Apps dealing with audio and graphics in any fine-grained sense tend to want the latter: they aren't actually dealing with resource management issues that often, especially not in the "weekend hack" stage, they just need low latency device access and a fast-enough inner loop. And those requirements imposed a massive, non-obvious barrier to entry on stuff with a substantial VM runtime: writing bindings, remapping ABI semantics, etc. You had to learn a lot of concepts, possibly more than are needed for writing useful Rust code, to overcome that. Rust demands just that you use certain kinds of documented idioms to get through a typical coding problem, while fighting with compilers and linkers to create bindings is a no-mans-land of debugging the meaning of each error message, silent failure or crash, requiring you to know two languages, the build system, the binary formats, and the OS you're targeting simultaneously.
For a long time, C++, for all its faults, was the prosumer's tool of choice for coding near to the metal while still leveraging existing tech, because it was what the toolchains actually supported directly, which let you get ypur weekend hack working piecemeal, while using something else introduced unacceptable levels of overhead.
But I think there are now justifications to use Rust in some cases and Zig or Nim in others. I've kicked the tires on all three, and can vouch for Nim feeling productive in the sense of being both relatively C-friendly as a build environment(lots of features for high-permissiveness hacking) and also occupying a "default to high-level methods" mindset. D could have gotten there in an alternate reality, I think, but it was trying really hard to be big-systems code instead of hacker's glue, which has saddled it with an awkward design story. The things D wanted to do well, Rust now mostly occupies.
fncivivue7
Found this myself. Learning curve is steep. Still not there yet but once you get into it I can really see how more productive I am vs other languages.
Other languages just require a lot more trial and error to get them to do what you want. Rust, if it compiles, generally does what you expected.
It's not just type safety and the borrow checking either, it's the idioms, std lib, and other language design choices that lead on to improved devex in the wider ecosystem as a result.
I understand you can get the same features out of modern C++ now days but it's not just the features, it's everything that comes with it.
memco
I had a similar experience. I took a very small project from Python and turned it into Nim: it was about six times as fast to run and took roughly the same amount of code in both. I have plans to learn more but this article is actually a little more fuel for my fire as I think one of my next explorations would be transferring and running code on other systems. If portability is as easy I could see this being used for some work tools I am building. We will almost surely never replace the current language all the major code is written in, but for small self-contained tools it would be great.
_dain_
I'm learning Rust now, I can say Nim is much harder. Maybe the language itself is simpler, but the documentation is just not very good. Very unpolished and amateurish. I actually forked out fifty quid for Araq's "Mastering Nim" book; it is atrocious. Spelling and grammatical errors on every page. The very first code example did not compile.
I also regularly run into utterly infuriating bugs while trying to accomplish what I thought would be simple things. Don't expect to be able to get anything useful done using iterators. They're zero-cost only if you don't value your own time.
On the other hand, all of Rust's docs are a joy and I haven't run into many technical problems so far.
winrid
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.
j-james
Did we read the same book? I find Mastering Nim a pretty excellent reference. (And you have to install the pixels library :-P)
The online documentation, certainly, could be better. I sometimes find standard library documentation lacking in examples, and compiler documentation is currently undergoing a massive refactoring effort on a couple of fronts. But the manual (https://nim-lang.github.io/Nim/manual.html) isn't half bad.
planetis
I have the book, and it's an excellent resource for the language. I might be a little biased because I am a long time Nim user but definitely so are you.
tomrod
Does Nim have any large groups sponsoring? Part of the appeal of Rust is that it will be around in 20 years due to so many groups adopting it and maturing its governance.
I enjoyed learning Nim syntax through exercism.io (not affiliated, just really enjoy it as a tool), but I'll be honest that I have no clue if it will become an ungoverned mess or thrive.
epage
> Nim is also easier to learn - if you know Python and any conventional statically typed language, it's a walk in the park. I
I kept hearing the comparisons to Python so I thought it'd be interesting to pick up but the syntax and naming was so counter to Python that that expectation made me immediately bounce off of it.
StillBored
I tend to be a C with objects (compiled with a C++ compiler) type of person because I think things like the base string, memory blob, etc types in C should have the ability to have bounds checking built in at compile time if the programmer chooses. Simply fixing the few things "wrong" with C I tend to think gets you 95% of the way to a heavier weight environment like java/etc.
So, I can't help but feel that all these languages are trying to solve that last couple percent, and paying a huge price in perf or programmer productivity to do it, at the cost of basically close to 0% bugs actually being reduced. Particularly when compared with C++ and Ada when used in a rigorous development environment.
Nim seems like the kind of thing (a veneer over C) I would want, along with an easy of interfacing to the rest of a C based project, but I always just tend to end up reaching for C with classes, when I need to get something done yesterday, and it needs to fit in a few K, or push the metal to the limit. Largely because I trust I won't get myself in a corner with it.
(PS: I too tried rust and tossed it as not ready, and not really solving the right problem. I don't tend to have memory concurrency bugs in either C or C++ because I don't try to be clever, instead defaulting to simple ownership models wrapped in C++ classes, or fully containing locking/etc in a single function that does all the work of both locking and unlocking the data structure in question and reading/updating it through a single entry/exit).
xedrac
> So, I can't help but feel that all these languages are trying to solve that last couple percent, and paying a huge price in perf or programmer productivity to do it
I'm the first to admit that Rust has a steep learning curve. But now that I'm proficient in it, and as a long time C++ programmer, Rust is easily 2x more productive for me, and WAY more enjoyable. For large/complex codebases, the gap is even bigger IMO. But yeah, it takes a lot to get over that initial hump. It really helps to have a mentor for the first couple months.
kaba0
> So, I can't help but feel that all these languages are trying to solve that last couple percent, and paying a huge price in perf or programmer productivity to do it, at the cost of basically close to 0% bugs actually being reduced
What about those “heavy” languages like Java, etc? Why don’t you use those then? I really don’t think that it has been true for the last 20 years to claim that they have a huge perf cost. And you really can’t go down the “safe” path in Java, even race conditions are well defined after all.
jstx1
Importantly it's a decision made as a solo developer at a tiny company. Otherwise it's not like there are any Nim jobs out there, or any serious mindshare/momentum, or significant investment from big companies.
Get the top HN stories in your inbox every day.
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 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.
Shout out to https://github.com/StefanSalewski/gintro which was super simple to build a simple GUI tool. With Rust I have no idea what to use after trying 5 different libraries.
The downside of Nim seems to be highly unpredictable performance in my experience. With Rust it's much easier to control. This might be a deal-breaker unless I can find some solution to it. Maybe it's just using it more than two weeks and learning the ropes.