37 ms·

Choosing Nim out of a crowded market for systems programming languages

272 points by generichuman 4y ago

jstx1 4y ago
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.
newaccount2021 4y ago
biggest con of Nim - no one uses it, so you will probably hit a toolchain/compiler error which will be very frustrating too similar to Go to not go with the 100x community size Go brings with it
- planetis 4y ago
  Hey I do, and report bugs which eventually are all getting fixed. Besides me (who's that guy anyway) there are a lot more experienced programmers who have built amazing things with Nim. Arraymancer, a deep learning library comes to mind and fidget which is an UI library, it's remarkable because all it's dependencies were written from scratch in Nim. Not to forget the Ethereum client nimbus and all the other companies using Nim in production. Perhaps give it a shot?
- archsurface 4y ago
  It's far more enjoyable than Go. I use Go at work, Nim at home. A smaller community, of course without Google's backing, but it is growing.
sergiotapia 4y ago
Nim desperately needs a real web framework (batteries included) and a proper ORM and it will take off like wildfire. Python on steroids.
- ilovecaching 4y ago
  I think you’re very confused about the purpose of a systems programming language.
  - tomrod 4y ago
    Nah, parent commentator and me both think Nim could be really large. The definition of "systems programming language" is defined by arbitrary lines.
    - ilovecaching 4y ago
      Web apps are applications and are the opposite of systems software. Systems software would be the web server itself, or something that runs beneath the application layer. Yes definitions are sometimes nebulous but that doesn’t mean words should lose all meaning and we should stop trying. Systems programming is a useful label for the boot stack, kernel, protocol implementations etc. which support the application layer.
      - alpaca128 4y ago
        The "systems" label only means those languages can do a few more low-level things, nothing more. There's no reason not to use it for other things as well.
        3a2d29 4y ago
        I know this is hammered to death on HN, but you could definitely argue memory safety is a reason not to use systems languages for anything else. Granted though it means what you meant by "it". I read that as "a systems programming language", but if you specifically meant Nim then I think it can enable a GC.
  - sergiotapia 4y ago
    Not at all, and I've actually _used_ Nim for a few years now. If Nim does not get a general purpose, batteries included web framework it will never reach escape velocity and will be left in obscurity despite all of the incredibly difficult and marvelous work Araq and the team has done. I want them to succeed. I love the language!
dataflow 4y ago
> 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.
- LAC-Tech 4y ago
  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 4y ago
    > 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 4y ago
      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.
      - dataflow 4y ago
        > Though I have to say - are there really that many scenarios in 2022 where a GC is unacceptable? There are tons of C++ and C programmers who would find the introduction of a GC into their programs to be unacceptable, yes. That's why D keeps losing this battle.
rich_sasha 4y ago
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.
- PixyMisa 4y ago
  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.
  - tomrod 4y ago
    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.
    - sigzero 4y ago
      https://nim-lang.org/sponsors.html https://nim-lang.org/sponsors.html
      - tomrod 4y ago
        Ah, so its definitely a passion project with only about $21k in direct funding per month as of last update (2019). Hey @G/Xooglers, Linux Foundation, etc., consider supporting Nim!
  - memco 4y ago
    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.
whage 4y ago
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 4y ago
  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 4y ago
    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 4y ago
      As they say, let people enjoy things
    - ilovecaching 4y ago
      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.
      - Herbstluft 4y ago
ilovecaching 4y ago
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. 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.
- LAC-Tech 4y ago
  Most people prefer coding newer systems over legacy systems in old dialects of C and C++. So that skews things more heavily in favour of rust.
  - 3a2d29 4y ago
    I agree, but what people prefer vs what companies do are very different. Companies rarely pay for totally rewrites. Nim compiles to C and offers safety that can work on top of codebases without a re-write.
- urthor 4y ago
  The Rust community is however, an excellent community to be part of. And it's future proof. Everyone knows Rust is the future. I'd say, for most college students, Rust would be the one you'd advise today.
  - planetis 4y ago
    I have bad experience interacting with members of the rust community. Biggest issue is that they don't keep their opinions to themselves and frankly make everyone misserable with their "join us now, you must" mentality.
    - 4y ago
greybox 4y ago
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
deleted 4y ago
[deleted]
stefantalpalaru 4y ago
Escapado 4y ago
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
- elcritch 4y ago
  Its ok. A developer was recently hired to work on it full time though!
  - zelphirkalt 4y ago
    On it or with it?
    - elcritch 4y ago
      On it, to improve the lsp tooling.
- j-james 4y ago
  It's alright when it doesn't crash. But it frequently crashes. Tooling is definitely a weakness of Nim (although it's improving). More specifically: right now auto completion is excellent, implicit type annotations are excellent, error tooltips on save work, broader rename/refactor support is limited/nonexistent, formatting on save is fine, auto imports don't exist (and probably shouldn't given that it's typical to use unqualified namespaces).
Cyph0n 4y ago
> [..] 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 4y ago
  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 4y ago
    > 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.
127 4y ago
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 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.
- throwup 4y ago
  It looks like gintro is a GTK binding - the Rust equivalent would be gtk-rs. https://www.gtk.org/docs/language-bindings/rust/ https://www.gtk.org/docs/language-bindings/rust/ I'm curious whether you tried gtk-rs and if so what problems did you have?
- pitaj 4y ago
  > 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
  - dilawar 4y ago
    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!?
bmacho 4y ago
> Pony has probably the best type system in any language existing today, giving even Haskell a run for its money. In what sense?
jmartin2683 4y ago
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.
- planetis 4y ago
  Can you explain to us what's the bigger problem we should be addressing according to your opinion sir?
  - jmartin2683 4y ago
    You’re creating lots and lots of bugs that will come back to haunt to at runtime (midnight on a Friday if the universe has its way).
    - lolinder 4y ago
      You're assuming everyone is coming to Rust from C. People who are learning Rust from a garbage-collected language will absolutely feel that Rust is harder than what they're used to, and not because they were writing bug-ridden code in Java or whatever.
    - moldavi 4y ago
      Single ownership often introduces bugs of its own. In Java, I never need to create an Err if the thing my ID is "pointing" to isn't around anymore in whatever hash map the borrow checker made me store it in. It's good in some cases, bad in others.
      - wiseowise 4y ago
        > In Java, I never need to create an Err if the thing my ID is "pointing" to isn't around anymore in whatever hash map the borrow checker made me store it in. What’s the problem here in Rust?
- wk_end 4y ago
npalli 4y ago
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(?) [1] https://nim-lang.org/1.4.0/gc.html https://nim-lang.org/1.4.0/gc.html
- elcritch 4y ago
  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=PLxLdEZg8DRwSQQaK0UVRd1DaetVc3lIwr https://youtu.be/aDi50K_Id_k?list=PLxLdEZg8DRwSQQaK0UVRd1Dae...
- verdagon 4y ago
  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.
svnpenn 4y ago
My issue is that Nim has some awkward problems with static linking: https://github.com/nim-lang/Nim/issues/15220 https://github.com/nim-lang/Nim/issues/15220
encryptluks2 4y ago
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.
- thunky 4y ago
  > Programming languages should not be overly opinionated in formatting I think gofmt, python black, etc have demonstrated that it's usually better to have a single standard then it is to fight endlessly about these details.
  - booleandilemma 4y ago
    It's funny you say that, because Go and Python are two of my least favorite languages, partially for reasons of formatting.
  - pigsinzen 4y ago
    They have demonstrated that some people have interest in controlling formatting. It would be a stretch to say they demonstrated that it’s better to enforce a standard. Black, itself, changed rules many times within a 1-year period to the point our own CI would fail on existing code that previously passed.
    - __turbobrew__ 4y ago
      > CI would fail on existing code that previously passed. You problem isn’t that black changed formatting rules, your problem is that you didn’t pin CI dependencies. This isn’t a unique problem to black, any other tool used in CI pipelines can cause things to break if you don’t pin them.
      - danuker 4y ago
        Indeed. Something wihout security impact will use pointless resources when you update. Do it rarely (or never if possible).
- 4y ago
mlinksva 4y ago
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 https://www.swift.org/about/#safety Another aside, the author gets some points for looking at Pony.
- georgelyon 4y ago
  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. 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/c7b07923f7a800674bc9745ae45ddc7f https://gist.github.com/GeorgeLyon/c7b07923f7a800674bc9745ae...
  - kibwen 4y ago
    > Whereas Rust (if I remember correctly) allows arbitrary panic-ing and catching of panics While it is possible to "catch" a panic in Rust, this is not an error-handling strategy, it is a correctness fallback. The intent is that, if you're writing a Rust library that exposes a C ABI, you halt the panic at the boundary of your library, because there is no standardized cross-language unwinding scheme and so unwinding across an FFI boundary would be UB. It's not there for error handling (and it can't be, not only because the API is deliberately designed to discourage it, but also because Rust programs can be compiled in a mode where panics abort instead of unwind). > Swift forces you to acknowledge a possible panic at function call sites using “try”. Without “try” control flow can’t suddenly end. This is a bit inaccurate. You can absolutely do things like divide by zero in a Swift function that isn't marked as `try`, which will crash the program. This is the same behavior that is expected of panics in Rust.
lamontcg 4y ago
> Rust: I'm not afraid to admit it - Rust is just too complicated for use as an aging and cranky solo developer. I'm nearly 51 and currently learning Rust. The first 10 hours of it were horribly slow, but it isn't as steep of a learning curve as Optimal Control Theory.
- nu11ptr 4y ago
  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.
  - moldavi 4y ago
    Easier than C or C++ for sure. But I definitely wouldn't say that Rust as easy as a GC'd language like Java or Go. They have strictly less constraints to deal with, they can let you use the simplest pattern for the situation, and (in my experience) they have less superfluous refactoring sessions due to the overly conservative nature of the borrow checker. I like how Matt Welsh put it in https://mdwdotla.medium.com/using-rust-at-a-startup-a-cautionary-tale-42ab823d9454 https://mdwdotla.medium.com/using-rust-at-a-startup-a-cautio...: > What really bites is when you need to change the type signature of a load-bearing interface and find yourself spending hours changing every place where the type is used only to see if your initial stab at something is feasible. And then redoing all of that work when you realize you need to change it again. Perhaps you're instead speaking of a specific situation or kind of program where the borrow checker happens to be no harder than any other language?
  - tgv 4y ago
    In my experience, it depends heavily on the kind of thing you're writing. I could write some small programs in it, no problem: a rather complex, text-based calculator was easy and elegant to write with function arguments, a game server monitor, some tools for a cryptography course, an FFT analyzer that reads from WAV or AIFF, etc. Then I tried to port my rather efficient Earley parser (https://en.wikipedia.org/wiki/Earley_parser https://en.wikipedia.org/wiki/Earley_parser) from C. Constructing the item set efficiently wasn't that hard, but constructing the forest (set of syntactic trees) was. In C, it was basically free by using some pointer sharing, but I couldn't get that done in Rust. Perhaps there's some clever trick I couldn't think of, but I couldn't get it anywhere near C's speed. And since the ultimate goal of that parser includes further memory shenanigans (unification of results yielded by the rules), I dropped the project. At my job, I'm writing in Go. I fairly sure I could easily port the C code to that. It would probably run a bit slower, but the algorithm and data structures would be readable, and extendable. So: it depends.
seanwilson 4y ago
> 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?
- christophilus 4y ago
  Nim is not really functional. Like most modern languages, you could probably pull of a functional style with it, but it's mutable, imperative, etc.
  - sanxiyn 4y ago
    OCaml supports mutability well. Basically, you can write OCaml as if you are writing Nim.
- klohto 4y ago
  Same way you avoid them directly in JS. I don’t think Nim claims it’s easy to do.
jopython 4y ago
Nim does not have a native ssl and regex lib in the standard library like golang or python. These libraries are taken for granted nowadays.
- firesloth 4y ago
  It doesn't? https://nim-lang.org/docs/re.html https://nim-lang.org/docs/re.html and https://nim-lang.org/docs/net.html https://nim-lang.org/docs/net.html are part of nim's standard library. Are they missing something you expect?
  - jopython 4y ago
    They are dependent on pcre and openssl respectively unlike Golang which is native.
    - cb321 4y ago
      Well, sure Golang, but to be fair they are not native pure Python in Python's stdlib either... This is more broadly relevant since part of the appeal of Nim is its easy C/C++ interoperability (by generating to these and so only requiring some declaration).
nu11ptr 4y ago
> 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 4y ago
  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
  - insanitybit 4y ago
    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 4y ago
      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
v3ss0n 4y ago
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.
cdaringe 4y ago
> 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 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 4y ago
  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.
germandiago 4y ago
This comparison looks more like a discourse than anything else IMHO.
anta40 4y ago
Hmm.. wonder why Pascal isn't on the list
- TylerE 4y ago
  Because it’s 2022 not 1982? There hasn’t been a new Pascal standard in 34 years.
  - anta40 4y ago
    Not sure about the current state of ISO Pascal, at least there's no ISO D or Rust, either. D and Rust are defined by the official implementations. On the other side, Delphi is still being enhanced and FPC tries to be compatible with it, so there are not stuck in 1982.
  - kcartlidge 4y ago
    I do C#, Go, Python, Node, Ruby, etc., but Free Pascal with Lazarus is my #1 choice for any cross-platform desktop app that needs a decent GUI without using Electron. It's free, fast (enough), and exceptionally easy. If you need a supported system then even Delphi is back to being (not totally un)reasonably priced once you consider that they only charge when you begin earning from it. Their threshold is very low, but by the time you reach it you've tested your idea and got sales. As for Pascal standards, I'm not entirely sure why there would need to be a recent one. Standards bodies have their place, but their activity is pretty much never something I ever give a thought to when deciding on software tooling.
    - TylerE 4y ago
      Standards can be overrated, sure, but some things like Unicode support really need to be done rihht
    - anta40 4y ago
      I think Pascal implementations are practically dominated by Delphi and FPC these days (FPC has Delphi compatibility mode). On the other side, there are more players in C/C++ club: GCC, Clang, MSVC, Pelles C, LCC Win32, AMD C++, Intel C++, etc. Having a standard is certainly useful.
deleted 4y ago
[deleted]
StillBored 4y ago
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 4y ago
  > 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 4y ago
  > 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.
MrBuddyCasino 4y ago
> 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. Chef‘s kiss.
ezquerra 4y ago
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.
drewm1980 4y ago
"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." You're embarrassed to have worked at Microsoft but not on crypto pyramid schemes?
ksec 4y ago
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.

272 points by generichuman 4y ago

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.

newaccount2021 4y ago

biggest con of Nim - no one uses it, so you will probably hit a toolchain/compiler error which will be very frustrating too similar to Go to not go with the 100x community size Go brings with it

planetis 4y ago
Hey I do, and report bugs which eventually are all getting fixed. Besides me (who's that guy anyway) there are a lot more experienced programmers who have built amazing things with Nim. Arraymancer, a deep learning library comes to mind and fidget which is an UI library, it's remarkable because all it's dependencies were written from scratch in Nim. Not to forget the Ethereum client nimbus and all the other companies using Nim in production. Perhaps give it a shot?
archsurface 4y ago
It's far more enjoyable than Go. I use Go at work, Nim at home. A smaller community, of course without Google's backing, but it is growing.

sergiotapia 4y ago

Nim desperately needs a real web framework (batteries included) and a proper ORM and it will take off like wildfire. Python on steroids.

ilovecaching 4y ago
I think you’re very confused about the purpose of a systems programming language.
- tomrod 4y ago
  Nah, parent commentator and me both think Nim could be really large. The definition of "systems programming language" is defined by arbitrary lines.
  - ilovecaching 4y ago
    Web apps are applications and are the opposite of systems software. Systems software would be the web server itself, or something that runs beneath the application layer. Yes definitions are sometimes nebulous but that doesn’t mean words should lose all meaning and we should stop trying. Systems programming is a useful label for the boot stack, kernel, protocol implementations etc. which support the application layer.
    - alpaca128 4y ago
      The "systems" label only means those languages can do a few more low-level things, nothing more. There's no reason not to use it for other things as well.
      - 3a2d29 4y ago
        I know this is hammered to death on HN, but you could definitely argue memory safety is a reason not to use systems languages for anything else. Granted though it means what you meant by "it". I read that as "a systems programming language", but if you specifically meant Nim then I think it can enable a GC.
- sergiotapia 4y ago
  Not at all, and I've actually _used_ Nim for a few years now. If Nim does not get a general purpose, batteries included web framework it will never reach escape velocity and will be left in obscurity despite all of the incredibly difficult and marvelous work Araq and the team has done. I want them to succeed. I love the language!

dataflow 4y ago

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

LAC-Tech 4y ago
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 4y ago
  > 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 4y ago
    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.
    - dataflow 4y ago
      > Though I have to say - are there really that many scenarios in 2022 where a GC is unacceptable? There are tons of C++ and C programmers who would find the introduction of a GC into their programs to be unacceptable, yes. That's why D keeps losing this battle.

rich_sasha 4y ago

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.

PixyMisa 4y ago
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.
- tomrod 4y ago
  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.
  - sigzero 4y ago
    https://nim-lang.org/sponsors.html https://nim-lang.org/sponsors.html
    - tomrod 4y ago
      Ah, so its definitely a passion project with only about $21k in direct funding per month as of last update (2019). Hey @G/Xooglers, Linux Foundation, etc., consider supporting Nim!
- memco 4y ago
  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.

whage 4y ago

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 4y ago
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 4y ago
  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 4y ago
    As they say, let people enjoy things
  - ilovecaching 4y ago
    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.
    - Herbstluft 4y ago

ilovecaching 4y ago

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

LAC-Tech 4y ago
Most people prefer coding newer systems over legacy systems in old dialects of C and C++. So that skews things more heavily in favour of rust.
- 3a2d29 4y ago
  I agree, but what people prefer vs what companies do are very different. Companies rarely pay for totally rewrites. Nim compiles to C and offers safety that can work on top of codebases without a re-write.
urthor 4y ago
The Rust community is however, an excellent community to be part of. And it's future proof. Everyone knows Rust is the future. I'd say, for most college students, Rust would be the one you'd advise today.
- planetis 4y ago
  I have bad experience interacting with members of the rust community. Biggest issue is that they don't keep their opinions to themselves and frankly make everyone misserable with their "join us now, you must" mentality.
  - 4y ago

greybox 4y ago

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

deleted 4y ago

[deleted]

stefantalpalaru 4y ago

Escapado 4y ago

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

elcritch 4y ago
Its ok. A developer was recently hired to work on it full time though!
- zelphirkalt 4y ago
  On it or with it?
  - elcritch 4y ago
    On it, to improve the lsp tooling.
j-james 4y ago
It's alright when it doesn't crash. But it frequently crashes. Tooling is definitely a weakness of Nim (although it's improving). More specifically: right now auto completion is excellent, implicit type annotations are excellent, error tooltips on save work, broader rename/refactor support is limited/nonexistent, formatting on save is fine, auto imports don't exist (and probably shouldn't given that it's typical to use unqualified namespaces).

Cyph0n 4y ago

> [..] 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 4y ago
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 4y ago
  > 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.

127 4y ago

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

throwup 4y ago
It looks like gintro is a GTK binding - the Rust equivalent would be gtk-rs. https://www.gtk.org/docs/language-bindings/rust/ https://www.gtk.org/docs/language-bindings/rust/ I'm curious whether you tried gtk-rs and if so what problems did you have?
pitaj 4y ago
> 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
- dilawar 4y ago
  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!?

bmacho 4y ago

> Pony has probably the best type system in any language existing today, giving even Haskell a run for its money. In what sense?

jmartin2683 4y ago

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.

planetis 4y ago
Can you explain to us what's the bigger problem we should be addressing according to your opinion sir?
- jmartin2683 4y ago
  You’re creating lots and lots of bugs that will come back to haunt to at runtime (midnight on a Friday if the universe has its way).
  - lolinder 4y ago
    You're assuming everyone is coming to Rust from C. People who are learning Rust from a garbage-collected language will absolutely feel that Rust is harder than what they're used to, and not because they were writing bug-ridden code in Java or whatever.
  - moldavi 4y ago
    Single ownership often introduces bugs of its own. In Java, I never need to create an Err if the thing my ID is "pointing" to isn't around anymore in whatever hash map the borrow checker made me store it in. It's good in some cases, bad in others.
    - wiseowise 4y ago
      > In Java, I never need to create an Err if the thing my ID is "pointing" to isn't around anymore in whatever hash map the borrow checker made me store it in. What’s the problem here in Rust?
wk_end 4y ago

npalli 4y ago

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(?) [1] https://nim-lang.org/1.4.0/gc.html https://nim-lang.org/1.4.0/gc.html

elcritch 4y ago
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=PLxLdEZg8DRwSQQaK0UVRd1DaetVc3lIwr https://youtu.be/aDi50K_Id_k?list=PLxLdEZg8DRwSQQaK0UVRd1Dae...
verdagon 4y ago
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.

svnpenn 4y ago

My issue is that Nim has some awkward problems with static linking: https://github.com/nim-lang/Nim/issues/15220 https://github.com/nim-lang/Nim/issues/15220

encryptluks2 4y ago

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.

thunky 4y ago
> Programming languages should not be overly opinionated in formatting I think gofmt, python black, etc have demonstrated that it's usually better to have a single standard then it is to fight endlessly about these details.
- booleandilemma 4y ago
  It's funny you say that, because Go and Python are two of my least favorite languages, partially for reasons of formatting.
- pigsinzen 4y ago
  They have demonstrated that some people have interest in controlling formatting. It would be a stretch to say they demonstrated that it’s better to enforce a standard. Black, itself, changed rules many times within a 1-year period to the point our own CI would fail on existing code that previously passed.
  - __turbobrew__ 4y ago
    > CI would fail on existing code that previously passed. You problem isn’t that black changed formatting rules, your problem is that you didn’t pin CI dependencies. This isn’t a unique problem to black, any other tool used in CI pipelines can cause things to break if you don’t pin them.
    - danuker 4y ago
      Indeed. Something wihout security impact will use pointless resources when you update. Do it rarely (or never if possible).
4y ago

mlinksva 4y ago

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 https://www.swift.org/about/#safety Another aside, the author gets some points for looking at Pony.

georgelyon 4y ago
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. 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/c7b07923f7a800674bc9745ae45ddc7f https://gist.github.com/GeorgeLyon/c7b07923f7a800674bc9745ae...
- kibwen 4y ago
  > Whereas Rust (if I remember correctly) allows arbitrary panic-ing and catching of panics While it is possible to "catch" a panic in Rust, this is not an error-handling strategy, it is a correctness fallback. The intent is that, if you're writing a Rust library that exposes a C ABI, you halt the panic at the boundary of your library, because there is no standardized cross-language unwinding scheme and so unwinding across an FFI boundary would be UB. It's not there for error handling (and it can't be, not only because the API is deliberately designed to discourage it, but also because Rust programs can be compiled in a mode where panics abort instead of unwind). > Swift forces you to acknowledge a possible panic at function call sites using “try”. Without “try” control flow can’t suddenly end. This is a bit inaccurate. You can absolutely do things like divide by zero in a Swift function that isn't marked as `try`, which will crash the program. This is the same behavior that is expected of panics in Rust.

lamontcg 4y ago

> Rust: I'm not afraid to admit it - Rust is just too complicated for use as an aging and cranky solo developer. I'm nearly 51 and currently learning Rust. The first 10 hours of it were horribly slow, but it isn't as steep of a learning curve as Optimal Control Theory.

nu11ptr 4y ago
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.
- moldavi 4y ago
  Easier than C or C++ for sure. But I definitely wouldn't say that Rust as easy as a GC'd language like Java or Go. They have strictly less constraints to deal with, they can let you use the simplest pattern for the situation, and (in my experience) they have less superfluous refactoring sessions due to the overly conservative nature of the borrow checker. I like how Matt Welsh put it in https://mdwdotla.medium.com/using-rust-at-a-startup-a-cautionary-tale-42ab823d9454 https://mdwdotla.medium.com/using-rust-at-a-startup-a-cautio...: > What really bites is when you need to change the type signature of a load-bearing interface and find yourself spending hours changing every place where the type is used only to see if your initial stab at something is feasible. And then redoing all of that work when you realize you need to change it again. Perhaps you're instead speaking of a specific situation or kind of program where the borrow checker happens to be no harder than any other language?
- tgv 4y ago
  In my experience, it depends heavily on the kind of thing you're writing. I could write some small programs in it, no problem: a rather complex, text-based calculator was easy and elegant to write with function arguments, a game server monitor, some tools for a cryptography course, an FFT analyzer that reads from WAV or AIFF, etc. Then I tried to port my rather efficient Earley parser (https://en.wikipedia.org/wiki/Earley_parser https://en.wikipedia.org/wiki/Earley_parser) from C. Constructing the item set efficiently wasn't that hard, but constructing the forest (set of syntactic trees) was. In C, it was basically free by using some pointer sharing, but I couldn't get that done in Rust. Perhaps there's some clever trick I couldn't think of, but I couldn't get it anywhere near C's speed. And since the ultimate goal of that parser includes further memory shenanigans (unification of results yielded by the rules), I dropped the project. At my job, I'm writing in Go. I fairly sure I could easily port the C code to that. It would probably run a bit slower, but the algorithm and data structures would be readable, and extendable. So: it depends.

seanwilson 4y ago

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

christophilus 4y ago
Nim is not really functional. Like most modern languages, you could probably pull of a functional style with it, but it's mutable, imperative, etc.
- sanxiyn 4y ago
  OCaml supports mutability well. Basically, you can write OCaml as if you are writing Nim.
klohto 4y ago
Same way you avoid them directly in JS. I don’t think Nim claims it’s easy to do.

jopython 4y ago

Nim does not have a native ssl and regex lib in the standard library like golang or python. These libraries are taken for granted nowadays.

firesloth 4y ago
It doesn't? https://nim-lang.org/docs/re.html https://nim-lang.org/docs/re.html and https://nim-lang.org/docs/net.html https://nim-lang.org/docs/net.html are part of nim's standard library. Are they missing something you expect?
- jopython 4y ago
  They are dependent on pcre and openssl respectively unlike Golang which is native.
  - cb321 4y ago
    Well, sure Golang, but to be fair they are not native pure Python in Python's stdlib either... This is more broadly relevant since part of the appeal of Nim is its easy C/C++ interoperability (by generating to these and so only requiring some declaration).

nu11ptr 4y ago

> 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 4y ago
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
- insanitybit 4y ago
  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 4y ago
    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

v3ss0n 4y ago

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.

cdaringe 4y ago

> 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 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 4y ago
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.

germandiago 4y ago

This comparison looks more like a discourse than anything else IMHO.

anta40 4y ago

Hmm.. wonder why Pascal isn't on the list

TylerE 4y ago
Because it’s 2022 not 1982? There hasn’t been a new Pascal standard in 34 years.
- anta40 4y ago
  Not sure about the current state of ISO Pascal, at least there's no ISO D or Rust, either. D and Rust are defined by the official implementations. On the other side, Delphi is still being enhanced and FPC tries to be compatible with it, so there are not stuck in 1982.
- kcartlidge 4y ago
  I do C#, Go, Python, Node, Ruby, etc., but Free Pascal with Lazarus is my #1 choice for any cross-platform desktop app that needs a decent GUI without using Electron. It's free, fast (enough), and exceptionally easy. If you need a supported system then even Delphi is back to being (not totally un)reasonably priced once you consider that they only charge when you begin earning from it. Their threshold is very low, but by the time you reach it you've tested your idea and got sales. As for Pascal standards, I'm not entirely sure why there would need to be a recent one. Standards bodies have their place, but their activity is pretty much never something I ever give a thought to when deciding on software tooling.
  - TylerE 4y ago
    Standards can be overrated, sure, but some things like Unicode support really need to be done rihht
  - anta40 4y ago
    I think Pascal implementations are practically dominated by Delphi and FPC these days (FPC has Delphi compatibility mode). On the other side, there are more players in C/C++ club: GCC, Clang, MSVC, Pelles C, LCC Win32, AMD C++, Intel C++, etc. Having a standard is certainly useful.

deleted 4y ago

[deleted]

StillBored 4y ago

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 4y ago
> 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 4y ago
> 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.

MrBuddyCasino 4y ago

> 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. Chef‘s kiss.

ezquerra 4y ago

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.

drewm1980 4y ago

"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." You're embarrassed to have worked at Microsoft but not on crypto pyramid schemes?

ksec 4y ago

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.