[WuxiFingerHold]

> IMO any system where taking a dependency is "easy" and there is no penalty for size or cost is going to eventually lead to a dependency problem.

Go and C# (.NET) are counterexamples. They both have great ecosystems and just as simple and effective package management as Rust or JS (Node). But neither Go or C# have issues with dependency hell like Rust or even more JavaScript, because they have exceptional std libs and even large frameworks like ASP.NET or EF Core.

A great std lib is obviously the solution. Some Rust defenders are talking it down by giving Python as counter example. But again, Go and C# are proving them wrong. A great std lib is a solution, but one that comes with huge efforts that can only be made by large organisations like Google (Go) or Microsoft (C#).

[athrowaway3z]

No it doesn't.

A large stdlib solves the problems the language is focused on. For C# and Go that is web hosts.

Try using them outside that scope and the dependencies start to pile in (Games, Desktop) or they are essentially unused (embedded, phones, wasm)

[Xeoncross]

> A large stdlib solves the problems the language is focused on

That's part of it, but it also solves the problem of vetting. When I use a Go stdlib I don't have to personally spend time to vet it like it do when looking at a crate or npm package.

In general, Go & Rust packages on github are high quality to begin with, but there is still a pronounced difference between OS packages and what is approved to be part of the language's own stdlib.

It's nice to know thousands of different companies already found the issues for me or objected to them in reviews before the library was published.

[dgb23]

“Web server” is a pretty big use case though.

But I agree that graphics is often overlooked in std libs. However that’s a bit of a different beast. Std libs typically deal with what the OS provides. Graphics is its own world so to speak.

As for Wasm: first, that’s a runtime issue and not a language issue. I think GC is on the roadmap for Wasm. Second, Go and C# obviously predate Wasm.

In the end, not every language should be concerned with every use case. The bigger question is whether it provides a std lib for the category of programs it targets.

To take a specific example: JS isn’t great at efficiently and conveniently generating dynamic HTML. You can go far without (or minimal) dependencies and some clever patterns. But a lot of pain and work hours would have been saved if it had something that people want to use out of the box.

[merb]

actually dotnet also does not need too many dependencies for games and desktop apps.

[zahlman]

>A great std lib is obviously the solution. Some Rust defenders are talking it down by giving Python as counter example.

Python's standard library is big. I wouldn't call it great, because Python is over 30 years old and it's hard to add things to a standard library and even harder to remove them.

[notpushkin]

There are things added from tine to time, but yeah, some stuff in there just feels dated at this point.

I’m still hoping we can get a decently typed argparse with a modern API though (so much better for tiny scripts without deps!)

[kokada]

While not everything in Python's stdlib is great (I am looking at you urllib), I would say most of it is good enough. Python is still my favorite language to get stuff done exactly because of that.

[nicce]

Maybe Python 4 will just remove stuff.

[fiedzia]

> but neither Go or C# have issues with dependency hell like Rust or even more JavaScript, because they have exceptional std libs

They also have a lot narrower scope of use, which means it is easier to create stdlib usable for most people. You can't do it with more generic language.

[pjmlp]

I would say C# gets used almost everything at Microsoft between GUIs, backends, DirectX tooling (new PIX UI, Managed DirectX and XNA back in Creative Arcade days), Azure,..., alongside C++, and even if Microsoft <3 Rust, in much bigger numbers.

[djfivyvusn]

I didn't understand the embedded systems argument. Just because a standard lib is large doesn't mean it all ends up in the compilation target.

[slashdev]

I don’t want a large std lib. It stifles competition and slows the pace of development. Let libraries rise and fall on their own merits. The std lib should limit itself to the basics.

[iTokio]

I think this is partially true, but more nuanced than just saying that Rust std lib is lacking.

Compared to go and c#, Rust std lib is mostly lacking:

- a powerful http lib

- serialization

But Rust approach, no Runtime, no GC, no Reflection, is making it very hard to provide those libraries.

Within these constraints, some high quality solutions emerged, Tokio, Serde. But they pioneered some novel approaches which would have been hard to try in the std lib.

The whole async ecosystem still has a beta vibe, giving the feeling of programming in a different language. Procedural macros are often synonymous with slow compile times and code bloat.

But what we gained, is less runtime errors, more efficiency, a more robust language.

TLDR: trade-offs everywhere, it is unfair to compare to Go/C# as they are languages with a different set of constraints.

[whstl]

I would say compared to other languages Rust feels even more lacking.

All those AFAIR need 3rd party packages:

Regex, DateTime, base64, argument parsing, url parsing, hashing, random number generation, UUIDs, JSON

I'm not saying it's mandatory, but I would expect all those to be in the standard library before there is any http functionality.

[nicce]

> Procedural macros are often synonymous with slow compile times and code bloat.

In theory they should reduce it because you wouldn’t make proc macros to generate code you don’t need…right? How much coding time you save with macros compared to manually implementing them?

[neonsunset]

To be fair I think Rust has very healthy selection of options for both, with Serde and Reqwest/Hyper being de-facto standard.

Rust has other challenges it needs to overcome but this isn't one.

I'd put Go behind both C#/F# and Rust in this area. It has spartan tooling in odd areas it's expected to be strong at like gRPC and the serialization story in Go is quite a bit more painful and bare bones compared to what you get out of System.Text.Json and Serde.

The difference is especially stark with Regex where Go ships with a slow engine (because it does not allow writing sufficiently fast code in this area at this moment) where-as both Rust and C# have top of the line implementations in each which beat every other engine save for Intel Hyperscan[0].

[0]: https://github.com/BurntSushi/rebar?tab=readme-ov-file#summa... (note this is without .NET 9 or 10 preview updates)