`Included batteries` and type safety are not the only but imho surely the most important criteria for software projects (I am excluding throw-away code and scripts). The article raises an important point but fails to teach the reader about the JVM ecosystem and the .net core ecosystem. The standard libraries of these two zoo's of programming languages vastly eclipse what the discussed languages offer (Go, Python and Rust).
There are many more (optional) technologies coming built-in. Your code will typically depend for 98% on official, trusted and vetted code. It might sound like hyperbole but it's reasonable to state that JVM and .net core have no competition if you select for these aspects.
I know, programming languages and religion... So do whatever you want with this information.
foot note for people not in the know- theres(in chronological order): 1) .Net Framework 2) .Net Core 3) .Net. Basically everything mentioned these days is just .Net, but core is often added because microsoft used such an ambiguous name.
It's not about the sheer number of code you have. It's very easy to just add random stuff and bloat your stdlib, like e.g. Python has done.
You want the right amount of the right libraries that are of high enough quality.
Java is the funniest example you could have given since Guava and Apache Commons, which are alternative implementations of the stdlib exist. Why do they exist? Because the Java stdlib has historically been pathetic in its quality - you still can't parse json, the basic act of opening a file has historically been laughable, etc.
You want at the least the basic building blocks like strings, unicode, collections, datetime, json, web server, http, db handling, regex, crypto, etc. to be good enough to use for 90%+ of projects and/or to provide the right interfaces for 3rd party options to hook into, to maintain compatibility.
Languages that either have incredibly poor implementations of those or don't offer them at all suck, no matter how many xml parsers or telnet libraries they may implement.
> - An extended stdlib which ships versioned libraries which use semver rather than being perma-stable.
Half of the point of an stdlib is that it is a single shared lib so you don't run into the all-too-common problem of having multiple versions of the same lib in your program. Either you bundle all the stdlib multiple times OR you need to rely heavily on complex dead-code-removal which increases startup time (and still have a lot of duplicated binary blob from different versions peer dependencies).
This is why stdlibs almost never _actually_ remove stuff or make breaking changes, because that would make existing programs not compile on the new version of the compiler. This is why in Java you can still call Date methods that resemble the ones present in Javascript (.getYear(), .getMonth(), etc). They were deprecated in JDK1.1 (1997) and still available, today. The alternative is to go through a python3 moment at some point.
Semver the stdlib makes it not that much better than using 3rd party packages.
I was fully expecting a comparison of recent battery chemistries, and forgot the "batteries included" saying being used for programming.
As someone who doesn't use the mentioned languages often, it's surprising to hear that Python's stdlib is inconsistent given how old it is / how much work has probably gone into it.
If you look at any language that has been around a while, with Java being a great example, you'll see many libraries that use an outdated coding style. Compare the different date/time libraries in Java, for example. Evolving these is always a problem, which I think Unison addresses in a way that lets the language evolve without having to carry too much baggage forward, while still not breaking others' code.
Yes! I've never been against languages with batteries included. In fact nowadays I prefer them. It's one of my biggest issues with Rust, but the problem also exists in Haskell. Funnily enough, in Node.js, which gave birth to npm, you can now do many stuff without external dependencies (last one I've seen are the sqlite functions).
But yes, in languages with batteries included sometimes they feel like an afterthought. It's not just Python. Java also used to have a big standard library, with many useful things including GUI programming which has been neglected a little bit.
The trick is, when shipping a new language having a batteries-included std lib is hard to do: what should you select, what is considered good (enough), how much time do you spent on it. This detracts from what most languages try to be. An exploration in novel language/compiler paradigms.
With node, what happened is that it was left to the ecosystem to grow good packages/batteries. Same with golang (see the uuid lib example from 1.27 the other day).
To bridge the gap you could have the language/platform declare some “blessed packages” or even “blessed packages and their versions for each release of the language”.
Ruby is one of the languages to have the most elegant and consistent standard library. It is just few standard patterns to learn to get productive.
I found Python's stdlib confusing. Is it list.sort() or sorted(list)? str.encode('UTF-8') to bytes and bytes.decode('UTF-8'). The string instance is already encoded in 'UTF-8'.
async for item in fetch_data_stream():
print(item)
Using async when infact you are `await`ing for items from fetch_data_stream() generator.
One thing would be shipping interfaces without implementations. Rust could try to ship more traits without implementations, I do see it could be problematic with Rust as they don't try to be opinionated on what you will build.
There is another alternative too, releasing interface only packages, then hoping everyone agrees to use those. JavaScript/TypeScript people actually did this already for one very tricky one, validation, see Standard Schema [1], which was great success. But I would hope to see more, for instance interfaces around typical building blocks like job queues, email sending etc.
Thanks, quite an achievement they got people to agree on the interface. However, for supply chain attacks the danger lurks in the implementation, not in the interface. You could argue that this approach comes with the benefit that one could switch implementation when one library goes rogue, but that is imho too little and too late.
`Included batteries` and type safety are not the only but imho surely the most important criteria for software projects (I am excluding throw-away code and scripts). The article raises an important point but fails to teach the reader about the JVM ecosystem and the .net core ecosystem. The standard libraries of these two zoo's of programming languages vastly eclipse what the discussed languages offer (Go, Python and Rust).
For example, this is asp.net core: <https://learn.microsoft.com/en-us/aspnet/core/?view=aspnetco...>. This is the std lib: <https://learn.microsoft.com/en-us/dotnet/api/?view=net-10.0>. This is EF core: <https://learn.microsoft.com/en-us/ef/core/>.
There are many more (optional) technologies coming built-in. Your code will typically depend for 98% on official, trusted and vetted code. It might sound like hyperbole but it's reasonable to state that JVM and .net core have no competition if you select for these aspects.
I know, programming languages and religion... So do whatever you want with this information.
foot note for people not in the know- theres(in chronological order): 1) .Net Framework 2) .Net Core 3) .Net. Basically everything mentioned these days is just .Net, but core is often added because microsoft used such an ambiguous name.
You miss the point by a mile.
It's not about the sheer number of code you have. It's very easy to just add random stuff and bloat your stdlib, like e.g. Python has done.
You want the right amount of the right libraries that are of high enough quality.
Java is the funniest example you could have given since Guava and Apache Commons, which are alternative implementations of the stdlib exist. Why do they exist? Because the Java stdlib has historically been pathetic in its quality - you still can't parse json, the basic act of opening a file has historically been laughable, etc.
You want at the least the basic building blocks like strings, unicode, collections, datetime, json, web server, http, db handling, regex, crypto, etc. to be good enough to use for 90%+ of projects and/or to provide the right interfaces for 3rd party options to hook into, to maintain compatibility.
Languages that either have incredibly poor implementations of those or don't offer them at all suck, no matter how many xml parsers or telnet libraries they may implement.
Currently we generally have a trade-off between:
- The standard library, which is both trusted/blessed and perma-stable
- A package ecosystem which is neither
I would love to see more exploration of the space in between:
- An extended stdlib which ships versioned libraries which use semver rather than being perma-stable.
- Better support for managing verification and assurance of package ecosystems.
> An extended stdlib which ships versioned libraries which use semver rather than being perma-stable.
You mean like Guava or Apache Commons for Java or Boost for C++?
Pretty sure Deno's stdlib is like this too
> - An extended stdlib which ships versioned libraries which use semver rather than being perma-stable.
Half of the point of an stdlib is that it is a single shared lib so you don't run into the all-too-common problem of having multiple versions of the same lib in your program. Either you bundle all the stdlib multiple times OR you need to rely heavily on complex dead-code-removal which increases startup time (and still have a lot of duplicated binary blob from different versions peer dependencies).
This is why stdlibs almost never _actually_ remove stuff or make breaking changes, because that would make existing programs not compile on the new version of the compiler. This is why in Java you can still call Date methods that resemble the ones present in Javascript (.getYear(), .getMonth(), etc). They were deprecated in JDK1.1 (1997) and still available, today. The alternative is to go through a python3 moment at some point.
Semver the stdlib makes it not that much better than using 3rd party packages.
java JCP ecosystem. JSR (Java Specification Requests)?
I was fully expecting a comparison of recent battery chemistries, and forgot the "batteries included" saying being used for programming.
As someone who doesn't use the mentioned languages often, it's surprising to hear that Python's stdlib is inconsistent given how old it is / how much work has probably gone into it.
It's about backwards compatibility and that the naming conventions weren't stabilized until after a bunch of libs entered the language.
Even when the logging library was introduced, surely someone must have said this is too Java-y.
I think Unison has the most interesting take here: https://www.unison-lang.org/docs/the-big-idea/
If you look at any language that has been around a while, with Java being a great example, you'll see many libraries that use an outdated coding style. Compare the different date/time libraries in Java, for example. Evolving these is always a problem, which I think Unison addresses in a way that lets the language evolve without having to carry too much baggage forward, while still not breaking others' code.
Yes! I've never been against languages with batteries included. In fact nowadays I prefer them. It's one of my biggest issues with Rust, but the problem also exists in Haskell. Funnily enough, in Node.js, which gave birth to npm, you can now do many stuff without external dependencies (last one I've seen are the sqlite functions).
But yes, in languages with batteries included sometimes they feel like an afterthought. It's not just Python. Java also used to have a big standard library, with many useful things including GUI programming which has been neglected a little bit.
> Java also used to have a big standard library, with many useful things including GUI programming which has been neglected a little bit.
Swing was replaced with JavaFX, then JavaFX was removed from JDKs. Long live Swing! But yes, it's extremely nice to have a GUI library out of the box.
The trick is, when shipping a new language having a batteries-included std lib is hard to do: what should you select, what is considered good (enough), how much time do you spent on it. This detracts from what most languages try to be. An exploration in novel language/compiler paradigms.
With node, what happened is that it was left to the ecosystem to grow good packages/batteries. Same with golang (see the uuid lib example from 1.27 the other day).
To bridge the gap you could have the language/platform declare some “blessed packages” or even “blessed packages and their versions for each release of the language”.
Ruby is one of the languages to have the most elegant and consistent standard library. It is just few standard patterns to learn to get productive.
I found Python's stdlib confusing. Is it list.sort() or sorted(list)? str.encode('UTF-8') to bytes and bytes.decode('UTF-8'). The string instance is already encoded in 'UTF-8'.
Using async when infact you are `await`ing for items from fetch_data_stream() generator.One thing would be shipping interfaces without implementations. Rust could try to ship more traits without implementations, I do see it could be problematic with Rust as they don't try to be opinionated on what you will build.
There is another alternative too, releasing interface only packages, then hoping everyone agrees to use those. JavaScript/TypeScript people actually did this already for one very tricky one, validation, see Standard Schema [1], which was great success. But I would hope to see more, for instance interfaces around typical building blocks like job queues, email sending etc.
[1]: https://standardschema.dev/schema
Thanks, quite an achievement they got people to agree on the interface. However, for supply chain attacks the danger lurks in the implementation, not in the interface. You could argue that this approach comes with the benefit that one could switch implementation when one library goes rogue, but that is imho too little and too late.
> it seems that the reason for Rust not having an API to get a stream of random bytes from the OS
This is already in nightly[1]. I don't see what "getting money in peoples pockets" has to do with its stabilization.
[1]: https://doc.rust-lang.org/std/random/trait.Rng.html#tymethod...
Open since 2024. Perhaps if people were paid this would be merged in sooner?
"Already" seems to do a lot of heavy lifting there.
It's also not a trivial problem. Rust supports a few dozen more platforms than CPython.[1][2]
[1]: https://pythondev.readthedocs.io/platforms.html
[2]: https://doc.rust-lang.org/nightly/rustc/platform-support.htm...
The tier 3 list is enormous yea.
Are we really going to keep talking about code in the post-coding era like nothing ever happened?
All that matters now is that your LLM can write reliable code and really that choice has already been made by the corpus of examples.
Go away