[tgv]

The author's experience is based on toy examples. Programming (and designing) in a professional setting is more than that, though. And the solutions are not the same for everyone: writing an Office plugin has different needs than writing a mobile game. For many of us, the availability of tooling and libraries is crucial. I'm not going to reinvent the web server by building on OS sockets or write a graphics rendering engine from scratch.

That said: Nim does look nice.

[matsemann]

Yeah, languages are "easy" to learn when you already know a few from different paradigms. I can skim through the docs of an unknown language and know enough to start writing in it quite quickly. What takes time is to also learn all the tooling, not just the syntax. How do you build it, debug it, deploy it, what frameworks and libraries should you use, and spend time to learn them.

Take javascript, for instance. If you're used to a C style based language with some functional patterns, jumping into a codebase and understand it is quite easy. But around the language itself you also need to know stuff like npm, webpack or similar, how the browser works, http concepts etc etc.

Or python, need to deal with pip, virtualenvs, perhaps poetry, need to understand the limitations to concurrency because of the GIL and how it affects deployments, perhaps django or some other framework, etc.

[cbm-vic-20]

Right. The languages themselves are usually pretty straightforward; 80% of them have a "common DNA" as most other languages, which an experienced programmer can pick up quickly. The ecosystems, on the other hand, have a lot less commonality, though more recent languages like Rust and Go are bundling more of that stuff so it's less chaotic than C and JavaScript.

[mojuba]

Even that is not a problem. Tooling and deployment are the most boring parts of any language.

What's more interesting and what's more difficult to find shortcuts for is understanding the spirit of the language, knowing its weaknesses, bottlenecks and inner workings. The threading model, what's done at compile time and what's done at run time, etc etc. There are so many things you need to learn before you can judge any given language relative to others that you know.

[blowski]

They’re also easy to learn when all you want to know is syntax. What about:

* dependency management and releases

* deploying and running in prod

* footguns that affect performance or security

* libraries for helping development

* language-specific features

etc

[rich_sasha]

I almost chose nim over rust, but then rust is an industrial machine with a ton of weight behind it. Nim may be the better language for my needs but not as good an ecosystem. Sad but true.

[davidkunz]

I agree. I love Nim, it's such a great language but I try to stick to Rust because I have a feeling that's where the industry is headed. And Rust will improve over time, maybe at some point it will be more pleasant to use.

[planetis]

> Maybe at some point it will be more pleasant to use.

Unless there is a complete rewrite of the borrowing rules and thus breaking changes that's highly unlikely of ever happening. Instead of following what the industry promotes, the same industry that lays off thousands of people on a whim, maybe start following community projects. Do what you like most, don't expect them to change to fit your needs and wants and stop trying to get into every trend that is hot. At least that my mantra to prevent having regrets later on. Good programmers have a future no matter what language they use.

[mettamage]

I came to this conclusion as well.

Ecosystem > language awesomeness

Provided that one ecosystem is huge (e.g. Python) and the other one small.

With that said, learning to write production code in a small language allows for certain better developments in mindset (e.g. Stack Overflow? Forget about it) and better in the quirks of the language, which you will see (to a lesser extent) in other languages.

[goodpoint]

The same was said for Linux, Python and many other projects when they were at a very early stage.

By your logic no community-driven project would ever be successful.

[tgv]

No, not at all. These projects were driven without a direct, professional need. That grew them so much, that they became viable in professional settings as well. Nim could get big too, but it has a lot of competition to overcome. Python and Linux were seeded and nurtured in education; that's hard to beat.