Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lies we tell ourselves to keep using Golang (2022)

fasterthanli.me

Post reply on HN
Print view View original

321–330 of 526 posts

Re: Lies we tell ourselves to keep using Golang (2022)

#321

Post by vaylian »

bazoom42 wrote: post #294
abtinf wrote: post #25

Earlier quoted context omitted.

Having programmed for over 30 years, including nearly a decade of C#, I would say exceptions are one of the worst ideas in all of programming. They are just horrific gotos that any library can invoke against your code. They are pretty much never, ever handled correctly. And nearly always, after an exception is “handled”, the application is actually in an unknown state and cannot be reasoned about. Even junior enginee…

Is “goto” just used to mean “bad and evil” here? Because exceptions are not a goto anymore than a return is a goto. The problem with goto is it can jump to any arbitrary place in your code. Exceptions will only go to catch-blocks up the call stack, which presumably you have written on purpose.

> Because exceptions are not a goto anymore than a return is a goto

Not true at all

* goto goes to a specific hard-coded address

* return looks up the previous address from the stack and goes there

* exceptions are a complex mess that require branching logic to determine where to resume execution

Re: Lies we tell ourselves to keep using Golang (2022)

#322

Post by quotemstr »

mike_hearn wrote: post #268
abtinf wrote: post #25

Earlier quoted context omitted.

Having programmed for over 30 years, including nearly a decade of C#, I would say exceptions are one of the worst ideas in all of programming. They are just horrific gotos that any library can invoke against your code. They are pretty much never, ever handled correctly. And nearly always, after an exception is “handled”, the application is actually in an unknown state and cannot be reasoned about. Even junior enginee…

Well, I've also programmed for over thirty years and I wouldn't use a language without exceptions and even wrote a whole essay defending that position: https://blog.plan99.net/what-s-wrong-with-exceptions-nothing... > Even junior engineers have a trivial time debugging most go errors Not my experience at all. I had to do this once. An HTTP request to a production server was yielding a 400 Bad Request with no useful i…

I can't agree with you about C++ exceptions being worse than useless. Exceptional C++ is worth it. Safety isn't that hard with RAII and ScopeGuard..

In your map example, just add a scope guard that removes the just-added element using the returned iterator if the rest of the procedure doesn't succeed. It's no different in Java.

Re: Lies we tell ourselves to keep using Golang (2022)

#323

Post by quotemstr »

mathw wrote: post #243
Chai-T-Rex wrote: post #180

Earlier quoted context omitted.

If a Rust function can panic, there's generally a non-panicking alternative. For example, `Vec` indexing has `vec[n]` as the panicking version and `vec.get(n)` as the version that can return `None` when there's nothing at that index.

I do wish this is something Rust had done better though - the panicking versions often look more attractive and obvious to developers, and that's the wrong way round. Vec indexing, IMO, should return Option .

One of my dream projects is creating a Rust stdlib based solely on panics for error handling. Sure, it'd be incompatible with everything, but that might be a feature, not a bug.

Re: Lies we tell ourselves to keep using Golang (2022)

#324

Post by chrismorgan »

quotemstr wrote: post #308
chrismorgan wrote: post #262

Earlier quoted context omitted.

One practical benefit of Rust’s approach that hasn’t been emphasised enough yet is the consequences of Option and Result being just values, same as anything else. It means you can use things like result.map_err(|e| …) to transform an error from one type to another. (Though if there’s a suitable From conversion, and you’re going to return it, you can just write ?.) It means you can use option.ok_or(error) or option.ok…

Exceptions are values in C++, Java, and Python too. They're just values you throw. You can program these values. As usual, I find that opposition to exceptions is rooted in a misunderstanding of what exceptions really are

Exceptions are values, but normal-value-or-exception (which is what Result is) isn’t a value. Review my remarks about map_err, ok_or, &c. with the understanding that Result is handling both branches of the control flow, and you can work with both together, and you might be able to see it a bit more. Try looking at real code bases using these things, with things like heavily method-chained APIs (popular in JS, but exceptions ruin the entire thing, so such APIs in JS tend to just drop errors!). And try to imagine how the collect() forms I described could work, in an exceptions world: it can’t, elegantly; not in the slightest.

Perhaps this also might be clearer: the fuss is not about the errors themselves being values, but about the entire error handling system being just values.

Re: Lies we tell ourselves to keep using Golang (2022)

#325

Post by 9rx »

the_gipsy wrote: post #29
devjab wrote: post #5

This article makes a lot of great points about the shortcomings of Go. I don’t think explicit error handling is one of them however. I’ve previously spoken about my loathing of exception handling because it adds a “magic” layer to things which is way too easy to mess up. From a technical standpoint that isn’t necessarily a good argument, but from a pragmatic standpoint and decades of experience… well I will take expl…

There are several shortcomings with go's error handling. The author heavily lies onto rust, so the alternative is not exceptions but a `Result ` sum type. No stacktraces and error wrapping forces you to not only invent unique error messages. You must also conceive a unique wrapping message at every call-site so that you can grep the error message and approximate a stacktrace. The weird "return tuple" , which obviousl…

> The weird "return tuple" , which obviously just exists for errors because there is not a single other place where you can use tuples in the language

Go functions also accept a tuple on input. While theoretically you could pass an error, or a pointer to an error for assignment, it is a stretch to claim it is for errors.

Re: Lies we tell ourselves to keep using Golang (2022)

#326

Post by neonsunset »

sureglymop wrote: post #133

Rust and Go are very different and I feel people want a middle ground that just doesn't exist currently. A garbage collected relatively simple language that compiles into a statically linked binary but has a type system similar to rust, rest types etc. Syntactically, Gleam and Kotlin come somewhat close but not really. I like Rust but I do believe it is too complicated for many people who are capable of creating some…

C# and F# will be by far the closest. Other options lack sufficiently good type system or tooling to match either of the two.

Compile to static native binary with 'dotnet publish -p:PublishAot=true' (or add this property to .csproj to not specify on each publish). In the case of F#, you will need to use Console.* methods over 'print*' because print has unbound reflection inside for structural output on "%A" format specifier (it will work most of the time but negatively impacts binary size and causes the compiler to complain).

I can especially recommend F# as "easier more business-focused Rust alternative" because it is expression-oriented, has discriminated unions, full HM type inference and gradual typing is a joy to work with. Data analysis and domain modeling are very pleasant to do in it too.

For systems programming C# is going to be the option to use - it will give you great concurrency primitives, fast (sometimes even zero-cost) native interop, smaller than Go native binaries and a lot of low-level APIs including portable SIMD. Go is often poorly suited for these tasks or can't do them at all (at least without workarounds). There are many new high-performance libraries focused on this domain as .NET gains popularity in non-gaming communities in this area. And of course you benefit from a huge existing ecosystem and won't have to do the all the heavy lifting by yourself unlike in niche languages suggested in sibling comments.

Re: Lies we tell ourselves to keep using Golang (2022)

#327

Post by [deleted] »

KingOfCoders wrote: post #61
the_gipsy wrote: post #29

Earlier quoted context omitted.

There are several shortcomings with go's error handling. The author heavily lies onto rust, so the alternative is not exceptions but a `Result ` sum type. No stacktraces and error wrapping forces you to not only invent unique error messages. You must also conceive a unique wrapping message at every call-site so that you can grep the error message and approximate a stacktrace. The weird "return tuple" , which obviousl…

Exceptions are sum types, they just have different syntactic sugar.

[deleted]

Re: Lies we tell ourselves to keep using Golang (2022)

#328

Post by 9rx »

KingOfCoders wrote: post #61
the_gipsy wrote: post #29

Earlier quoted context omitted.

There are several shortcomings with go's error handling. The author heavily lies onto rust, so the alternative is not exceptions but a `Result ` sum type. No stacktraces and error wrapping forces you to not only invent unique error messages. You must also conceive a unique wrapping message at every call-site so that you can grep the error message and approximate a stacktrace. The weird "return tuple" , which obviousl…

Exceptions are sum types, they just have different syntactic sugar.

Checked exceptions may be implemented as a sum type. Traditional exceptions are more likely to be a single type that wraps up a context object alongside stack trace information.

Re: Lies we tell ourselves to keep using Golang (2022)

#329

Post by [deleted] »

Seb-C wrote: post #319
KingOfCoders wrote: post #65

Go: "I'm a simple language!" User uses Go for some time. User: "I hate you, you're a simple language!" Perhaps it's because I'm 50+, I love a simple language. I feel the "critique" is not very balanced, and I view judgements that are not balanced as weak, as everything in technology is about tradeoffs. I of course come to a different conclusion: https://www.inkmi.com/blog/why-we-chose-go-over-rust-for-our...

The problem is that Go is not designed to be a simple language for it's users, it's designed to be a simple language to implement for it's maintainers. In my opinion, a simple language should be highly consistent (have a few rules, but which are universal and consistent everywhere). Instead we have a language with weirdnesses, inconsistencies and workarounds all over the place. A good example is type elision: it's av…

[deleted]

Re: Lies we tell ourselves to keep using Golang (2022)

#330

Post by voidhorse »

Go is great for a variety of projects. Smaller codebases, little cli tools, simple servers, etc. It has its quirks, as any language does, but it is foolish to write off an entire language when some of the very properties you dislike may actually be a good fit for the problem at hand.

When engineers focus on language features they focus on the wrong things. Yes, languages like Java and Rust are fantastic for large codebases because generics and strong encapsulation become especially important as the number of engineers working on a project scales. Contrarily, Go would probably be a million times better for a small project of one to three staff that primarily revolves around a few well-designed data structures and basic array manipulation. In this context, the more sophisticated features of a Rust or Java are actually hindrances and end up making things more elaborate than needed.

Languages are a resource and a tool, not an identity marker. Use the language that makes sense for your constraints. Programming is all about modeling problems. No language will do this for you and each one has features that help or hinder and some are better or worse form problems of different shapes. Learn about how computers and compilers actually work so that you are empowered to use a wealth of languages and can choose the best one for your project on rational grounds.

Or, you can embrace Haskell and use the only perfect programming language to have been thus far invented :)

Post reply on HN