A long-time Linux maintainer calls Rust a "cancer" in the Linux codebase and tries to block crucial abstractions from entering the kernel. Another contributor tries getting him banned in return.
"So naturally it created a huge multi-year war, between people who were used to the C way of doing things, and people who wanted to adopt Rust for memory safety."
---
Jacob, it would be interesting to get your views on whether Nim (aka #nimlang) would be a better fit for Linux devs in comparison to Rust. Since Nim consumes C/C++ libraries with ease, it's great for hard realtime embedded development thanks to its new default ARC/ORC memory manager.
{ Both ARC and ORC offer deterministic performance for hard realtime systems, but ARC can be easier to reason about for people coming from Ada/C++/C -- roughly speaking the memory for a variable is freed when it goes "out of scope". }
Of course, developers are also able to disable the GC and handle things themselves. And with Nim, you get a language that takes the best concepts & inspiration from Python, C/C++, Ada, Object Pascal/Modula to create a very disruptive language that is "efficient, expressive & elegant" in that order.
As such, developers can compile their Nim code to C, C++, Objective C, JavaScript in order to have the ultimate versatility as a developer on Linux, Windows, MacOS, iOS, Android & BSD Unix. Thus I truly believe Nim will be a great addition to all Linux devs. ;-)
{ "Nim's memory management is deterministic and customizable with destructors and move semantics, inspired by C++ and Rust. It is well-suited for embedded, hard-realtime systems." }
I think on a project as large as Linux, they care as much about the ecosystem as they do the technical features. And since large companies that contribute to the kernel already employ Rust developers, that probably outweighs a lot of technical considerations once the base needs (performance and memory safety) are met
Understood! I guess for core Linux kernel devs, it makes sense not to introduce a new ecosystem which would just add more complexity in their development processes.
However, I feel Nim will definitely be a good fit at the application & backend level once more user reviews like this Reddit dev reaches the developer masses. ;-) But it can definitely be used in kernel development.
====
{ ** Why I enjoy using the Nim programming language at Reddit. **
Written By Andre Von Houck
.....You can also compile Nim to JavaScript. Just like with TypeScript, you get static typing and can use the same language for your backend and frontend code. But with Nim you also get fast native code on the server.
Writing frontend code in Nim is comfortable because you have easy access to the DOM and can use other JavaScript libraries even if they are not written in Nim.
In addition to JavaScript for the web, you can also compile to WASM.
If you are writing a game or a heavy web app like a graphics or video editor, it might make more sense to go the WASM route. It is cool that this is an option for Nim. Both approaches are valid.
If you’re really adventurous, you can even use Nim for embedded programming. Let’s say you have some embedded chip that has a custom C compiler and no GCC backend. No problem for Nim, just generate plain C and feed it to the boutique C compiler. Making a game for the GBA? Again, no problem, just generate the C code and send it over to the GBA SDK.
Nim is crazy good at squeezing into platforms where other languages just can’t.
This includes the GPU! Yep, that’s right. You can write shaders in Nim. This makes shader code much easier to write because you can debug it on the CPU and run it on the GPU. Being able to run the shader on CPU means print statements and unit tests are totally doable.
There are tons of templating languages out there for HTML and CSS but with Nim you don’t need them. Nim is excellent for creating domain-specific languages and HTML is a perfect scenario. You get all of the power of Nim, such as variables, functions, imports and compile-time type-checking. I won’t CSS typos ever again.
With Nim being so great for DSLs, you can get the benefit of Nim’s compiler for even things like SQL. This flexibility and type-safety is unique.
All of this is beyond cool. Can your current language do all of this?
Nim is very fast.
Nim does not have a virtual machine and runs directly on the hardware. It loves stack objects and contiguous arrays.
One of the fastest things I have written in Nim is a JSON parsing library. Why is it fast? Well, it uses Nim’s metaprogramming to parse JSON directly into typed objects without any intermediate representations or any unnecessary memory allocations. This means I can skip parsing JSON into a dictionary representation and then converting from the dictionaries to the real typed objects.
With Nim, you can continuously optimize and improve the hot spots in your code. For example, in the Pixie graphics library, path filling started with floating point code, switched to floating point SIMD, then to 16-bit integer SIMD. Finally, this SIMD was written for both x86 and ARM.
Another example of Nim being really fast is the supersnappy library. This library benchmarks faster than Google’s C or C++ Snappy implementation.
One last example of Nim’s performance is taking a look at zlib. It has been around for so long and is used everywhere. It has to be as fast as possible, right? After all it uses SIMD and is very tight and battle test code. Well, then the Zippy library gets written in Nim and mostly beats or ties with zlib!
It is exciting to program in a language that has no built-in speed limit.... }
"So naturally it created a huge multi-year war, between people who were used to the C way of doing things, and people who wanted to adopt Rust for memory safety."
---
Jacob, it would be interesting to get your views on whether Nim (aka #nimlang) would be a better fit for Linux devs in comparison to Rust. Since Nim consumes C/C++ libraries with ease, it's great for hard realtime embedded development thanks to its new default ARC/ORC memory manager.
{ Both ARC and ORC offer deterministic performance for hard realtime systems, but ARC can be easier to reason about for people coming from Ada/C++/C -- roughly speaking the memory for a variable is freed when it goes "out of scope". }
source: Nim's Memory Management
https://nim-lang.org/docs/mm.html
Of course, developers are also able to disable the GC and handle things themselves. And with Nim, you get a language that takes the best concepts & inspiration from Python, C/C++, Ada, Object Pascal/Modula to create a very disruptive language that is "efficient, expressive & elegant" in that order.
As such, developers can compile their Nim code to C, C++, Objective C, JavaScript in order to have the ultimate versatility as a developer on Linux, Windows, MacOS, iOS, Android & BSD Unix. Thus I truly believe Nim will be a great addition to all Linux devs. ;-)
{ "Nim's memory management is deterministic and customizable with destructors and move semantics, inspired by C++ and Rust. It is well-suited for embedded, hard-realtime systems." }
source: https://nim-lang.org
I think on a project as large as Linux, they care as much about the ecosystem as they do the technical features. And since large companies that contribute to the kernel already employ Rust developers, that probably outweighs a lot of technical considerations once the base needs (performance and memory safety) are met
Understood! I guess for core Linux kernel devs, it makes sense not to introduce a new ecosystem which would just add more complexity in their development processes.
However, I feel Nim will definitely be a good fit at the application & backend level once more user reviews like this Reddit dev reaches the developer masses. ;-) But it can definitely be used in kernel development.
====
{ ** Why I enjoy using the Nim programming language at Reddit. **
Written By Andre Von Houck
.....You can also compile Nim to JavaScript. Just like with TypeScript, you get static typing and can use the same language for your backend and frontend code. But with Nim you also get fast native code on the server.
Writing frontend code in Nim is comfortable because you have easy access to the DOM and can use other JavaScript libraries even if they are not written in Nim.
In addition to JavaScript for the web, you can also compile to WASM.
If you are writing a game or a heavy web app like a graphics or video editor, it might make more sense to go the WASM route. It is cool that this is an option for Nim. Both approaches are valid.
If you’re really adventurous, you can even use Nim for embedded programming. Let’s say you have some embedded chip that has a custom C compiler and no GCC backend. No problem for Nim, just generate plain C and feed it to the boutique C compiler. Making a game for the GBA? Again, no problem, just generate the C code and send it over to the GBA SDK.
Nim is crazy good at squeezing into platforms where other languages just can’t.
This includes the GPU! Yep, that’s right. You can write shaders in Nim. This makes shader code much easier to write because you can debug it on the CPU and run it on the GPU. Being able to run the shader on CPU means print statements and unit tests are totally doable.
There are tons of templating languages out there for HTML and CSS but with Nim you don’t need them. Nim is excellent for creating domain-specific languages and HTML is a perfect scenario. You get all of the power of Nim, such as variables, functions, imports and compile-time type-checking. I won’t CSS typos ever again.
With Nim being so great for DSLs, you can get the benefit of Nim’s compiler for even things like SQL. This flexibility and type-safety is unique.
All of this is beyond cool. Can your current language do all of this?
Nim is very fast.
Nim does not have a virtual machine and runs directly on the hardware. It loves stack objects and contiguous arrays.
One of the fastest things I have written in Nim is a JSON parsing library. Why is it fast? Well, it uses Nim’s metaprogramming to parse JSON directly into typed objects without any intermediate representations or any unnecessary memory allocations. This means I can skip parsing JSON into a dictionary representation and then converting from the dictionaries to the real typed objects.
With Nim, you can continuously optimize and improve the hot spots in your code. For example, in the Pixie graphics library, path filling started with floating point code, switched to floating point SIMD, then to 16-bit integer SIMD. Finally, this SIMD was written for both x86 and ARM.
Another example of Nim being really fast is the supersnappy library. This library benchmarks faster than Google’s C or C++ Snappy implementation.
One last example of Nim’s performance is taking a look at zlib. It has been around for so long and is used everywhere. It has to be as fast as possible, right? After all it uses SIMD and is very tight and battle test code. Well, then the Zippy library gets written in Nim and mostly beats or ties with zlib!
It is exciting to program in a language that has no built-in speed limit.... }
source: https://www.reddit.com/r/RedditEng/comments/yvbt4h/why_i_enjoy_using_the_nim_programming_language_at/