Also, what is its FFI story? How easy it is to interop with C++ and JavaScript?
Corporate support is absolutely essential for a new language to be taken seriously in the industry. If Go weren't associated with Google, people would have laughed that language out of the room long ago. Likewise, it's difficult to imagine TypeScript ever catching on if it didn't have Microsoft's might behind it (even though TypeScript is actually an excellent language).
Without the power of money, you are nothing.
Big tech wants you to think that you're nothing without them, while in truth there are plenty of situations where small realities can absolutely out-compete them:
https://kristoff.it/blog/the-open-source-game/
If you want a proxy variable to observe wrt Zig's growth, look at the star history on GitHub: we are today more popular than Rust was at our age.
https://star-history.com/#ziglang/zig&rust-lang/rust&Timelin...
...and in fact some big tech companies are jumping on the bandwagon, like Uber, but that's an after-the-fact thing.
https://www.uber.com/en-US/blog/bootstrapping-ubers-infrastr...
> If Go weren't associated with Google, people would have laughed that language out of the room long ago.
Nah, Go gets right certain critical things, and that's why is popular. Being from Google doesn't guarantee anything, look at Dart for example.
Which does not say anything given Githubs growth and change in usage patterns from 2010 to today.
Rather, I would say Zig is lagging far behind Rust and it should have had multiples higher stars than Rust at the same time to be on "equal footing" given the multiples larger software community that exist today.
Zig has a VP of Community and it's important how the role promotes and evangelize the language for developers. Another example: Crystal appointment a new Community Manager recently, and now have developer "ambassadors" - to promotion the Crystal language. It's a shame that Nim has no equivalent role or initiave to grow the language community.
And I know plenty of software folks who wouldn't know who he is at all.
This is especially true for a language like Go which had limited functionality and a complete lack of tooling (eg. no package manager, no generics) for a long time.
I didn't pick up Rust until a few killer projects were released. Before that async was a complete mess. For a long time we didn't have the ? operator.
You mean like Limbo?
Nim isn't really known for anything other than being a good general-purpose language. In that sense, it's sorta like Haxe lang.
Other popular languages are T- or M-shaped generalists -- i.e. good enough as a general purpose language but also excelling at 1-3 specialties. You can use these languages for anything but in practice you use them in specific contexts.
* If you're working on a game in Unity3D, you're almost certainly using C#.
* If you're working on ML stuff using Jupyter notebooks, you likely use Python w Pandas etc.
* If you're doing big data processing with Hadoop then it's likely Scala w Spark.
* If you want a very high concurrency messaging backend, then Elixir or Erlang on OTP/BEAM is a good choice.
* If you're making a native iOS app, you don't have to use Swift but you probably will. Same with Kotlin for native Android. If you decide on Flutter instead of native mobile, then you'll use Dart.
However, my boss is never going to make me use Nim, because there aren't any particular use-cases where Nim is known as The Language To Use For That Situation. AFAIK Nim isn't known for any particular libs/frameworks/tools like Django, Rails, numpy/scipy/pandas, PyTorch, Hadoop, OTP, etc.
(full disclosure: I had a hard time finding a good language to replace my Bash scripts and settled on Nimscript, https://news.ycombinator.com/item?id=35756090)
Also *Timing*
Nim came out right after a number of other well-known languages caught on. There are too many other decent and popular languages to choose from. I like Nim, but not a single one of my programmer friends or acquaintances uses it. Whenever I mention it, the reaction is like: "Better to stick with a proven language I know (usually Go/Python/Ruby/Java)" / "Is that like Zig?" / "I'd rather learn Haskell, Rust, or a dependently typed language."
And finally...
I think Mojo is going to hurt Nim adoption.
> I think Mojo is going to hurt Nim adoption.
Mojo is interesting. Python is a genuinely terrible language with an unparalleled library ecosystem. I hope something saves me from the tyranny of Python. But I'm not optimistic.
Nim has the advantage of provably existing and being fully open source.
Well, agree with "other than being a good general purpose language", Nim doesn't have strong marketing point. Remember many years ago Rails attracted lots of developers to learn Ruby?
Hmm I wonder if Crystal will also share the same fate...
But Nim has a pretty solid standard library with clearly written code and an awesome community to help with problems. I generally read a lot of standard library code to expand my knowledge of language and discover common patterns which repeat themselves in a lot of real world problems.
C inter-op is really first class, and as far as i know it has one of best C++ inter-op as well, you can take a look at: https://github.com/jmgomez/NimForUE for a real world example.
I use Nim for my work in both professional and personal capacity and also have written about some of it at https://ramanlabs.in/static/blog/index.html
Nim doesn't GUARANTEE memory safety, so it's basically... better Pascal? It's an iterative improvement that nobody is getting super excited about. Why is it better than D, V, Delphi?
Does a C++ developer have reasons to switch to Rust
and
Does a C++ developer have reasons to switch to Nim
* Cargo for managing dependencies and a sensible module system
* Option/Result based error handling without using null
* Zero (runtime) cost abstractions like iterators and async
I think anything that can generate a trivial hello world program that doesn't leak memory is better than V.
It provides 4 choices: default optional GC (that can be turned off), autofree (either alone or with GC), arena allocation (-prealloc), or manual memory management (-gc none). This flexibility has already been proven, like with their Vinix OS project[2].
Lastly, for developing languages going through alpha and beta phases, think that people should acknowledge how the process works and update their information. Rust or Nim, for example, aren't the same language they were 5 years ago or when still in beta.
[1]: https://github.com/vlang/v/blob/master/doc/docs.md#memory-ma... (4 ways to manage memory in V)
If you use `unsafe` you have to make sure of it yourself, but you can easily grep for this keyword and see where the monsters lurk.
Probably also Rust having a novel memory management model and being backed by a large organisation (Mozilla) had a lot to do with its early success.
"very exciting features such as macro support, pythonic syntax, transpiles to C/C++/JavaScript, no VM, systems programming language, suitable for hard real-time systems etc" is not a good elevator pitch. Its a little bit of everything with no clear focus point.
So I'd say rust had better marketing.
At least it's the reason I tried it once.
It was not a bad experience.
However i do wonder how big the market is for "python, but faster and multicore". I suspect it is smaller than "c but safe".
With Python I can just search "python <thing>" and find popular, well-maintained, libraries to do <thing>. I can't do that with Nim. Most of the stuff I find seems to be 5-9 years old and have no updates since.
Not to mention, everyone aims for those traits. It is not unique enough.
I do have a customer using Python. We had our share of bugs introduced by wrong cut and paste or manual git conflict resolutions after merges for code like
for x in a_list:
if cond():
do()
else:
other()
something()
There is possibly another argument to be made, that Nim is not close enough to Python. Look at how people have gravitated towards Mojo and it being a superset. Therefore, Nim could be argued as kind of trapped in a no man's land, where not of the C family and not close enough to Python to be an easy enough switch over nor strong enough to gain mass appeal with its own identity.
The language not having one clear thing it excels at, surely makes marketing it more difficult, so Nim would have needed more effort than normal to properly explain its philosophy to the market.
Community building and governance is also critical. Nim has a fork called Nimskull that was created because of disagreements in the core team. I don't have any insight on what happened there, but regardless having part of your core team splinter off into a separate hard fork is not good for the growth of the project. This is a HN thread from that time: https://news.ycombinator.com/item?id=32021299
Lastly, it's also a matter of luck. Sometimes you just happen to be working on something that becomes more relevant all of a sudden in a way that you couldn't predict, and some other times this doesn't happen. Zig for example became more relevant once M1 Macs came out because now all of a sudden arm64 is not a "theoretical" target anymore. Now the laptop that you want to use is arm, and so cross-compilation suddenly becomes a real thing to worry about.
> The language not having one clear thing it excels at, surely makes marketing it more difficult, so Nim would have needed more effort than normal to properly explain its philosophy to the market.
Agree on both points! And I am starting to realize that governance is the key element. A better governance would enable better community building and with a big community and a decent governance someone good enough at marketing would be able to figure out a way to put in the additional effort. But hey guys, where can you find a tech community in which we are all pretty bad at marketing and very bad at evangelizing? I think it is a nice value proposition for those who like to build stuff… ;)
I think contributors should focus first on building compelling cases of using Nim in specific niches (like jmgomez is doing for unreal engine) and we should at some point try to meet and start working on the governance issues. It will take some time but I am still confident. The language is such a joy and the community - albeit small - is full of outstanding people.
Btw, you have done outstanding work on zig, congratulations to you, Andrew and the rest of the community, it is inspiring to see! I find very interesting how you decentralize community management empowering people to build their own communities. At least that is what I gather from following from far, I might be off. Would love to know more if that was an explicit goal or the result of some happy coincidences.
Thanks! Having the communities be decentralized was a deliberate decision from early on. Andrew wanted to go in that direction and to me made perfect sense so we never even stopped to talk about it much.
In practice there are two simple considerations that make it a no brainer for us:
- eventually your communities will be decentralized / independent whether you like it or not (eg today there are plenty of python sub-communities depending on whether you use python for webdev, data science, devops, etc)
- a central community hub means that you need to spend money and communication budget on a team of moderators. given how the ZSF financial strategy, we have to stay small if we want to succeed, so that means giving up things like having a moderation team.
I can't just cowboy stuff with $language because other people would need to maintain it.
C# is the de facto language for Unity-based software.
With Go I can cross-compile a single executable blob and distribute that easily to a heterogenous environment. It also does concurrency _really_ well.
Python is the one that the data analysts know how to use
Rust is for those cases where none of the above are fast enough or memory efficiency is a big thing.
What does Nim do?
Also, concurrency is very confusing in Nim. Channels require copying, so you start to look elsewhere. Regular stuff like thread pools and async fit together in confusing ways and it's easy to create multithreaded code that compiles but does not work. It's common to look into a nim "web framework" and have no idea how concurrency works in the framework from the docs or the code. There is one nim HTTP library that does, but I don't think it's very popular.
Nim has excellent C++ FFI. It's not perfect, but capable of wrapping C++ templates, calling constructors, and virtual methods. Though it can be a pain dealing with inner template types and consts. Here's a larger example of C++ interfacing with Unreal Engine: https://github.com/jmgomez/NimForUE
Typescript would be the notable "exception", and even that had huge backing, and I'd still have a hard time believing even typescript has really surpassed javascript in usage.
It's the same with Julia, yes it was clear who it was trying to replace, but it wasn't 10x better.
Rust also stroke a programmers thirst for learning new concepts (or ego).
It’s basically good vs interesting.
In my opinion, Nim's ability to be compiled to C, C++, and JS make materials for new users too defragmented (this also almost occur with Clojure, IMO, though JVM/JS/and now Dart targeting make sense with their various niches). And all the tricky parts like Orc/Arc/no GC.
But I really love the Python + Pascal syntax, to be honest. Maybe even more than Lisps.
I really wish I could buy the new Nim book but it's kinda hard as a 3rd worlder to import dead-tree books. Unfortunate.
Then look at how the community was built (e.g. Mozilla / conferences / forums etc.)
I've only recently started writing rust (after years of C#, Java, JavaScript, Ruby, Python, and a variety of other languages), and once I got past the basics of understanding borrow checker issues I love it as a language. Personally (for reasons unknown) I prefer brackets over indentation based languages, so Nim is a pretty hard sell there.
There are over 50 CLI utilities in Nim at https://github.com/c-blake/bu, many of which do something novel rather than just "re-doing ls/find/cat with a twist". While they are really more "ls/ps construction toolkits" with some default configs to get people going, I think https://github.com/c-blake/lc and https://github.com/c-blake/procs are nicer than Rust alternatives. I mention these since you seem interested in such tools.
Anecdatapoint - I've never heard of literally a single one of the utilities listed on the bu page.
Regarding cligen, right from the start clap wins on producing idiomatic output. Compare: https://github.com/c-blake/cligen#cligen-a-native-api-inferr...
Usage:
fun [optional-params] [args: string...]
An API call doc comment
Options:
-h, --help print this cligen-erated help
--help-syntax advanced: prepend,plurals,..
-f=, --foo= int 1 set foo
-b=, --bar= float 2.0 set bar
--baz= string "x" set baz
-v, --verb bool false set verb
$ demo --help
A simple to use, efficient, and full-featured Command Line Argument Parser
Usage: demo[EXE] [OPTIONS] --name <NAME>
Options:
-n, --name <NAME> Name of the person to greet
-c, --count <COUNT> Number of times to greet [default: 1]
-h, --help Print help
-V, --version Print version
$ demo --name Me
Hello Me!
However, the language itself still seems to be a little in flux (v2.0 is nearly out, and my impression is that v3.0 might finally be a nice stable language) and the BDFL makes some language decisions (and holds some opinions) that I'm not fully on board with, and I think make the language a little less than it could be. Obviously that's subjective though.
I'll definitely keep an eye on it and check back in periodically, but I'm also not going to write any non-disposable code in it for now.
They also need a new BDFL with some tact.
Rust can be argued to be a nice addition to the group. You can view it as "The nicest (in some qualities) in a niche". Nim doesn't have this sort of edge.
While it can use clang as a backend, Nim does not rely upon LLVM support like Zig or Rust (pre-gcc-rust working). Use on embedded devices is fairly popular: https://forum.nim-lang.org/search?q=embedded (or web search).
Latency-wise, for a time, video game programming was a perceived "adoption niche" or maybe "hook" for Nim and games often have stringent frame rendering deadlines. If you are interested in video games, you might appreciate https://github.com/shish/rosettaboy which covers all but Ada in your list with Nim being fastest (on one CPU/version/compiler/etc). Note, however, that cross-PL comparisons are often done by those with much "porting energy" but limited familiarity with any but a few of the PLs. A better way to view it is that "Nim responds well to optimization effort" (like C/Ada/C++/Rust/Zig).
My context: I'm a maintainer of iNim, creator of the Rust channel, No Boilerplate, and a professional python web developer for 15 years.
The features you are excited about in Nim are compromised for the sake of simplicity:
- Macros can't change syntax,
- There's a limit to how real-time the standard language is,
- Compiling to javascript is a nice trick, but if it didn't rely on GC it could compile to webassembly, which is better,
- Ask any advanced python developer: Indentation for syntax is a bad idea at scale. Hell, have you ever used YAML?
What Rust does is a revolution because they solved the problem of memory safety without garbage collection with the Borrow Checker. The knock-on effects are GARGANTUAN.
This was a hard problem to solve, and it makes the language more complex to learn, but it unlocks all the language's superpowers. If you 'cheat' with a GC, you get nothing. Nim started its life, just as most languages did with a GC, and the efforts to keep the syntax the same while offering alternatives are greatly compromised. It's far easier to add GC/RC to a low-level language than it is to remove it from a high-level one, where the whole ecosystem relies upon this behvaviour.
Of COURSE I know about Nim's plugabble GC options. That doesn't impress me at all (though Araq's effort is to be commended). In Nim they are compiler options, in Rust they're libraries. The difference is vital. For example, at a per-variable level, I can choose to reference count with https://doc.rust-lang.org/std/sync/struct.Arc.html if I so wish (I rarely need to because the borrow checker is magic).
If you want python, you can have it inside a Rust macro, sort of like this https://crates.io/crates/inline-python because rust macros CAN change syntax. With Macros and no GC, you can rebuild ANY FEATURE inside Rust, the floor of the abstraction is the metal, and the ceiling is the sky.
This is what Rust is all about: full power to the developer, no compromises. My video on this topic for those interested is: https://www.youtube.com/watch?v=PuMXWc0xrK0
I love both languages, but I can only see one language being the standard next 40 years, and demonstrably so can Linux, Microsoft, Cloudflare, Discord, and many others.
You might want to read this iconic tweet[3]
[1]: https://wasmtime.dev [2]: https://wasmer.io [3]: https://twitter.com/solomonstre/status/1111004913222324225
Emscripten and experimental backends hardly count as support for Nim. Python can run in webassembly by the same token, but no one would. The standard rust compiler compiles directly to webassembly, natively, with the stable toolchain.
In other languages, yes, the js bridge is a problem. However, not only will this be fixed in browsers at some point, but rust is so fast that TODAY yew.rs, a mature wasm framework, is faster than react.
My thoughts are better explained in this video https://youtu.be/P4LMfkFLRsI
Even though I have never used Rust in any significant capacity (tried to do Advent of Code with it, gave up on the first task) I can still tell you what Rust is good at.
I can do the same for C, C++, Java/Typescript, Go, C#, Java etc.
With a bracket, i can easily read the scopes, block of codes. With indentation, it's harder.
- Step 1: Find open bracket
- Step 2: Find closed bracket
With indentation, the algorithm now becomes:
- Step 1: Find something which seems to open a scope.
- Step 2: Scan all indentation level until it's done.
The difference is huge here.
It’s a pretty nice language when the tools work though :)