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.
> 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
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.
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.
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
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.
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.
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.
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.
> 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.
> [..] 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.
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.
> 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.
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.
> 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).
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
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."
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.
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
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(?)
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.
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.
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.
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).
> 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.
> 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.
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.
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 then have an error condition which is like 'if you die, just print that you died and quit.' And that pretty much meets my needs. The extra safety isn't actually protecting anything valuable, in my case.
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.
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.
What’s the LSP and linter/formatter story these days? Last time I tried it the lsp was miles behind what I am used to from TypeScript land in vscode. I have gotten sooo used to all the auto completion, helpful error tooltips and auto imports and formatting on save that it felt tedious not to have that in a similar capacity. Maybe I was just doing things wrong and it’s been a while. In general I am super intrigued by nim coming from python originally. I wish I could use it professionally on a project just to spend more time with it
Aside, curious what this bit of the post refers to:
> Pros for Swift are focus on secure programming outside of just obsessing over memory safety like Rust.
I've never used Swift at all but would enjoy learning what it brings to the "secure programming" table that I might be missing from the summary at https://www.swift.org/about/#safety
Another aside, the author gets some points for looking at Pony.
I can’t speak for the author, but I’ve had a similar feeling. Where (safe) Rust’s core principle is memory safety at all costs, I feel that Swift takes a more nuanced approach, prioritizing making good programming patterns easier while still being memory safe (though perhaps not as expressive as Rust).
Swift also is much more principled when it come to certain things like exceptions. Whereas Rust (if I remember correctly) allows arbitrary panic-ing and catching of panics, Swift forces you to acknowledge a possible panic at function call sites using “try”. Without “try” control flow can’t suddenly end.
> OCaml, Haskell, F#, and other weirdos: I personally can't do it. I tend to not like functional programming languages. I want to, but my brain lacks the plasticity to relearn everything.
Why would you find OCaml hard to learn if you know Nim? Isn't Nim a functional programming language as well?
Also, how is Nim for writing real-time games that run via JavaScript where you want to avoid garbage collection pauses?
> I think the D folks fell into the same trap as Rust in trying to support every esoteric programming fetish stemming from toy-project and side-hustle demands among People Who Code.
[+] [-] 127|3 years ago|reply
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.
[+] [-] pitaj|3 years ago|reply
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
[+] [-] etra0|3 years ago|reply
It's still fun though, and I appreciate the minimal visual noise while writing it.
[+] [-] throwup|3 years ago|reply
I'm curious whether you tried gtk-rs and if so what problems did you have?
[+] [-] culi|3 years ago|reply
Seems like GTK is the pretty clear frontrunner?
https://www.areweguiyet.com/
[+] [-] cdaringe|3 years ago|reply
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|3 years ago|reply
> 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.
[+] [-] TylerE|3 years ago|reply
[+] [-] ezquerra|3 years ago|reply
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|3 years ago|reply
[+] [-] ilovecaching|3 years ago|reply
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.
[+] [-] dataflow|3 years ago|reply
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.
[+] [-] Cyph0n|3 years ago|reply
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|3 years ago|reply
> 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.
[+] [-] aussiesnack|3 years ago|reply
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.
[+] [-] etra0|3 years ago|reply
This minimal example causes a segfault:
which wouldn't be simply possible to type in safe Rust.[+] [-] bet3lgeuse|3 years ago|reply
> 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|3 years ago|reply
...
> 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|3 years ago|reply
[+] [-] moldavi|3 years ago|reply
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."
[+] [-] Karrot_Kream|3 years ago|reply
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.
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] aew4ytasghe5|3 years ago|reply
[+] [-] greybox|3 years ago|reply
[+] [-] npalli|3 years ago|reply
[1] https://nim-lang.org/1.4.0/gc.html
[+] [-] elcritch|3 years ago|reply
[+] [-] verdagon|3 years ago|reply
[+] [-] rich_sasha|3 years ago|reply
Suck to say but it's true.
[+] [-] anyfactor|3 years ago|reply
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.
[+] [-] PixyMisa|3 years ago|reply
Learn Rust for your job, Nim for your side projects.
[+] [-] StillBored|3 years ago|reply
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|3 years ago|reply
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|3 years ago|reply
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|3 years ago|reply
[+] [-] lamontcg|3 years ago|reply
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.
[+] [-] julianeon|3 years ago|reply
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 then have an error condition which is like 'if you die, just print that you died and quit.' And that pretty much meets my needs. The extra safety isn't actually protecting anything valuable, in my case.
[+] [-] nu11ptr|3 years ago|reply
[+] [-] jmartin2683|3 years ago|reply
[+] [-] bmacho|3 years ago|reply
In what sense?
[+] [-] Escapado|3 years ago|reply
[+] [-] mlinksva|3 years ago|reply
> Pros for Swift are focus on secure programming outside of just obsessing over memory safety like Rust.
I've never used Swift at all but would enjoy learning what it brings to the "secure programming" table that I might be missing from the summary at https://www.swift.org/about/#safety
Another aside, the author gets some points for looking at Pony.
[+] [-] georgelyon|3 years ago|reply
Swift also is much more principled when it come to certain things like exceptions. Whereas Rust (if I remember correctly) allows arbitrary panic-ing and catching of panics, Swift forces you to acknowledge a possible panic at function call sites using “try”. Without “try” control flow can’t suddenly end.
Admittedly, I haven’t used Rust significantly in a couple years, but I wrote this a few years back and some of the points still have merit: https://gist.github.com/GeorgeLyon/c7b07923f7a800674bc9745ae...
[+] [-] seanwilson|3 years ago|reply
Why would you find OCaml hard to learn if you know Nim? Isn't Nim a functional programming language as well?
Also, how is Nim for writing real-time games that run via JavaScript where you want to avoid garbage collection pauses?
[+] [-] christophilus|3 years ago|reply
[+] [-] klohto|3 years ago|reply
[+] [-] MrBuddyCasino|3 years ago|reply
Chef‘s kiss.
[+] [-] svnpenn|3 years ago|reply
https://github.com/nim-lang/Nim/issues/15220