Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Choosing Nim out of a crowded market for systems programming languages

forum.nim-lang.org

Post reply on HN
Print view View original

41–50 of 271 posts

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

#41

Post by 127 »

I have done non-trivial things both in Rust and Nim. For big projects Rust seems a little more robust, but for medium and small projects Nim is an order of magnitude faster to develop for. There are still many rough edges, but it's exactly the tradeoffs I would personally pick for my one person small business making tools for artists. So far I have been using Rust and it's alright, but looking very much into Nim to see if I can replace Rust because of the high cognitive load to keep all of the Rust stuff in my head, as I don't really need safety.

Shout out to https://github.com/StefanSalewski/gintro which was super simple to build a simple GUI tool. With Rust I have no idea what to use after trying 5 different libraries.

The downside of Nim seems to be highly unpredictable performance in my experience. With Rust it's much easier to control. This might be a deal-breaker unless I can find some solution to it. Maybe it's just using it more than two weeks and learning the ropes.

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

#44

Post by stephc_int13 »

LAC-Tech wrote: post #24
dataflow wrote: post #14

Earlier quoted context omitted.

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

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…

Anyone who was forced to write Java code on Android at some point suffered extremely painful performance issues due to the Garbage Collector.

I never had any problems with manual memory management, it can be done properly and safely without a GC, so for me the presence of a GC in a programming language is a net loss.

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

#45

Post by BenFrantzDale »

LAC-Tech wrote: post #11
dataflow wrote: 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…

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.

I had one experience with Go. It was slow because the GC kept kicking in. So we won’t use Go again in favor of time-tested C++. GC is a major reason we are using C++ over Go. In my mind it’s a half-speed language. I’m also very put off by Rob Pike’s “Look, we replaced C++!” attitude when he somehow doesn’t seem to grok zero-cost abstractions. C++ has plenty of issues, but it doesn’t have GC and it goes further, providing standard allocators: both PMR for convenience and most use cases, and statically, for truly zero runtime cost.

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

#46

Post by urthor »

ilovecaching wrote: post #13

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.

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

#47

Post by nine_k »

Herbstluft wrote: post #35
ilovecaching wrote: post #33

Earlier quoted context omitted.

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.

People have done (and are still doing) amazing work in Fortran too. Why should we use C or C++ when Fortran was already perfectly fine?

Fortran us better than C and even C++ for its domain, high-performance numerical code. The guaranteed lack if aliasing allows for optimizations not always possible in C code. Built-in handling of stuff like complex numbers and even range types in modern Fortran (that is, supported for last 25-30 years), along support for parallelization, and with robust structured / procedural programming, is just the right tool for some jobs.

BTW if you run fancy modern stuff like numpy, you run quite some Fortran, because it includes, for instance, BLAS.

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

#48

Post by tomrod »

sigzero wrote: post #18
tomrod wrote: post #12

Earlier quoted context omitted.

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.

https://nim-lang.org/sponsors.html

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!

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

#49

Post by randbox »

dataflow wrote: 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 turned off, so everyone just recommends using ARC.

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

#50

Post by 3a2d29 »

LAC-Tech wrote: post #24
dataflow wrote: post #14

Earlier quoted context omitted.

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

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 more systems programming jobs (where GC is not usable) today than there was years ago. The percentage of all programming jobs that they make up is smaller, but the absolute number is bigger: https://www.toptal.com/c/after-all-these-years-the-world-is-...

Not saying the original poster is this type of person, but I actually work with a lot of recent bootcamp grads and you be surprised how many think C is totally not used anymore. To many of them, the whole world is written in python and JavaScript.

Post reply on HN