I was pleasantly surprised to see support for Nim as a task language! very cool! Particularly considering your target market of developers with corporate education budgets, I expected a much smaller set of mainstream languages.
Thank you! Our language support mechanism is OSS, and we welcome community contributions. It's designed in such a way that you don't strictly need to have knowledge of the course material to be able to add support for a language.
Nim tried regions based memory management and ended up going a different direction. The feature still exists, but the core devs ended up considering it a bit of a dead end: https://forum.nim-lang.org/t/6930
As I said in another comment, the familiar python like syntax, while having the potential for much better performance.
Many data scientists are familiar with Python. They can write similar code and will run much faster by default (or with very little tweaking).
Then, if that's not fast enough, The language is positioned such that you can optimize the code to a much higher degree than you can with Python.
I'm not saying that Python code can't be optimized, but there is a limit to the speed of python code even with optimization. At some point you have to drop down to a C extension (what Numpy, Pandas, etc... does) and then you are just writing glue code in Python to drive the C. You could also use one of the Python optimized compilers, but that has limits and edge cases as well. There is "developer friction" there.
In Nim you can just have the whole program in one language. The program can be optimized to the same level as optimized C code with no special tools. This is much less friction.
What's missing is the libraries. But that will come with time.
It isn't acceptable to just permit memory-leaks in case of cycles. There's no way we'd ever see something like that in a serious JVM.
Unless there's some serious machinery to provide assurances against reference cycles, of course. Which sounds like an interesting research project, come to think of it.
> It isn't acceptable to just permit memory-leaks in case of cycles.
That's only in the new --gc:arc which is still somewhat experimental. The old gc, --gc:markandsweep IIRC, does detect cycles, and has a deadline schedule (i.e. you can tell it "I now have 5ms, collect as much as you can"); But it has per-thread heaps, which means passing data between threads often entails a copy. You also have --gc:boehm (no cycles, shared heap), and --gc:none (no gc, you should take care of freeing memory yourself).
The major features are: Python like syntax, Lisp like macro system, potential for C like performance (YMMV of course).
This is my person opinion here:
Nim is part of the "new generation of system programming languages" from the last decade or so. Some other examples in this category include Zig, D lang, Go lang, Swift, Rust, etc...
The whole idea is to provide "modern high level" language features and ergonomics while still producing efficient low level code.
For Pythonistas, The familiar syntax is attractive to Python programmers looking for a more performant language (data science is a prime example.)
Nim is also attractive to lispers looking to move to a more traditional Algol or C like language while still keeping much of power and flexibility that they are used to from macros.
Do you think the gcc -std flag would exist if every distribution of gcc included a command to easily download alternate versions and swap them out depending on project configuration? -std seems more like a bandaid around a difficult install/config than a feature, in my opinion.
Obviously nim is free to make implement whatever options they want, but it seems to me like every second spent triaging/fixing/etc bugs about not properly maintaining broken things (not to mention the end user time spent experiencing them and debugging them!) is time that could be better spent improving the language.
Yes, the -std flag would definitely still exist: the thing being changed by that flag is a lot of stuff in the parser, some stuff in the standard library, and some semantics bits further towards the backend, but at some point the versions converge and go through the same optimisation pipeline. A pipeline that definitely has seen improvements in more recent versions, so it's totally worth it to use a new compiler with an old language standard on old code: it might very well produce a faster executable. Just using an older compiler would also revert back to the old performance.
Additionally, a C/C++ compiler in an older standard mode would disable certain features, of course, but not completely: it's still able to give diagnistics in the vein of "this thing isn't valid with the current version setting, but it would be valid in C++17", for example. That's useful to a programmer.
A newer GCC will likely have better optimizations, better safety checks, or what have you that would benefit old codebases using older versions of C's syntax. Similar deal with a newer Clang/LLVM, for that matter.
That is, if we had a GCC version manager that worked the same way things like choosenim or rustup or pyenv or rvm or what have you work, I can guarantee you GCC will ship with an -std flag, because you can bet someone needs to compile a C89 codebase and wants the latest and greatest compiler smarts to do it. Same deal for Clang, or Visual Studio, or `zig cc`, or whatever.
Great example of this (that I just had to deal with this week, lol) is Wine, which mandates C89-compliant code, and yet absolutely benefits from any compiler optimization improvements introduced with newer versions of GCC.
I would say gc:arc beta quality. Very usable for many programs, but needs more battle hardening. Please try it and send bug reports if you find them! That's how we improve!
