Nim 1.0

Congrats to the Nim team.

One thing that is frustrating for anyone hearing about Nim for the first time is that it's really hard to look at what appears to be yet another slightly different take on Rust or Go and intuitively understand why it exists.

There is absolutely a grid that can be populated: who started this, is it corporately affiliated, what languages is it similar to, what is the motivation of its creators, what is the philosophy driving its design, is it intended to be an eventual competitor or replacement for languages XYZ, where does it sit on the spectrum between raw assembly and MS Access, is it intended to be a "systems language" eg can you write a kernel or device driver using it, does it require a VM, is there corporate support available, how established is the developer community, are there books and courses, does it have garbage collection, is it a compiled language, is it a strongly typed language, what are the three perfect use cases, how stable is the API, what's the package management story, does it have a reasonable standard library, is there editor support for color coding and linting, what's the job market look like, is the documentation well-written, and most importantly, if we all got in the same room, would I want to hang out with the people excited about this language?

The cost of learning yet another language vs actually spending your finite spare time building something (or with your loved ones, or reading, or sleeping, or making art) is insanely huge.

Well it all started when I wrote the genui macros for wxNim and the Gtk wrappers. I started working on a rather simple note-taking application and had an idea in mind for what I wanted it to look like. Turns out this look wasn't possible in wxWidgets without resorting to custom widgets (because the Windows back-end didn't have support for something none of the others could support it). So I had to switch away from wxWidgets and use Gtk instead, not a huge issue for that project since I was just going to use it for personal purposes anyways, but it made me realise something. There isn't a single cross-platform UI toolkit that allows me to learn that one library and then create UIs for either all the targets, or one specific target. The idea has then gone through many revisions and back and forth on implementation ideas, but the current vision is to base it on Nims powerful type system. So instead of saying that "I want a wxTextCtrl" you say "I want to have a way of editing this string". Then it is up to the target toolkit to have an idea of how a string should be edited. Then any sort of styling of the resulting UIs are done on a per-platform basis, with whatever tools are available for that platform. This will also allow the toolkit "drivers" to take in their own UI specifications (for example Glade for Gtk) and map the types you supply to parts of the UI. Essentially separating the UI generation completely from the code/logic. The benefits of an approach like this is that for a simple UI that is only meant as a front-end for some algorithm you can just specify your inputs and actions and the UI can be automatically generated for you across platforms. If it looks weird on one platform you are able to specify for that platform what modifications to make. Or if you want to create a beautiful shiny graphical application you are able to tailor make every aspect of the UI for the target platform and then bind it back to your code. This is probably already way longer than what you expected, or even wanted, I've been thinking about this and toying around with implementations for a while now. I had an early prototype that created widgets for Gtk and Karax (Nim web front-end toolkit) that worked really well, but I hit some snags with the implementation in an earlier version of the language. Now that the language is more mature, and I'm more used to it, I might finally be able to implement it properly.

Julia discourages Linux distros to package it. They include modified and unmodified versions of all libraries they depend on within the Julia source repository.

I am not quite sure how they are planning to grow within the ecosystem that matters most for many developers.

From a book linked in another comment: https://livebook.manning.com/book/nim-in-action/chapter-1/34

For some reason, a lot of fortran programmers insist on screaming, even though it’s been optional for 3 decades. I mostly program in python these days...