Hacker News Reader

God I get tired of the if err criticism with Go. I truthfully don't even notice it when I write Go, I don't understand why folks get so bent out of shape over it.

That just means you have written a lot of go. I truthfully don't notice lifetimes or the borrow checker most of the time when I write rust.

I actually think that, ironically, the if err problem with go is worse for reading code than writing code. If you are used to the pattern it's not that difficult to add the `if err != nil` after a fallible function call, and as is mentioned elsewhere, linters can help catch if you miss it. However, if you are trying to figure out what a function is doing, it can be very difficult to follow the flow, when 3/4 of the code is

    if err != null {
        return err
    }

especially if you don't have a lot of experience reading go code. And that 3/4 is not an exaggeration. I have had to read functions where literally every line of normal logic is followed by those three lines to propagate the error from the other function. A function that would otherwise fit on a single screen now takes up over three screens worth of scrolling.

I don't see how that's a specific problem of the Go programming language though. Rust still has option types and the cases where an Option could be None still need to be handled. Maybe the big difference is the compiler forcing the handling of this case but it seems like a small thing for experienced programmers.

Rust's default paradigm for memory management seems more significant of a language feature in my opinion and is what I can imagine most people don't like. A lot of the programs I write don't fall into the class of problems Rust is trying to prevent which makes the restrictions it enforces bothersome for me.

> Rust still has option types and the cases where an Option could be None still need to be handled

And rust has the `?` operator, as well as combinators like `map`, `and_then`, `unwrap_or_else`, etc. which IMO make the flow much easier to follow than say `if option.is_none() { return None }`.

> Rust's default paradigm for memory management seems more significant of a language feature in my opinion and is what I can imagine most people don't like

I never said it wasn't. My point is that if you use a language enough you get used to things that are difficult for people less experienced with that language.

`map` and its cousins make Rust error handling code easier to write. It doesn't make error handling easier to follow. And Rust introduces the problem of "thicket of different error types". And that's before we get to the sync/async boundary. There's a lot not to like about both Rust and Go's error handling. People need to stop pretending that either language has this answered perfectly.

People complain about Go's wordy error handling, but systems programming is error programming. The places where Go's error handling is most annoying is in application code, where you'd ordinarily EAFP instead of LBYL. But that's also the code Rust is least convenient for.

Go vs. Rust is truly the dumbest programming language slapfight in the entire industry.

Having used exceptions, like in java and python, checking error return values like in go and to some extent c, and using ADTs to represent error conditions like in rust, haskell, and scala (scala has exceptions too, but it's arguably more idiomatic to use Option, Try, etc.), primarily in application code, I by far prefer using ADTs. IMO it is a good balance between explicitness and verbosity. And ensuring you handle errors is built in to the type system.

I feel like the err != nil issue combines with GO using initialization to 0 values to be annoying.

If you forget err != nil, well your value does actually have a value and you would think your result was 0.

It's super annoying, I switched from Go to Rust for my personal projects because of it. It's like a seat belt beep that won't stop.

This reminds me of the same response regarding generics from Go users:

> God I get tired of the generics criticism with Go. I truthfully don't even notice it when I write Go, I don't understand why folks get so bent out of shape over it.

Over ten years later, Go gets generics.

There’s no contradiction there. I rarely missed generics in Go. Now on the rare occasion that they add significant value, I can use them.

Your profile link doesn't work. Regarding `if err`, it's one thing to add it everywhere, it's another to forget and then have something break. If Go also checked for exhaustive error handling, I wouldn't mind it either.

https://github.com/kisielk/errcheck

Every Go project I've worked on has used this linter. I think it should be builtin, but it's very easy to incorporate.

> but it's very easy to incorporate.

As someone who is adding this to a Go project with hundreds of unchecked errors, I disagree.

What kind of error does it check?

It looks for code where the err != nil hasn’t been handled

This is pretty trivial to accomplish with linters. Where I work your build will fail if you have unchecked err's hanging around, along with a lot of other sorts of issues. No, it's not built into the language by default or anything, but is that dealbreaking?

It is dealbreaking. These days I gravitate more and more towards strongly statically typed languages over weakly dynamically typed ones, which I definitely used to use when younger. Fact is, linters are simply not the same as something built-in from the ground up. Trust me, I have written many thousands of lines of Python and Ruby, and even with linters, they don't hold a candle to even something like TypeScript in terms of type ergonomics and refactorability, not to mention even stronger languages like Haskell or OCaml.

Anecdotally this is the same argument many C++ devs make in regards to Rust safety guarantees. The difference is just...different.

Well for one, Go is not a weakly, dynamically typed language, and this also isn't an issue of type checking at all.

Sure, I did not mean Go specifically when I said that, just stating how when I used linters in other such languages, it was not comprehensive enough to replace a language with types and other niceties built-in.

I also don't use much Go because it lacks good algebraic data type support, honestly can't imagine going back to a language that doesn't have them as I like to define all my business logic in types and then build the actual application from there. Go simply doesn't have that capability.

I'm not familiar with algebraic data types, what's missing from Go that makes that impossible? Sounds about like defining structs/other custom types before writing any method bodies, which is what I'd typically do in a Go project.

> what's missing from Go that makes that impossible?

The language maintainers don't want to add it: https://github.com/golang/go/issues/19412

In general I agree with you, but Go's simple syntax means that there are extremely few (if any? I've never run into one) edge cases with checking that an error was at least considered. The guarantees are the same as what you get with e.g. Rust. The only difference is that you have to run a third party's code, which I don't like, either.

> The guarantees are the same as what you get with e.g. Rust.

I'm not sure how they could be, given that Rust checks exhaustively and Go doesn't. If one programmer messes up, then that's it, an unhandled exception might occur in the future. I would rather rely on the computer telling me when it should be handled over humans.

And the worst human to tell you that is an SRE

It's hard catching bugs in go when your eyes tend to glaze over tens of thousands of 'if err != nil' statements causing bad signal-to-noise ratio.

I actually like Go over Rust, but really, really wish the language provided some more ergonomics and fixed several of its terrible gotchas. (the for loop issue for example)

Also wish Go gets RAII some day.

I dunno, if my exceptions would have to be manually rethrown every time, I’d get really cranky very quickly.

I don’t think that’s any better in Rust though.

Rust has many convenient shorthands like the ? operator, where `let x = foo()?` is equivalent to

  let x = match foo() {
      Ok(value) -> value,
      Err(e) -> return Err(e),
  }

IIRC, `let x = foo()?` is actually equivalent to

  let x = match foo() {
      Ok(value) -> value,
      Err(e) -> return Err(e.into()),
  }

Which can automatically convert one error type into another when the appropriate From and/or Into impls exist.

It is a little more complex than that these days

https://github.com/rust-lang/rust/blob/4e0d0d757e2f1b61ec809...

Many convenient shorthands that you all have to be familiar with before being able to write (and read) Rust competently. I guess that's what they mean with the steep learning curve...

If anything, context param drilling due to lack of thread local variable or similar is way less ergonomic

It's nice to read that someone else has had a positive experience with the zero2prod book. I'm working my way through it and my impression so far (even after reading the official "book") is that Rust is hard; I enjoy the challenges and the eventual realizations, but working my way through some of the chapters that involve implementations, traits, and macros makes me wonder: Would I actually be able to do this myself in a reasonable amount of time, in a professional setting?

I thought so too when first starting it, but I realized it's in-depth by design. There are a lot of tutorials that teach you the vague basics but they leave out things you (ostensibly) might not need currently, like logging and tests. In contrast, Z2P covers a lot of areas that are traditionally missed in such tutorials, and it even teaches design patterns for high performance web APIs. With that in mind, it felt like reading two books worth of information in one.

After going through the book, I've found that I simply use the same boilerplate for every new project, so it's more of a `write-once, use again` type of deal. In that case, I don't worry about the time it took to get to the point where I could do that reusing.

Agreed! And personally, I've found that "Zero To Production Rust" is absolutely phenomenal! I feel like it's the equivalent of "The Book" for using Rust on back-end apps!

I was surprised at just how detailed it was. I thought it would be like those NodeJS tutorials like "build a full-fledged backend API in 5 hours" but no, it covers everything you might think of for production, so its title is very accurate. It also teaches you system design along the way, which is quite a notable benefit over many other types of tutorials.

Thank you for linking to zero2prod. I just bought it after looking at the repo for the example code and scanning the sample. I wish I’d read this book a year ago.

I’ve worked my way through a couple of rust books, but this was the first one that actually talked not just about the language, but the entire development flow. Git workflows, CI/CD, docker, comprehensive testing.

Even after clearing the initial rust fundamentals, there are so many standard libraries like anyhow, chrono, serde, thiserror, and tokio that are almost required knowledge, but aren’t covered in most books.

Thank you for sharing your discovery!

> It's as ergonomic as (and sometimes even more so than) any NodeJS or Go API I've made (as even though Rust doesn't have function overloading, actix-web and others have some macro magic they do behind the scenes to make it appear as if it does)

Not that this takes away from your point, but does Go have function overloading? I had assumed it hadn't given the discussions I had heard about what it would take to retrofit `Context` parameters on everything when they added that type, but I guess maybe this could be one of those "functions can but methods can't" things (which I think I heard is how they do generics as well?)

No function overloading. Functions and methods can have the same name, params and return type.

> I can depend on the compiler telling me if I haven't done so exhaustively, via the Result type

That's going to get tiresome after about half a day.

Exceptions or GTFO.

I will die on the hill that Exceptions are absolutely terrible for readability and control flow and should die.

Result<> or Go returning many values is wayyyy better.

I'm so convinced that there exceptions are the superior article, that basically there is no hill worth dying on that can even be identified. It would be like saying that I'm going to personally defend a civilized continent against some fringe bushmen armed with flint arrowheads. I've got an army for that, funded by my taxes.

I will bury you and then unwind your stack, and clean up everything.

Sorry, I will disagree. It seems like you haven't written any Rust, try it and see how well a Result type works instead of excepting everywhere.

The only difference between exceptions and Result are that you need to change your return type to Result, and that you need to add a ? after calls that might fail.

There's also a bit of annoying typing stuff involved, but generally with something like the anyhow crate you can handwave that away too.

> The only difference

That's a significant difference.

It's the only difference if you're only considering blub exceptions, and not a nice exception system in which raising an exception doesn't immediately unwind, so that you can have remote handlers choosing local restart points and such.

> you need to change

Say I can't change it. I want to pass the exception through a third party library I don't control. I don't want to fork it, or can't.

Sum types with pattern matching are definitely nicer than some integer error codes or what have you, but for error handling, they are just a lipstick on error codes.

People outside of the Rust bubble do know what these concepts are, and about languages like OCaml.

Moreover, everyone who ever had anything to do with the concept of the development of exceptions was not an idiot who just didn't see the light of returning a sum type.

> you can handwave that away too

With what plugin for what editor ... :)

If you think Result is not ergonomic enough, try writing some Go.

In fact, you can often return Result from an underlying function from your own, achieving an effect similar to exceptions.

I agree with you about Rust and the web - it's a great fit for a performance-oriented web backend.

Personally, I actually think it's a worse fit for things like kernel/embedded development than for web backends. The ergonomics of Rust are so Javascript-y that the web is natural, and other environments where C is used are a lot messier and trickier.

I wish ReasonML took off more. It's an OCaml dialect which reminds me of Rust with a garbage collector, which is unsurprising given the Rust compiler's history being initially written in OCaml and where a lot of its ideas stem from, such as exhaustive pattern matching, the Result type, functional programming being as performant as imperative programming ("zero cost abstractions") and so on. ReasonML was developed at Facebook by the creator of React and it was supposed to be used as an alternative language than JS for writing React.

However, it didn't have much support after TypeScript took the JS world by storm. If it had, we might have seen the same great Rust-like benefits on the frontend as well, and perhaps the backend too instead of NodeJS.

The productiveness, safety, and beauty (seriously!) of the surprisingly numerous Rust kernel and embedded projects suggests otherwise. That use case took off very quickly in Rust world.

7 years ago I’ve deployed the first version of the REST API service written in Rust. We had multiple deployments in consecutive 5 years. For 2 years this service runs without any updates.

There were just a couple of failures in the first 2 months.

> deployed an API that has not gone down a single time since deploying near the beginning of this year

How often does the codebase change? How many people work on it?

I would say that using Rust for backend APIs seems a bit off. I like Rust, but introducing languages that can be made unsafe / can at a minimum memory leak seems irresponsible.

Its dumb when the C++ community refuses rust when it guarantees memory safety, so why would you bring in a language you prefer to an area that doesn't need it if it introduces that issue?

If you like Result<> or concurrency, use a GC language with those things. Go may not have them, but your choice isn't just Go.

The big win with Rust is that it's not only memory-safe but also thread-safe, which is hugely important in a web application.

IMHO C# is also an excellent choice, but there's a lot going on behind the covers to keep it working properly in a multi-threaded web environment. This mostly doesn't concern you as a developer, until it bites you.

Can doesn't mean will. I have not once used unsafe in my API code, the API acts just as it would in a GC language. In return I get more throughput, more speed, less memory used. The borrow checker ensures that I don't leak memory when not using unsafe, so I don't worry about it.

> borrow checker ensures that I don't leak memory when not using unsafe

Also to point out, you can 100% leak memory in safe rust

You can 100% leak memory in pretty much every language though: just use a bad caching/memoisation strategy, and you'll have memory leaks for days. Leaking memory isn't in of itself a problem, and it can be a very valid strategy for short-lived programs where you can rely on the OS to do the ultimate garbage collection run anyway. It's only a problem in the sense that uncontrolled memory acquisition will inevitably lead to the system running out of memory to acquire, but that's also true if you're accumulating memory for perfectly legitimate reasons.

Yes, you're right. However, it's much harder than in other languages, and the likelihood of doing so therefore is lower. I can also leak memory in GC languages too, just to note.

What would you say to a C++ dev refusing to use rust because their code is memory safe and they have never had a memory safety issue?

"Can" is the whole thing. A rust dev risking can is like a C++ dev risking can.

I like rust and do what you want in personal projects, but introducing it to a GC space when there are langauges that "can't" be unsafe is irresponsible when a GC language can offer all the upside of rust.

GCs prevent memory leaks, which safe rust can do. So even if you somehow make sure no unsafe is ever used, you can still introduce a hard to debug issue just because you want to use rust.

The difference is that it's fairly easy to prevent unsafe code from occurring: a "forbid(unsafe_code)" directive prevents unsafe code from even being accepted by the compiler. In C++ there is no equivalent - good linting can prevent some obvious errors, but a lot of valid code is inherently unsafe (in the Rust sense) if used incorrectly or under the wrong assumptions.

It's also worth pointing out that most GC languages can have the same issues as a Rust program (if not more) just by virtue of having FFI. In Python, I can quite happily load a C extension and ignore all the rules. Whereas in Rust, if I want to use a C library, I still need to explicitly declare it as unsafe code.

In practice, I tend to find that I have to think more about how I approach parallel/multi-threaded code in Rust than I do in other languages - not because it's dangerous, but because the compiler doesn't allow code that would break memory safety guarantees. In some ways, that's obviously a bad thing if I'm having to think more, but in my experience, the thoughts often lead to a better design anyway. So in the end, I'm more confident in my Rust code than I am in equivalent code in a GC language.

Right but to my knowledge (and I could be wrong) that unsafe tag does to prevent it in the crates.

Many memory safety violations have been discovered in rust crates: https://www.infoq.com/news/2021/11/rudra-rust-safety/

Maybe I wrong on that, but if it can’t guarantee crate safety, then it doesn’t really do anything.

That's true, but again, it's also true in most other languages that your dependencies can do anything they like, including shipping untrusted, compiled C code.

The value of something like "unsafe" is not that your code is magically protected if it isn't there, but rather that it provides a warning sign as to where dangerous code might lie. So if something goes go wrong - or you're just worried something _might_ go wrong - you know roughly where to look. In the same way, if your Python code includes a C extension and you start getting weird segfaults, you can reasonably guess where to start looking.

Except that, because unsafe is so well integrated in the language, you can often significantly reduce the impact of unsafe to only a few lines, and in most cases you won't need to use it at all.

> "Can" is the whole thing. A rust dev risking can is like a C++ dev risking can.

They're not the same because how C++ does memory safety and how Rust does it is unequivocal. C++ is unsafe by default, Rust is not, and you are ensured it is not, as I mentioned, via things like the borrow checker. To equivocate them is to fall into the same trap you yourself mention.

There are no GC vs non-GC spaces. The point of Rust is to be able to have memory safety without a garbage collector, that's literally why it was made. Thus, it is expected based on that premise that we be able to use Rust wherever a GC could be used. The fact that unsafe exists does matter, as long as unsafe isn't used. I too can turn a GC language like Java into an unsafe monstrosity, by for example doing raw bytecode tinkering, does that mean that Java is now unsafe? No, unsafe is merely an escape hatch.

Right but my main point is this:

Rust comes with additional risk. It is easier to leak memory, it is easier to be unsafe (especially since you can't guarantee what future other devs will do), but you gain nothing.

You get all that risk, but fearless concurrency can be done in GC languages (like Elixir) and many people have created the Result type before. So you have added risk for no benefit. Not to mention its easier to hire devs (and train devs) for other GC languages cause not everyone knows or understands the borrow checker.

Is there any advantage?

I mentioned the benefits elsewhere. Faster, more throughput, uses far less memory, more ergonomic developer experience (Elixir for example is not statically typed), rock solid stability (my API and anecdotally those of others I hear have never crashed). The risk is small compared to the benefits. I'm not sure why you keep saying there aren't benefits because there are. Now you might not agree they're good enough for you, but they exist.

Fair, but again I think you can get all those things with a GC language.

Speed is the only one you may possibly not, but I think speed is an non-issue. Speed in programming never matters except in the systems space. No one is gonna be able to tell Rust vs Go in a web API and depending on how you do the benchmark, I think many GC languages can probably tie Rust.

> Speed in programming never matters except in the systems space.

This kind of attitude is how we get bloated Electron apps that HN (including me) loves to complain about. Speed should be a first class consideration, not something to throw away for later.

> No one is gonna be able to tell Rust vs Go in a web API

Debatable, Discord moved from Go to Rust [0] because they were getting latency and CPU spikes from Go's GC, and I'd assume that's the same with any GC language because, well, the GC has to run sometime. Now you might say that we're not all Discord scale, to which I'd say, like above, there are benefits to Rust that are more than just speed. Cargo alone is nigh unbeatable compared to some other languages. I was trying to get Python to work the other day and was pulling my hair out over venv, virtualenv, pip, conda etc.

[0] https://news.ycombinator.com/item?id=26227339

Bloated is the problem, not language speed. I may have misspoke, what I meant was speed in language never matters.

And the discord instance was because it was systems/performance critical software they rewrote. They didn’t rewrite there web APIs. Discord mentioned the rewrite is now rust with C++ glueing it together. No way you are using C++ unless you have to.

I’ll agree with you on python venv/pip. Ugh what a mess. I like cargo, but honestly I think you could argue cargo also is an issue. When you bring in 100 crates, you just gotta hope all the unsafe code in them are safe.

A static analyzer found 200 memory unsafety issues in rust crates: https://www.infoq.com/news/2021/11/rudra-rust-safety/

Memory safe GC languages you don’t have to worry about that, and you can get a package manager.

The problem with Cargo is it only builds rust. I agree it's the best language-specific build tool, but I love the monorepo pattern and future proofing insurances that modern language agnostic build systems like Bazel enable / provide.

> Speed in programming never matters except in the systems space.

It matters to whoever is paying for compute. If you get some other benefit, it may be a worthwhile tradeoff, but it always matters.

> Speed in programming never matters except in the systems space. No one is gonna be able to tell Rust vs Go in a web API

Speed equals money. The same app running at twice the speed uses half the compute resources. You may also gain a lot of simplicity if you don't need to distribute your architecture so early on.

Don't believe the hype: moving from Go to Rust will not make your app (web or other) twice as fast! It might make your developers twice as slow though (as the author of the article noticed)...

If that were true, all enterprise code would still be non-GC

> It is easier to leak memory

I'm not convinced about this at all. I've had far more issues with memory leaks in JavaScript programs than I have with Rust. The only way you're really likely to leak memory in Rust is creating cycles of Rc and Arc types. But I don't think any of my programs have even contained Rc, and only trivial usages of Arc for global resources, which I absolutely wouldn't want to point to each other. JavaScript will let you create the same problem without making it obvious with type signatures. And while you might be lucky and have the GC sort out your mess, it doesn't always manage to.

If you're going to use Rust in web anything at all, the backend is the first place you'd think of. You can use Rust in the frontend but it's not exactly a smooth experience. Rust is a systems language.