I'm surprised no new languages focus on ecosystem. It is much less fun than making clever syntax I suppose.
Most new languages that I know of have a package manager/inbuilt dependency resolution mechanism and a fairly robust module system to try and support 3rd party dependencies.
Rust, Go, Dart, D. You can expect every language post 2010ish to have this.
The same can't be said of slightly older languages like C#, Java, or python. Perl, for all its foibles, was probably the first language with a more modern package management system (CPAN).
The problem is if you don't consider these things in your initial design, the solution you end up with later tend to be worse.
So, ultimately, all people are saying when they knock Go's package management is that they don't like how it works. That's fine, I don't like how all sorts of things work. But "nothing" is false, and "hacky" is so subjective as to be practically worthless. Obviously, the reason Go gets picked out in these discussions is that it's quite successful as a language, and, to me at least, it follows obviously that they solved package management to some level of the community's satisfaction, because languages without package management aren't successful.
If we wanted to hash out the pros and cons of different package management strategies, that's all the thread will be: just hundreds of back-and-forth messages about package management. It's a big topic.
When I wrote Go, the official language policy is that you do not need versioning and should not make breaking changes. Throw everything into a vendor/ if you must. For me, that kind of stance on package management definitely warrants attention.
There are lots of things I don't like about NPM. But imagine claiming that Node doesn't have real package management. You can't even write a for-loop in Node without a package. Go isn't quite that far gone, but it's pretty hard to write idiomatic Go of any significance with zero packages.
But they really did launch with no solution and take a fairly long time to figure it out.
I think nix might be the way--just have one package manager to rule them all--but I'm not aware of any language ecosystems that are leaning into this.
Yup, the alternative is a C/C++/or Haskell scenario where instead of one generally accepted "right" package manger you end up with 20. You might get lucky like Java did with maven but that's no real guarantee.
> but I'm not aware of any language ecosystems that are leaning into this.
Bazel does. However, bazel (AFAIK) generally does things by leaning on the existing build systems of various languages.
For software, unfortunately we are in a "jack of all trades master of none" scenario. I don't think there's a one size fits all solution.
To be fair, Haskell doesn't have 20. It has two.
But yeah, fair point. And maybe we can rely on newer languages to converge on a package manager faster than the languages of old did due to the internet.
It's just kind of awkward how they all do the same thing in slightly different ways. But not meaningfully different.
They all have some kind of lock file, and they all have some kind of cache that you have to handle specially if you don't want to download the universe in CI, and they all let you specify version restrictions but each uses different files to store these things, terminology to describe them, and uses a different configuration language for you to express them.
Learning languanges would be so much fun if I didn't have to learn a new package manager each time.
However, I'd say it's a lot better situation than what exists for C/C++ ATM.
(Package name, version number) -> (cryptographic hash of package bits)
Both is, and ought to be, table stakes for modern language ecosystems. But when it comes to tooling for hosting, fetching, installing, and contributing re: those maps, there's no reason to have each separate language community build an overlapping set of tools that solves those problems.
I understand that when you have a new language, building all of that tooling is probably a fun way to flex it, but it's a bigger problem than most language communities really have the interest in to solve properly. So it ends up being a hack job every time.
I'd argue that the only reason Java doesn't feel like a hack job re: packaging is that they've (wisely) solved a smaller problem. I can use pypi to install a python package with Java dependencies, but I can't (so far as I know) use maven to install a java library with python dependencies.
Better would be to have some lightweight standard for mapping package names to hashes, and then decouple the hosting/trustworthyness indicating/installing/packaging concerns such that language designers don't have to worry so much about those things since they're not really language specific problems.
Frankly, I wish new languages focused more on flexibility and expressiveness even if that made things harder up-front!
Design languages for experts, not beginners. It might be more difficult to get started but if it's well designed it pays off.
Honestly, this is a lot of the draw of Go and Rust for a lot of people; other than debugging (which I can't speak to from experience, but as I understand it, both are on par with C++), the points you hit on above are all things Go and Rust have really solid answers to compared to their contemporaries.
Yes.
I disagree. You can get up and started in most language stacks fairly quickly. Keep focus, learn to sort advice into helpful and unhelpful buckets, and start building with a goal in mind.
For example - I hadn't touched fennel nor Love2d until about a month ago, and we made something happen.
You can do this too.
In contrast, I spent a ton of time trying to build other lisps that are designed to be embeddable on those consoles and got nowhere.
Fennel rocks. Such a pragmatic and well designed mini-language.
The article is about what it takes to really know a language. That's a bigger task. It takes months, if you work fast. That's how you write high-quality, maintainable software.
You can do this too.
In a way it is. After all if i make a new language, i can control what it can do and how it evolves but i can't control other people to force them use it.
All of them?
Go, Rust, Kotlin, TypeScript