Comment by traceroute66 | Hacker News Reader

Comment by traceroute66 | Hacker News Reader

Parent Full thread

> Rust is not a panacea.

Amen to that.

I don't understand why more people don't highlight Rust's main weakness. The lack of strong stdlib.

No stdlib means you have two choices:

    (a) Re-invent the wheel; or
    (b) Use a crate.

Most people choose (b) because they don't have the time, inclination or expertise to do (a).

Which means you open yourself up to supply chain attacks, unless you constantly audit the upstream crates, which, let's face it, most people won't, they probably won't even audit the original version they pulled in, let alone the updates.

Which means with something like an nginx re-write in Rust, which is a complex piece of software with many moving parts, you end up importing a whole ton of random crates. Half of which will probably become abandonware within a few years, because that's the way of the world with open-source, maintainers move on to bigger and better things.

There is a difference between rewrite in Rust and rewrite properly in Rust.

No doubt there are people out there doing solid open source work with Rust (e.g. the guys at tweede golf) but that takes time and effort, and in the case of tweede golf, the extra effort is financially sponsored, something that is not the case with most open source projects, especially the single-maintainer ones.

Also: No bootstrapping rustc from source. There are a bunch of projects trying to get that fixed, but currently pretty much everybody relies on binaries coming from upstream. Having a core infrastructure component like nginx rely on a compiler we can't verify would make a supply chain attack against the compiler very attractive.

Yeah, the poor stdlib is the main reason Go is my go-to (no pun intended) language for writing servers rather than Rust. That and the slow compiler, which a lot of people think shouldn't matter, but does matter.

> language for writing servers

Or indeed clients.

In 2024 you shouldn't need to import third-party code to make a call to a REST endpoint and parse the JSON. Or the same with crypto.

All the stuff that's bread-and-butter in today's cloud-centric world, you shouldn't need to farm out to third-party code, it should be stdlib.

That’s a bit of a slippery slope though and causes maintinence nightmares for mature projects. Let’s say I want to upgrade to a new more secure TLS protocol. If it’s bundled to the language version that may mean changing the entire concurrency model, or something equally burdensome on a million line code base.

> That’s a bit of a slippery slope though and causes maintinence nightmares for mature projects.

I'm sorry, but I'm having great difficulty following your line of argument.

Are you seriously suggesting that Go does not have any mature projects ?

If not, are you seriously suggesting that the mature Go projects in Go are encountering maintenance nightmares because of stdlib ?

Your line of argument is giving off a whiff of FUD, sadly.

Well, they’re right. When the changes you want are part of the stdlib, then you may have to take on many changes you don’t want just to get the one change you do want. It’s a well known trade off.

A good middle ground here is to have official crates/pkgs managed by the core organization that can be upgraded separately.

Do you have any real-world examples of this happening in Go?

Discussing objective engineering tradeoffs is not the same as spreading FUD. It's baffling that you are so quick to shut down conversation and get combative. I never implied that there are no mature Go projects, just that the burden of maintenance is different than that of other languages that choose to break out more functionality into libraries, and that having a comprehensive stdlib is not 100% upsides as you implied.

I think it is worth trying to relate it to lived experience and ask "is this actually a problem or are we imagining problems that are unlikely to manifest?".

I used to develop in Java in large organizations for many years and be responsible for deciding how we use the language, what libraries we use etc. I used to be pretty hard on developers who would choose third party libraries for anything the standard library already delivered. Even in cases where third party libraries were perhaps a bit better than the standard library. They'd have to offer a clear and significant advantage over the standard library over time to warrant consideration. Especially if we're talking about core functionality or something that would be expensive to replace later.

Every third party dependency you introduce is a potential problem because you have to track them. You have to care about their development and release practices, you have to track their license (which may change), the health of the project, you have to know how they respond to defects being discovered etc. You have to do this for every single piece of third party code if the code you work on is critical to your business.

My real-world experience is that third party code carries a much higher risk than whatever you depend on from a standard library and you can make mistakes that end up being extremely costly.

> Discussing objective engineering tradeoffs is not the same as spreading FUD. It's baffling that you are so quick to shut down conversation and get combative.

What on earth are you on about ?

An assertion was made that Go stdlib was somehow "a slippery slope though and causes maintinence nightmares for mature projects".

It is a rather bizarre assertion to make, especially in relation to Go.

I am therefore merely asking for evidence of that assertion. Because, frankly, it smells of FUD and you know it.

But instead you are the one looking to shut down the conversation by not answering the perfectly reasonable questions I posed.

I'd be tempted to think that if an application is designed in a way where switching your TLS implementation has consequences for the concurrency model, you have some serious design challenges.

That being said, a good reason for using Go and its standard library is that they have been very good in terms of keeping important things in good shape and they put a lot more care into smoothing upgrades than is usually the case for random libraries. That's much of the motivation for using standard libraries: they have to be maintained in a manner that doesn't blow up billions of lines of running code. Third party libraries tend to be a far more mixed bag.

As for crypto: I shudder to think what it was like to use SSL/TLS in the C/C++/Java world. Horrific implementations that are fiddly to work with so you won't be inclined to mess with them more than you absolutely need to in regimens that rarely, if ever, pushes you to improve security as algorithm preferences shift over time. We've made heavy use of the crypto parts of Go to build our own PKI solution for an IOT platform and it was a lot easier than in any language we've used before. By a good margin.

I think you inadvertently made the argument for using Go and its standard library :-)

(Of course, 10 years down the road, perhaps people have abandoned Go and it has become a wasteland and there's some other language with a better stdlib you should be using. But ask yourself this: how much of the code you have written in the past is still running unchanged? You'll have to evolve, develop and adapt over time no matter what so if Go were to fade away, it isn't going to happen overnight and you'll have plenty of time to move on)

> I'd be tempted to think that if an application is designed in a way where switching your TLS implementation has consequences for the concurrency model, you have some serious design challenges.

I think you're misunderstanding OP's theoretical. If TLS is in the stdlib, that means its version is tied to the version of the language you're using. I.e. if you want to upgrade to a newer TLS, you need to upgrade your entire language version (compiler, interpreter, whatever).

So you can end up in a spot where you need to go from v1 of a language to v2 to get a modern TLS implementation. However if v2 of the language also contains changes to how the language handles threading, you now need to rewrite your app's threading to be compatible with v2 of the language, just so you can get a safe TLS implementation.

Basically because TLS is in the stdlib, TLS can force you to upgrade your language version.

If TLS was 3rd party, you could upgrade the library without upgrading your language version (presuming the TLS library supports your language version).

I understand the argument. Fortunately, Go makes a lot of promises that makes this scenario unlikely. So in real life this becomes mostly a theoretical issue. It could happen. It just isn’t terribly likely.

And if it does happen, it is likely a lot of other people will find themselves in the same boat, making a practical solution emerging more likely.

And note: the same thing could happen, and is more likely to happen, if you use a third party library. Some of the libraries I’ve used for years are no longer actively maintained, for instance.

If you want an opposing opinion, check out Python. I haven't seen anyone use urllib in the stdlib in like a decade.

Putting things like that in the stdlib makes them subject to the same API stability constraints as stuff like the threading API.

They tend to ossify and get abandoned when a 3rd party lib makes a faster, or better, or just more convenient API.

Go has a fair bit of this. I haven't touched the stdlib logger in forever. The HTTP server side is kinda meh, the client side is okay but not fantastic.

I am a fan of Go's experimental packages. I kind of wish things could live there permanently as "things the core devs believe are a good implementation, but don't want to bind stability guarantees to the language".

> If you want an opposing opinion, check out Python.

I would argue that Go is a fair comparison, Python is not.

Python is just a mess of a language, dependency hell etc.

> Go has a fair bit of this. I haven't touched the stdlib logger in forever.

You do realise Go has log/slog in stdlib now ? So structured logging is now in stdlib.

> You do realise Go has log/slog in stdlib now ? So structured logging is now in stdlib.

I do, it's just twice as slow as the old stdlib logger, which was already twice as slow as 3rd party loggers, and it makes like 8x as many allocs as zap. If I were going to change my logger, it would be to zerolog, not slog.

> Python is just a mess of a language, dependency hell etc.

We're talking about stdlib though, which are the only packages dependency hell doesn't apply to.

> I would argue that Go is a fair comparison, Python is not.

Go is the youngest of the major languages, making it one of the worst place to check if you want to see how packages age in the stdlib. Look at a language that's actually old if you want to see the kind of problems old apps face.

It also has a weird place, language-wise, because its developed by Google who has an unusual amount of influence over developer patterns. Other languages have to follow devs to where they are, Go can kind of lead the way via Google.

Reply on news.ycombinator.com