Comment by jackjeff | Hacker News Reader

Comment by jackjeff | Hacker News Reader

Checking for errors after every line (like in Go) is the worst. Used to do that in c/c++ calling win32 APIs. Know what happened when sloppy developers come along? They don’t bother checking and you have really bizarre impossible to debug problems because things fail in mysterious ways. At least with an exception if you “forget” to catch it blows up in your face and it’ll be obvious

Sure monads are cool and I’d be tempted to use them. They make it impossible for forget to check for errors and if you don’t care you can panic.

But JS is not Rust. And the default is obviously to use exceptions.

You’ll have to rewrap every API under the moon. So for Monads in JS to make sense you need a lot of weird code that’s awkward to write with exceptions to justify the costs.

I’m not sure the example of doing a retry in the API is “enough” to justify the cost. Also in the example, I’m not sure you should retry. Retries can be dangerous especially if you pile them on top of other retries: https://devblogs.microsoft.com/oldnewthing/20051107-20/?p=33...

Monadic style or not, the `if err != nil return err` pattern destroys critical information for debugging. `try/catch` gives you a complete stacktrace. That stacktrace is often more valuable than the error message itself.

That is why everyone says to wrap your errors in Go. %w ftw

Naked err returns can be a source of pain.

> the `if err != nil return err` pattern destroys critical information for debugging.

Funny enough, your code looks like it is inspired by Go, and Go experimented with adding stack traces automatically. Upon inspecting real-world usage, they discovered that nobody ever used the stack traces, and came to learn that good errors already contains everything you'd want to know, making stack traces redundant.

Whether or not you think the made the right choice, it is refreshing that the Go project applies the scientific method before making a choice. The cool part is that replication is the most important piece of the scientific method, so anyone who does think they got it wrong can demonstrate it!

This is the arrogance of language designers with limited experience developing real-world applications. Maybe it works as a replacement for C building low level apps, but it won't fly in enterprise codebases.

Go recognizes the arrogance of language designers (Pike is a team member, so it was hard for such a thing to go unnoticed!), hence why they put their theories to the real-world test instead of just guessing. Most languages seem to pack in feature after feature because some random nobody on the internet thought it would be a good idea without ever seeing if their thought could be proven as a good one, but Go tries to actually show it first.

Which is also why it draws so much ire. It speaks the truths developers don't like to admit.

With which million line enterprise codebase did they real-world test this?

They test with their community and get the biases of their community. Don't pretend it's more than that.

"Enterprise" being a euphemism for low-quality developers who don't know how to write quality software (the sloppy developers referenced in an earlier comment)? Perhaps not. Go does seem to scare off anyone who relies on crutches to work around shoddy work and inability.

But it doesn't really matter which codebases they used, does it? Replication efforts will reveal anything they got wrong. No need to make guesses.

"Enterprise" is a euphemism for line of business software that makes billions of dollars. Ie, the stuff that runs the real world.

"Enterprise" traditionally refers to code that is full of bad practices. Like, when Java was all the rage, FooFactoryBuilderFactory was the embolism of enterprise. In other words, where sloppy developers are found. Glad we were able to clear up that isn't what you meant.

So you are meaning – with respect to the code – the same as all other software? What, then, is "enterprise" trying to add? It is not like you would write code that makes billions any differently than you would a code that makes a dollar.

I have written, and continue to write at another org, Go that drives line of business software that makes billions of dollars and runs the real world. Check a random email you have and if you see a header X-EID, it was processed with Go.

Please tell me about the scientific study relating to the utility of stack traces that was run in your codebase.

Individual codebases can already include stack traces as they see fit, so studying only a single codebase would be rather pointless. If an individual codebase benefits from stack traces, it will use them! The study looked at how often they were used to determine if it would be a useful default. It found, by looking at many different projects that had stack traces included by default, that it would not be useful to include by default. Especially in light of the cost of inclusion. Adding stack traces is definitely not free.

Please can you provide the article/mailing list where this was discussed along with their methodology?

I code Go professionally. I like the language. However, I vehemently disagree with the stance that error messages > stack traces. Error messages are in no way as helpful as stack traces. Ideally, you'd have both.

The scientific method doesn't care about your feelings, but it does care about your replication efforts. Under what circumstances did your research found stack traces to be necessary?

The idea that you need to run a study to criticize a design decision is stupid. A stack trace is ground truth, natural language is interpretative. The implications are plain to see.

> The idea that you need to run a study to criticize a design decision is stupid.

Not at all. Fundamentally, you do need understanding in order to criticize. "Criticizing" without understanding is merely whining. If your intent is to whine, you are certainly welcome to until your heart's content, but it will be fruitless. Without you having an understanding – and being able to articulate it – progress cannot be made. This should be obvious.

> A stack trace is ground truth

But a costly truth. Even languages that do pass around stack traces are careful to avoid them except under special circumstances, which is kind of nonsensical from a theoretical point of view. If you find them to be useful, you'd find them useful in all cases. However, it is a necessary tradeoff for the sake of computing efficiency.

With a few small changes to your codebase you can restore the automatic attachment of stack traces like the original experiments had. Stack traces are made available for you to use! But, it remains that the research showed that the typical application didn't ever use it, so it wasn't a sensible default to include given the cost of inclusion. "But, but I wish it were!" doesn't change reality like you seem to think it does.

You come off extremely rude, and for someone so enamored with the scientific method you make a lot of baseless assumptions about what I think and understand.

Understanding comes from all kinds of places. When a child touches a hot stove, they come to understand the consequences. That child doesn't gather 30 participants and record their reactions as they take turns burning their fingers. I'll leave you to extrapolate.

> You come off extremely rude

How I come across has no bearing on what is said. This is irrelevant and a pointless distraction.

> Understanding comes from all kinds of places.

If you have an understanding then you've studied it. All that is lacking, then, is the communication of what is understood. Strangely, after several comments, still crickets on the only thing that would add value to the discussion...

He's a troll. I regret feeding him.

Thirty years working as a developer

I think you omitted the part and ergonomics of wrapping err in other err, as it bombs out of nested if statements. like a poor persons stack trace.

And using those utilities to test if an err is of a certain kind now that’s been wrapped a few times

An advantage to the Monad approach is that it sugars to the try/catch approach and vice-versa (try/catch desugars to monads). JS Promises are also already "Either<reject, resolve>". In an async function you are writing try/catch, but it desugars to monadic code. You could write an alternative to a library like "neverthrow" that just wraps everything in a Promise and get free desugaring from the async and await keywords (including boundary conditions like auto-wrapping synchronous methods that throw into Promise rejections). You could similarly write everything by hand monadically/pseudo-monadically directly with `return Promise.reject(new Error())` and `return Promise.resolve(returnValue)` and everything just works with a lot of existing code and devs are quite familiar with Promise returns.

It might be nice for JS to have a more generic sounding/seeming "do-notation"/"computation expression" language than async/await, but it is pretty powerful as-is, and kind of interesting seeing people talk about writing Monadic JS error handling and ignoring the "built-in" one that now exists.

This is also where I see it as a false dichotomy between Monads and try/catch. One is already a projection of the other in existing languages today (JS Promise, C# Task, Python Future/Task sometimes), and that's probably only going to get deeper and in more languages. (It's also why I think Go being intentionally "anti-Monadic" feels like such a throwback to bad older languages.)

Moving from try:catch to errors as values was so refreshing. Same company, same developers, but suddenly people were actually _thinking_ of their errors. Proper debugging details and structured logging became default.

I assert that try:catch encourages lazy error handling leading to a worse debugging experience and longer mean time to problem discovery.

Checked exceptions also force people to think of their errors

Nice thing about Monads in JS with tools like neverthrow is that you can create the Monad boundary where you like.

It becomes very similar to try-catch exception handling at the place you draw the boundary, then within the boundary it’s monad land.

If you haven’t wrapped it in a monad, chances are you wouldn’t have wrapped it in a try-catch either!

Don’t accept sloppy development practices regardless of what programming language you’re going to use.

Just FYI, the go linter has `errcheck`, which would catch your sloppy developer checkins: https://golangci-lint.run/usage/linters/#errcheck

Reply on news.ycombinator.com