Live data from Hacker News

Choosing Nim out of a crowded market for systems programming languages

forum.nim-lang.org

51–60 of 271 posts

Re: Choosing Nim out of a crowded market for systems programming languages

#51

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.

Right, I guess I'm veering off topic and going into 'D in its own merits' rather than 'D as a C/C++ replacement'. Fast python vs convenient C.

Re: Choosing Nim out of a crowded market for systems programming languages

#52

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.

Can you explain to us what's the bigger problem we should be addressing according to your opinion sir?

Re: Choosing Nim out of a crowded market for systems programming languages

#53
post #49
post #5

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

I don't know Nim, maybe it's the same? If it is I guess that would probably also explain why Nim hasn't replaced C or C++ either.

Though do note that (academic discussions notwithstanding) refcounting is not what people usually mean by GC in these contexts. Having to put up with refcounting is one thing (people already do it manually anyway), but having to put up with a generational or other complex GC is quite something else.

Re: Choosing Nim out of a crowded market for systems programming languages

#54

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…

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.

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.

Re: Choosing Nim out of a crowded market for systems programming languages

#55
post #34
post #8

Earlier 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…

I have the book, and it's an excellent resource for the language. I might be a little biased because I am a long time Nim user but definitely so are you.

Re: Choosing Nim out of a crowded market for systems programming languages

#56
post #7

The author seems to be very knowledgeable about the different aspects of programming. Whether you agree with his opinions or not, this article I think is a great starting point for learning about many interesting topics. Definitely bookmarked for later.

They sound like someone that is attracted to chasing the high of the next technology to learn rather than picking a language like C/C++ that would have worked and given them way more career stability. Rather than mastering a bunch of programming languages they should have focused on one and built clout as a problem solver that doesn’t see a new shiny tool as a way to label their career. Boring popular language + focu…

Ugh, as a C++ programmer - for the love of god don't choose the language for career stability. Both the language and the ecosystem is horrible. Choose it if you need it work in the domain of your choosing. For me it happens to be the case. If you want to choose a career language go for any of the other TIOBE usual suspects.

I completely agree that if you want to be a career programmer, focus on solving problems for business. But it can be done in any language nowadays.

Re: Choosing Nim out of a crowded market for systems programming languages

#57
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

Re: Choosing Nim out of a crowded market for systems programming languages

#58

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…

C++ codebases are not at all pleasant to maintain. I'm willing to accept a smaller job market in exchange for a much more enjoyable day to day existence.

Re: Choosing Nim out of a crowded market for systems programming languages

#59
post #46

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…

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.

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.

Re: Choosing Nim out of a crowded market for systems programming languages

#60

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.

That's true only in comparison to languages with manual memory management. Higher level languages spare you the burden of being conscious about these things, which means Rust is naturally going to be more difficult to work with than, oh, I dunno, Ocaml.

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.

Post reply on HN