Earlier quoted context omitted.
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…
> 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.
Choosing Nim out of a crowded market for systems programming languages
51–60 of 271 posts
Re: Choosing Nim out of a crowded market for systems programming languages
#52I 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.
Re: Choosing Nim out of a crowded market for systems programming languages
#53> 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…
> Because the GC is infectious. As soon as your dependency needs it (and IIRC even parts of the standard library did/do), it becomes painful if not impossible for you to avoid it. Isn't this the same for Nim? The standard library doesn't provide pure functions for parsing strings, it provides functions which generate exceptions. Exceptions use the heap, it's hard to get programs to compile with the garbage collector…
Though do note that (academic discussions notwithstanding) refcounting is not what people usually mean by GC in these contexts. Having to put up with refcounting is one thing (people already do it manually anyway), but having to put up with a generational or other complex GC is quite something else.
Re: Choosing Nim out of a crowded market for systems programming languages
#54The 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…
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.
Companies rarely pay for totally rewrites. Nim compiles to C and offers safety that can work on top of codebases without a re-write.
Re: Choosing Nim out of a crowded market for systems programming languages
#55Earlier quoted context omitted.
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'm learning Rust now, I can say Nim is much harder. Maybe the language itself is simpler, but the documentation is just not very good. Very unpolished and amateurish. I actually forked out fifty quid for Araq's "Mastering Nim" book; it is atrocious. Spelling and grammatical errors on every page. The very first code example did not compile. I also regularly run into utterly infuriating bugs while trying to accomplish…
Re: Choosing Nim out of a crowded market for systems programming languages
#56The 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 + focu…
I completely agree that if you want to be a career programmer, focus on solving problems for business. But it can be done in any language nowadays.
Re: Choosing Nim out of a crowded market for systems programming languages
#57Re: Choosing Nim out of a crowded market for systems programming languages
#58The 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…
Re: Choosing Nim out of a crowded market for systems programming languages
#59The 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…
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.
Re: Choosing Nim out of a crowded market for systems programming languages
#60I 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.
From the other direction, coming from low-level languages: the other problem is that Rust's type system isn't powerful enough to express certain things that you, a competent C programmer, might be fully conscious of...and so you end up needing to fight the type system to get it understand something you're already aware of. To use a classic example, you can understand exactly how the lifetimes work in a doubly linked list but still find it more painful to write in Rust than in C.