[mikeocool]

I was a big fan of go for a while. Though now that I have programmed more swift and rust recently, having a compiler that doesn’t protect against null pointer deferences or provide concurrency safety guarantees feels a little prehistoric.

Though go certainly did a much better job than rust on the standard library front.

[boccko]

Standard library is something you have to maintain for all eternity, with identical API. It had been argued that some concurrency primitives like channels would have been better outside of std (for rust, to be clear). Once dependency management is solved, a small std is beneficial.

[j1elo]

> you have to maintain for all eternity, with identical API

People always tout this as a huge reason for not wanting a too big std in Rust (or "too useful" either), but IMHO that's just talking about reaching theoretical optimals, while leaving the community for years without good guidance via providing a opinionated practical and pragmatic way of doing things. Which I find to be a very unhelpful stance for a tool such as a programming language.

If a design of some std package didn't pass the test of time, and a new iteration would be beneficial, the language can leave its original API version right there, and evolve with a v2, with an improved and better thought out API after learning from the mistakes of v1.

Prime example: "hey we found that math/rand had some flaws, so here is math/rand/v2". A practical solution, and zero dramas as a result of having rand be part of std.

[troad]

Perhaps it would help if stdlibs were be versioned, with the chosen version declared in the project file. For existing languages, a lack of version would simply indicate the original stdlib, meaning nothing should break.

I definitely don't think stdlibs should be changed often, but it seems fairly damaging to a language when things may be added to a stdlib but never removed, no matter how broken or misconceived (see C++).

Rust is a great language, but the poor stdlib + overreliance on crates + explosion of unvetted transient dependencies makes it a hard sell for a lot of projects.

[ok_dad]

I use go because of the large and useful stdlib. I rarely have to reach for an external library, and even then I only consider libraries that are very popular. If a library isn’t available, I’ll just write my own, using the stdlib. I recently used the awesome crypto library to implement an envelope encryption system, I didn’t need anything outside of the stdlib or Google’s x library (x is effectively the experimental stdlib).

Having too much external code, like npm or rust crates, seems like a nightmare for me.

[mook]

Doesn't Rust already have that solved via editions? If anything, that's the language that's especially well positioned here.

[dwattttt]

I believe the stdlib can't be versioned like that: there's only one stdlib linked into a final artifact, you can't have two versions with differing APIs in there.

[estebank]

There's work on edition aware name resolution so that a type with the "nice path" can change over an edition while still accessible through a longer path, but 1) it's not implemented yet, 2) it hasn't been used yet (see 1), 3) if it is ever used it should be done very sparingly (because of the bafflement that can occur if someone follows older docs in the new edition, implementation will come with efforts to mitigate these problems).