[jamieson-becker]

Nim is an amazing language. The syntax is cleaner (IMO) and easier-to-read than Go and approaches Python in its readability, which is impressive for a statically typed, compiled language[0]. The design is focused on performance above all else, but it still has metaprogramming[1] and functional features.

However, Go and other languages have a huge ecosystem and many more libraries. Nim only has a few web servers/frameworks, for example. Even if Nim's web frameworks/servers (like httpbeast) are quite fast[2], they lack the completeness that exist for other languages.

Until then, if you are looking for a systems programming language, you owe it to yourself to investigate Nim[3], alongside Go, Crystal, Julia, D, Rust, Haskell, etc. The tooling is fantastic and the Nim compiler produces clean, cross-platform C code (or JS[4]!) that can be automatically fed into gcc, clang, mingw-w64, etc. It's a language that's undergoing rapid changes, but almost all of the changes are in the libraries and it's exciting to see all of the innovation there -- and as libraries increase and mature, it will become a really compelling application language as well.

The community is extremely active, and issues are promptly dealt with. For HNers, it's an opportunity to still make a huge difference by contributing to a relatively young language, compared to getting drowned out by all the noise in a more mature language community.

0. https://nim-lang.org/docs/tut1.html

1. https://en.wikipedia.org/wiki/Metaprogramming

2. https://www.techempower.com/benchmarks/

3. https://nim-lang.org/features.html

4. https://picheta.me/snake/

[nepeckman]

Honestly I think Nim is more compelling as an application language than a systems language. I know there are plenty of people that care about Nim in the embedded space and are improving the experience of GC-less Nim. But for me, Nim with GC strikes a nice middle ground between speed of development and speed of execution. I can hack a project together quickly and get a native binary that executes much quicker than a scripting language. Its definitely my favorite language for hobby projects and I'm looking forward to the 1.0 release.

[dom96]

Couldn't agree with you more here. I personally use Nim as an application language too and it will take a lot of convincing to let me go of the precious GC :)

[leshow]

> Until then, if you are looking for a systems programming language, you owe it to yourself to investigate Nim[3], alongside Go, Crystal, Julia, D, Rust, Haskell, etc.

Go, Crystal, Julia, Haskell and Nim all have a runtime that sort of precludes their use as a true systems lang. I agree with your other points, and I like Nim, I wish it was more popular, but I can't convince myself it's worth the time investment to learn it. I know Rust and Haskell already, between those two there isn't much space where Nim would be a good fit that the others aren't.

[pjmlp]

Luckly not everyone thinks like that.

http://www.astrobe.com/default.htm

https://www.wildernesslabs.co

https://www.ptc.com/en/products/developer-tools/perc

[leshow]

It's great that there are a few projects that enable writing software for embedded devices in some languages you don't usually see in the space, but projects like this do not suddenly make the lang a 'systems language'. You wouldn't want to write an OS in Java or C# or any language with a GC & runtime really.

Nerves is also a wonderful project, enabling the use of elixir for IoT devices, but nobody would claim elixir is a systems lang.

[caseymarquis]

Microsoft actually created an experimental managed OS: https://en.m.wikipedia.org/wiki/Singularity_(operating_syste...

[echelon]

Minor nit. Every language you mentioned with a GC is not a systems language.

[pjmlp]

Having a GC is not an impediment for systems language, for example:

- Algol 68

- Mesa/Cedar

- Sing#

- System C#

- Modula-2+

- Modula-3

- Oberon

- Oberon-2

- Active Oberon

- Oberon-07

- Component Pascal

- Lisp (regarding Lisp Machines and its derivatives)

- Java (when deployed bare metal on embedded devices, e.g. Aicas, PTC)

- Swift

- D

- C# (when used alongside .NET Native, IL2CPP, CoreRT, Netduino, meadow)

[meruru]

That's not a minor nit, that's a digression from object-level discussion to arguing about word definitions.

[tedunangst]

Eh... https://github.com/mit-pdos/biscuit

[rurban]

Your argument that a systems language must be memory unsafe relates only to current practices but not to science. science would rather prefer memory safety in systems.

[sl1ck731]

Go is a systems language. The term isn't confined to device drivers. It includes platform/backend software such as web servers and things like message queues or the Docker ecosystem.

The term is nebulous though.

[echelon]

That's wrong! Those fall squarely in the application domain.

By your argument Ruby and Python are also systems languages because they can be used to write servers and job queues.

You're not doing real time programming with Go. Don't make systems programming lose its meaning by promulgating this myth.

[sl1ck731]

Real-time programming can be done in any language, Java for example.

I think you're conflating writing device drivers/kernels with systems programming, which includes those things but is not limited by them.

Regardless, the term's meaning can't be lost if its apparently this hazy.

[zepolen]

I don't think you understand what real time programming is.

[sl1ck731]

Enlighten me, please.

https://www.aicas.com/cms/rtsj

http://blogs.windriver.com/wind_river_blog/2017/05/java-on-v...

[nimmer]

Wrong. A system language should at least build shared objects for other languages. Nim can, Go cannot.

[0815test]

> For HNers, it's an opportunity to still make a huge difference by contributing to a relatively young language

It would be better for someone to work on an alternate, Python-like input syntax (focusing on readability and good intuition, and perhaps more attractive to novice programmers) for some established language, like Rust. Working on a "young" language, you just miss the chance of contributing to an ecosystem that's already been in development for quite some time, and where efforts aren't going to be left stranded as the bulk of the dev community chooses to go for something else.

[jamieson-becker]

> for some established language, like Rust. Working on a "young" language, you just miss the chance of contributing to an ecosystem that's already been in development for quite some time

Would you still make this point if you were comparing...

for example, Rust and C++?

... where Rust is the "young" language? Working on such a young language (and, FWIW, Rust is younger than Nim), you might miss the chance of contributing to an ecosystem that's already been in development for quite some time.

Not every language grows up with a silver spoon from Mozilla or Google.

[0815test]

Given that C++ is widely regarded as having unfixable problems (and even the ISO-C++ community is now basically admitting this, with the C++ Core Guidelines being nothing more than a somewhat pointless band-aid), yes I would. If C++ was fixable, Rust would not exist in the first place. (Same goes for e.g. Ada btw - if you could simply fix both the clear lack of openness in the available Ada toolchains, and its lacking anything comparable to the Rust borrow checker, Rust would also not need to exist.)

I can tell why Nim was created - there is a somewhat widely felt need for a systems language (Nim is clearly targeting C/C++ compatibility) with a more Pythonic input syntax! But it's far from clear that Nim itself as it exists today is a sensible answer to these issues.

[otabdeveloper1]

> is widely regarded

Yeah, citation needed, d00d.

> with a more Pythonic input syntax

A 'more Pythonic syntax' is literally the least important requirement anybody needs in a programming language.

[Symmetry]

There are things about Nim, like the thread local garbage collected heaps, that you can't really replicate in Rust. Sometimes you want garbage collected language because it makes your life easier. Sometimes you don't because you're a library or realtime or you want to optimize the hell out of your code.

[0815test]

Pluggable GC heaps or the like will likely become possible in Rust at some point. We can already see some of the groundwork being provided, e.g. with support for things like custom, user-specified allocators (at a local, not whole-program level - this is not yet in Rust, but definitely in the pipeline!)

It's just a bit silly to couple one's choice of language/ecosystem/etc. to a single memory-management strategy, and the Python/Nim-like choice of obligate GC as an extension to obligate reference counting also seems a bit puzzling. That's basically taking every sort of automated memory management under the sun and compounding their disadvantages - I'd think one can do better than that, in fact even Go or Ocaml do better than that!

[ddragon]

I'd say there isn't really a better general option. Some people may want to target the largest amount of people right out of the gate, some people might want to be a big fish in a (growing) small pound. Some projects might have so many (possibly non core) dependencies that it's too hard to start from scratch without already existing mature tools, some projects you might want to start from scratch anyway so might as well use a more modern language that will give it some edge.

I think the only globally optimal option in hobby open source projects is doing whatever seems more fun for you, and for many people is using that language that no one uses (or making your own language that no one uses).

[steveklabnik]

https://github.com/mystor/slag