Hi,
I've used Nim for over a year and really liked it. Prior to learning Nim, I spent a year learning Rust but gave up because it felt too complex and I kept fighting with the borrow checker and the compiler. My productivity was not good. So I tried Nim and was able to pick up easily and get a lot more done with less time.
With that said, it's my best interest to see Nim gain more popularity and adoption. IMO Rust is its biggest competitor. Rust has become a mainstream language in system programming and got a lot of commercial and community support. However Nim is still very much a niche language.
I think Nim's strength is its well-designed syntax, metaprogramming features and great performance. It lowers the barrier and makes low level system programming accessible to almost every programmer. It has the potential to become widely adopted like Python or Rust. However, with current resources available, there is a long way to go.
Today I'm not going to discuss how to make Nim more popular. I want to pose a question about its long term plan for the JavaScript backend support.
I have a few questions related to that. Please excuse my ignorance if they are silly as I don't know much about compiler design and specifically design of Nim.
Supporting multiple targets in one language is an interesting idea. However I feel that C/C++ and JavaScript are too different from each other and might not be easy to target simultaneously.
It might not be too hard to handle code generation from Nim source to C or JS. But it's a different story to make the same semantics work the same way in both target languages. Variable scope, memory management, GC, compilation and execution etc work drastically different in C and JS.
In C, memory management and pointer operation are at its core. JS has nothing to do with those however. In JS, you don't have direct access to all the OS level stuff like file system, sockets, processes etc. The web standards are slowly making those available to JS but they work completely different from the system APIs available to C I suppose.
Even if we got JS backend support to a somewhat working state, is it going to be able to sustain the ever changing frontend ecosystem? I assume in order to enable people to use Nim-generated JS, we need to be able to call from Nim to native JS code, and from JS to Nim code. In the mean time, we want to be able to use React, JSX, Vue or any new mainstream frameworks.
I can see that TypeScript is gaining market share every day. What's the story if people want to use Nim and be able to use a frontend library written in TypeScript?
A big question I want to ask is, where will Nim be in 5 years or 10 years, especially its JS support?
Will it be close to what we have today? Or it'll use mundane features like native classes, import maps etc? If the answer is former, I feel it'll not attract developers but only slows down Nim's step forward.
It might be a good idea to support multiple targets with one nice syntax. And it might even be possible to support same Nim semantics in the generated code and keep them up to date with latest development in both languages. However if there is not enough resource to make that happen, it might be the right decision to extract JS support out of its core and focus on C/C++/ObjectiveC as the first and foremost target. It might be worth to retain all the good design choices that made C/JS possible at the first place. So that anyone who want to pursue the Nim->JS path can be on their own.
Let me stop here and hear what people have to say. Maybe I'm just too pessimistic about the complexity of maintaining two target languages.
Thank you!
I assume in order to enable people to use Nim-generated JS, we need to be able to call from Nim to native JS code, and from JS to Nim code.
You already can use JS functions/etc in Nim with importjs (also see https://nim-lang.org/docs/jsffi.html), and export Nim code to JS as usual with exportc so Nim doesn't mangle the name and then module.exports or something similar.
The JS backend is 3000 lines of code and it is reasonably stable and is not too expensive to support. It also does support pointers.
In 5 years from now we might have extracted and moved it to its own git repository, nim-lang/nimjs and will come with its own libraries and release cycle.
Will this be on the roadmap of Nim2 or the release after?
You asked for "5 or 10 years from now" and Nim2 is expected to arrive sooner than that. :-)