Curious to know the rationale behind the "batteries not included" approach.
One of the advantages of Go imho is it's solid stdlib, which includes production-ready HTTP server/client, JSON, XML, crypto libraries and more.
One of the advantages of Go imho is it's solid stdlib, which includes production-ready HTTP server/client, JSON, XML, crypto libraries and more.
• One size does not fit all. Rust targets many different environments, including embedded and WASM. A big stdlib makes porting Rust harder. It's already problematic, e.g. `std::fs` makes no sense in a browser context, and std's out-of-memory handling strategy was unacceptable for the Linux kernel.
• Rust is judged by the size of its "Hello World!" executable, which already looks pretty fat due having stdlib linked statically.
• Rust has a strong backwards-compatibility guarantee, which means that anything stabilized in stdlib has to stay, forever, and can't evolve. Not many features can be nailed on the first try, and not nailing them means people will forever debate whether to use the worse-but-standard version or a 3rd party version.
• Rust has already dodged some bullets, because 3rd party `serde` turned out better than Rust's old built-in `rustc-serialize`, `syn` won over Rust's `syntex`, `criterion` is better than built-in `bencher`, `rand` had 8 major revisions, `time` broke compat 3 times, etc.
• Rust is stuck with `std::mpsc` which turned out to be slower and less flexible than `crossbeam-channel`.
• Rust team is not an infinite resource.
• The Rust language is designed to be extensible via libraries, unlike Go where e.g. maps, channels, range iteration are special built-ins you can't replace.
If libraries are initially kept outside of the standard library they can compete, gain and lose support, and a clear winner will eventually surface. Old patterns can continue to exist and be support without breaking changes while new, better APIs can incubate. In time, after they've proved themselves, then they can be pulled into the stdlib.
When it isn't included in the stdlib then a new developer needs to always ask "is this the recommended library?" In some of my projects I'm still using a few libraries that might not be the preferred community solution anymore, they are still very well supported. When a winner becomes more clear then I can migrate.
It comes down to two different approaches. Both are valid, both have their advantages. I prefer rust's conservative approach to the stdlib but I understand why someone would rather less reliance on shifting 3rd party libraries.
Compare it with Java's logging framework hell. java.util.Logging used to be near-unusable, and the resulting cambrian explosion of logger frameworks continues to this day. Using a library will make you depend on some logging framework. So it is today normal for a Java program to contain 4-5 different logging frameworks, passing messages to each other.
"Not enough" or "too much" is relative to your use-case. Go is almost purpose-built for web servers, whereas Rust is much more general and lower-level. It's got excellent built-ins for core data structures, async primitives, etc (which makes it much more batteries-included than C), but many (most?) of Rust's users don't need an HTTP server or JSON parsing
It's a judgement call. I think they struck a pretty good balance, especially considering the vibrant ecosystem and breezy package management that can help fill in the gaps, but it's never going to be perfect for everybody's usecase
https://docs.python.org/3/library/csv.html#csv.Sniffer
This feature runs some heuristics and invents a new dialect of CSV based on a sample of the file. That should send chills down your spine, there is literally no safe way to use this thing. Using it in production is a bug in and of itself and will likely lead to security issues.
How many Rust packages work on IBM i?
IBM i was a random example, there are plenty of platforms out there.
But if you're working in an environment where Rust support is poor and Python support is rich, then yeah it totally makes sense to choose Python over Rust, I'm not any sort of absolutist.
Have you had a different experience that's leading you to these views?
> crypto does change
A nearby comment mentioned Python, which did have that problem. The ssl module on its standard library didn't verify certificates by default, and since that's no longer considered good cryptographic practice (to put it mildly), that behavior had to change, even though it could break existing code. See for instance https://access.redhat.com/articles/2039753 and the several PEPs it links to, in particular https://peps.python.org/pep-0466/ which is about the backporting of the Python 3.x version of that module to a patch release of Python 2.7.
Why would you say that? Do a cycle of deprecate + remove every few major releases, provide a migration path, and you're good.
Editions currently don't allow existence of multiple standard libraries, because code from different editions can be mixed.
Neither of these things have ever been done, though they have been proposed, and it's just up to the library team to determine if they ever think it would be worth it to do so.
Seems like this would be a great way to deal with deprecated stdlib functionality. Especially in the case that there is a better replacement available. Ranges and channels would be obvious candidates for this.
Channels appear to be trickier, but it might be possible to upstream crossbeam's version of those as well (it's certainly been proposed and discussed for years).
Designing Cargo was outsourced for a similar reason AFAIK.
As for cargo, what we have today is literally Rust's third package manager, after the experience with using the first two led people to conclude that they just needed to hire domain experts to design and implement it (the bundler folks).
Rust's language design decisions are more of a cathedral; the language feels cohesive and carefully put together, like a delicate puzzle. They're slow to adopt language design decisions, leaving them in an unstabilized purgatory until a very high degree of confidence is developed that it's the right decision. Rust's approach to dependencies is more of a bizarre; you're expected to go to crates.io and work out what dependencies to adopt for just about everything.