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.<p>Shout out to <a href="https://github.com/StefanSalewski/gintro" rel="nofollow">https://github.com/StefanSalewski/gintro</a> which was super simple to build a simple GUI tool. With Rust I have no idea what to use after trying 5 different libraries.<p>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.
> I feel inferior for not being fluent in OCaml<p>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.<p>There are now excellent resources, predominantly: <a href="https://cs3110.github.io/textbook/cover.html" rel="nofollow">https://cs3110.github.io/textbook/cover.html</a><p>When OCaml 5 settles, its general applicability will be (imho) much larger.<p>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<p>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.<p>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
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.<p>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.<p>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++.<p>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.<p>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).<p>Oh, and I _love_ nim’s uniform function call syntax. Every other language should copy that feature.<p>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.
> Zig is truly compatible with C and will compile C code directly, since its compiler is actually written in C++.<p>I assume this was intended to say something else?<p>> 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<p>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.<p>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?<p>Anyways, I wish OP the best with Nim. I’ve always found it to be an interesting language.
> Rust: I'm not afraid to admit it - Rust is just too complicated for use as an aging and cranky solo developer.<p>...<p>> 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.<p>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).
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(?)<p>[1] <a href="https://nim-lang.org/1.4.0/gc.html" rel="nofollow">https://nim-lang.org/1.4.0/gc.html</a>
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.<p>Suck to say but it's true.
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.<p>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.<p>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.<p>(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).
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.
> Rust: I'm not afraid to admit it - Rust is just too complicated for use as an aging and cranky solo developer.<p>I'm nearly 51 and currently learning Rust.<p>The first 10 hours of it were horribly slow, but it isn't as steep of a learning curve as Optimal Control Theory.
I really can’t understand where this idea that rust is ‘hard’ comes from. Everything that it formalizes is something that you <i>should already be conscious of</i>. 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:<p>> Pros for Swift are focus on secure programming outside of just obsessing over memory safety like Rust.<p>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 <a href="https://www.swift.org/about/#safety" rel="nofollow">https://www.swift.org/about/#safety</a><p>Another aside, the author gets some points for looking at Pony.
> 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.<p>Why would you find OCaml hard to learn if you know Nim? Isn't Nim a functional programming language as well?<p>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.<p>Chef‘s kiss.
My issue is that Nim has some awkward problems with static linking:<p><a href="https://github.com/nim-lang/Nim/issues/15220" rel="nofollow">https://github.com/nim-lang/Nim/issues/15220</a>
Nim still need a lot of time to mature, there are totally ridiculous decision of things that core things have done like style insensitivity and half a decade old serious bugs that Nim team ignore to fix cause Nim adoption to low. 5 years ago it was on rival to rust but now rust had sky rocketed and Nim community is having a lot of in fighting going.
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.<p>If you are not an expert at C or C++ and being paid to learn Rust or Nim, you’re actively harming your career by not mastering the languages that people want today. If learning hot new fads brings you joy, then perhaps the intrinsic value outweighs the real world loss, but it’s the hard to swallow truth.
"I started out coding in the mid-90s and refocused my career on Bitcoin and crypto in 2016 after leaving a very large software company in Seattle."<p>You're embarrassed to have worked at Microsoft but not on crypto pyramid schemes?
It will be interesting to look again once Nim reaches 2.0. And Crystal still requires lots of work on compiler and Windows Support. I just wish it had more resources. Along with Zig. All three of them need more time to mature.
biggest con of Nim - no one uses it, so you will probably hit a toolchain/compiler error which will be very frustrating<p>too similar to Go to not go with the 100x community size Go brings with it
If I recall Nim doesn't even allow tabs. Programming languages should not be overly opinionated in formatting, especially when it requires extra bytes to use spaces.