Rust is not a good language for web development and I'm convinced that the majority of developers who push it for web development are just trying to show off.
Migrating from Go to Rust
471–480 of 544 posts
Re: Migrating from Go to Rust
#472Earlier quoted context omitted.
That's because the types of errors where you want a stack trace are a relatively small subset of all possible errors. Stack traces are only useful for errors that indicate a bug in the program, i.e. something a programmers has to respond to. It's not useful for the vast class of bugs that are a result of wrong input, wrong external state, or infrastructure issues. Rust projects tend to favor panicking over error hand…
See? You get people explaining to you that you actually don't want a stack trace because xyz.
This sounds disingenuous. They explained why the language doesn't force stack traces on all errors, and then explained how to get them if you want them.
Re: Migrating from Go to Rust
#473JVM languages to Rust, I understand it somehow. But Go to Rust??? It does not make any sense.
They run a Rust consultancy business. Anything is worth converting to Rust, for the right price.
Re: Migrating from Go to Rust
#474Earlier 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.
It also means that everything is (over) optimised for Google's usecases, but not general purpose applications
I came across this problem pretty directly a couple of weeks ago - I wanted to see if I could port a small C program to Go, where one of the needs is to create gzip archives. But the Go stdlib insists on extraneous padding that breaks the backwards compatibility requirements of my program.
The padding isn't needed, it isn't useful, and you can't opt out of it. So the whole program went in the bin and I have resumed maintaining it in C
This is one of dozens of situations I've experienced where Go's allegedly pristine stdlib design has kicked me in the nuts
Re: Migrating from Go to Rust
#475Earlier quoted context omitted.
What about the data in the error payload?
I think this is a clash of terminology: a Rust enum isn't an integer with pretensions of an identity. You'd describe it as a tagged union in some languages. So when you say you'd return an error with extra information, what that information is is associated with the specific variant of the enum. Using yuriks AllocError as an example, if the error is SizeTooLarge, it has the size field. Other errors may have no additi…
I'm aware that a rust enum isn't just an integer? How would it have a payload if it were just an integer?
right. If allocerror only has size field, where do you stash the unwind information (which could be of arbitrary size)
Re: Migrating from Go to Rust
#476the whole article kinda reads like "i have a leak in the basement of my house in the pacific northwest. the solution? im moving to nevada"
i dont dislike rust at all (infact, its rustler interop with elixir/erlang is great), but the article reframing a bunch of intentionl design choices (that i would broadly argue as good design choices) in golang as shortcomings is so weird (gc, generics, error handling, etc.). especially so when they're framed in such a way to make error-prone go seem inevitable, or are directly comparing well-written rust and poorly-written go. take, for example, the section on data races. the article broadly classifies rust as data race free and golang as full of synchronization issues. and this is true if you only actually care about data races (not race conditions broadly), assume all of your rust is safe rust, and none of your golang uses any of the available solutions (atomics, synchronization primitives, channels, etc.) to data races. yes, go leaves much of the behaviour up to the programmer. this isn't a downside.
more egregiously, the article glosses over two of the biggest and, to me, most critical differences between the two language. first, go compiles FAST. i can write something and test it immediately, including stepping through the code. i dont need to context switch away from the task and can easily, and quickly, program fixes and changes and features. this is such a huge development gain that switching away from it would require an incredibly good reason. secondly, the package structure of rust offers a clear vector for supply-chain attacks. not that golang is perfect in that sense, but it has a ton of factors that reduce the likelihood, and if i'm being really picky about safety it's going to be a big consideration.
Re: Migrating from Go to Rust
#477Earlier quoted context omitted.
The stdlib is the place where good ideas go to die. And then you have httplib3 followed by httplib4. In other words: I highly prefer the Rust approach. It doesn't matter a lot whether I rely on the stdlib or another dependency to me. It's a dependency after all. People think just because it's the stdlib it's somehow better quality or better maintained, but these are orthogonal concepts. In the end it depends solely o…
The stdlib isn't necessarily better, but it's always there . To use Python as an example, I tend to prefer requests to urllib2, as do most programmers. But I've absolutely been in scenarios where all I could get was the stdlib, and having urllib2 saved my ass. I think it's extremely important for the stdlib to be batteries included, even if they aren't the best versions of those batteries on the market.
so how do you get into scenarios where you only can use the stdlib?
Re: Migrating from Go to Rust
#478Earlier quoted context omitted.
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.
It also means that everything is (over) optimised for Google's usecases, but not general purpose applications I came across this problem pretty directly a couple of weeks ago - I wanted to see if I could port a small C program to Go, where one of the needs is to create gzip archives. But the Go stdlib insists on extraneous padding that breaks the backwards compatibility requirements of my program. The padding isn't n…
How is this «optimized for Google»?
Re: Migrating from Go to Rust
#479> You literally cannot dereference an Option without acknowledging the None case. Whole categories of pager-duty incidents disappear. This is at the very least misleading, given that you can use unwrap. Regarding error handling: will a parser error in the config return an error that includes the name of the file that’s failed to parse? That’s the kind of useful context that I add to errors in Go.
The difference is, unwrap will stick out like a sore thumb, and it’s opt-in. You explicitly tell "this may panic". As for error handling, this kind of enrichment is usually left to the caller (that is, the end application), with error libraries like anyhow where you can add arbitrary string contexts to an error. You would end up writing `Config::load(path).with_context(|| format!("Failed to load configuration file {p…
While I agree it's better than the golang alternative, it's definitely still a footgun. See Cloudflare's Nov 2025 outage.
Re: Migrating from Go to Rust
#480Earlier quoted context omitted.
> I had the misfortune of having to use Python with a virtual env on the weekend - it did not end well, and reminded me why I migrated away from Python. I see this sentiment a lot, and it doesn't match my experience at all. In my decade-old bubble of using Python professionally, I've never had an issue with virtualenvs. The few issues I might've had with dependency resolution must be so far in the past that I don't r…
I used Python for a decade (professionally), gave up on it once I started using Go (professionally) in earnest - about 8 or 9 years ago. I never liked virtual envs, having to remember where they were, what their names were, and what was installed into each one was a pain point for me. This weekend I was trying to learn some AWS stuffs, and I cloned the official repo of example code which was Python. I followed the di…
> having to remember where they were, what their names were, and what was installed into each one was a pain point for me.
It's at the project root, it's named 'venv', and its contents are described by requirements.txt.
> You're saying you see people complain about it a lot - therefore it's a genuine problem.
Debatable as a principle, but applicable enough here I suppose. Still, I'm not saying the problems aren't real, but what I (and probably most of us virtualenv users) are saying is that there's a pretty broad swathe of projects where you don't encounter them. It's just fine. You install your packages and use your packages and that's the whole story.
I guess if you have a hard dependency on a particular version of python, it's going to be harder, but... why? That's already niche in my book. If you're saying the AWS repo was pinned to a particular version of python, I'm going to blame that on Amazon frankly. That's definitely bizarre.
Edit: Were you looking at this? https://github.com/boto/boto3 Definitely more complicated than a typical greenfield virtualenv-able project, with some python version restrictions.