461–470 of 544 posts
Earlier quoted context omitted.
Funny - you said Go was worse - now you're saying Go's the same...
It is worse, gcc has the warnings at least, go does not. You need a 3rd party linter.
Go has go vet - baked in and runs by default
I tire of your bad faith ignorance.
Earlier quoted context omitted.
Rust has clearly opined that they prefer a small standard library and a "choose your own libraries" vs "batteries included" approach. If Rust included a crypto lib and a vulnerability was discovered, many fixes are backwards incompatible. Rust maintains strict backwards compatibility, which means updating the relevant crypto functions in the std lib would necessitate a major version bump. By keeping crypto outside of…
In general, I get your argument, but cryptography is the perfect example for something so well-specified, well-understood, and extremely widely used, that these arguments do not really apply. You are not going to have to make backwards-incompatible changes to SHA256 or Poly1305, etc. It has minimal API surface too, and is not going to be a large maintenance burden. But nearly everybody is going to need crypto at some…
Certainly, that's a better outcome than just providing bindings to OpenSSL, which is what most other languages do.
Earlier quoted context omitted.
> Rust still rely on many C and C++ libraries Yes but Rust has a lot more availability of libraries to do stuff as a result. Want to do anything ML or scientific? You at least have a route in Rust where you don’t with Go.
With Go basic stuff like url parsing or HTTPS support is written in Go and comes with the standard library. With Rust too many necessary things are just wrappers around C and C++ making cross-compilation and reproducible builds much harder to archive. As for availability if CGO is ok, then calling C or C++ code from Go is not that hard. Also, there is always an option to just start C++ process if extra data copies ar…
The only thing I can think of is cryptography. We do have ring, but the default in rustls today is aws-lc-rs.
Earlier quoted context omitted.
What "cloud memory costs"? Most Rust code is an informally-specified version of the old Python reference-counting GC. That's how you're supposed to write it, with clone() everywhere, and then dropping down to optimize. You can do the same thing with Go in the other direction by writing an allocator. People believe a lot of weird things about these languages.
Why would I roll custom allocation strategies in Go (and then be accountable for supporting them) that affect multiple teams and services when I can have an LLM port to Rust and get dozens of additional benefits?
But do remember that the logic you're using depends on nobody on your team reading the LLM code. If you're close-reading LLM outputs, all the complexity of Rust's memory management model is back on the table.
Earlier quoted context omitted.
> Rust lacks a uniform error type Rust has practically one error, it's the Error trait. The things you've listed are some common ways to use it, but you're entirely fine with just Box (which is basically what anyhow::Error is) and similar.
Surely you need an alternative to Box for reporting memory allocation failures?!
In Rust you can do that (mostly on nightly although not only), and yes there are alternatives for this case, but it's rare anyway.
Earlier quoted context omitted.
> Rust has three main error systems (io::Error, thiserror, and anyhow), which is a pain when you have to pass them upward through a chain of calls anyhow explicitly isn't designed for what you are trying to do here. It's designed to be the last link in the chain (and complementary to thiserror, not in competition). If you are using anyhow any deeper than your top-level binary crate, you are likely to be in for an unp…
He was talking about the chain of function calls not crates. You still have that in your top level crate.
Earlier quoted context omitted.
Rust's stdlib is small, Go took more of Python's "batteries included" strategy. So in that sense it seems like a category error to try to look for crypto stuff in the standard library. Of course this brings the well known problem of "okay, but then which one should I use?". Nowadays this is largely solved by a few web searches and LLM queries, and people are quite helpful at https://old.reddit.com/r/rust/ . Go was sh…
It turns out that the needs of Google overlaps significantly with the needs of software engineers outside Google. That argument could have been valid for a while after its initial release. But now it is just a lazy argument today. I think batteries included is a better strategy. To the degree where I think Rust should reconsider this decision.
But there's no theory of standard library that they could implement. Shipping things together makes sense, but the maintenance burden is already significant, and there's also no theory of "ethically cloning open source maintainers".
I'm also quite squeamish when I think about all the unvetted dependencies, so yes, there's definitely a need, but I don't think slapping a stdlib tag on millions of lines of code would lead to great things.
But sure, I think someone could champion the case to introduce a process for adding projects to the standard packages. The projects would need to show some competence, commitment to quality and security. And the process obviously needs to have an orderly procedure for deprecation, and for "non maintainer updates" (like Debian has, for example).
C++ also forms a natural barrier to entry.
I'm moving more and more from Python and Golang to C++. C++ also forms a natural barrier to entry.
Earlier quoted context omitted.
Rust doesn't promise that your safe Rust doesn't have race conditions only specifically that it doesn't have the one very weird kind of race condition from computers with no analogue to the real world, a Data Race. An ordinary race condition would be e.g. you put the cat out of the front door, then you walk to the kitchen and close that door - well, the cat might race around the outside of the house and get in first.…
> In logic, equivocation ("calling two different things by the same name") is an informal fallacy resulting from [...] knowingly and deliberately using words in a different sense than the one the audience will understand. Of course I mean data race, most people in such a thread will implicitly understand that is the race meant. Nobody building a webshop with limited supplies wants to prevent "first come first served"…
No they don't, as you handily illustrated by offering no actual data race analogies but instead managing to confuse loss of atomicity with a data race. It's OK though, so long as you write only safe Rust you can't blow your own foot off even though you didn't understand how the explosives work.
And actually people write other race conditions all the time, particularly ToCToU races are very common, and as I explained Rust doesn't prevent those - although a Rust library you're using might go out of its way to be friendly by directing you away from them as Rust's own file system stdlib functions do.