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

391–400 of 526 posts

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

#391

Post by miki123211 »

packetlost wrote: post #338
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…

Rust and Go's lack of stack traces are basically equivalent in that you need to call an additional function to add the stack context to the error result. For go you use fmt.Errorf, in Rust you use .context from anyhow (bad practice in many contexts IMO) or .inspect_err + log. It's rather unfortunate that neither has an easy way of capturing a line number + file easily and appending it to the context. Go could easily…

> I agree that Go should really have an analogue to Rust's `?`, but you can't really do that in a sane way without sum types to represent your conditions. The very multiple-return style error propagation makes it impractical to do.

There was a proposal for a `try`, which I still think should have been adopted.

Under that proposal, `someComplicatedExpression(try(functionReturningError()))` would be converted to `foo, err := functionReturningError(); if err != nil{return zeroValue, zeroValue, err}; someComplicatedExpression(foo)`

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

#392

Post by zaptheimpaler »

amai wrote: post #378

Sorry to spoil the party, but the future is mobile and none of your favorite programming language ( Rust, go, Python, Nim, Lisp, Zig, Smalltalk ...) is ready for this. The future will be Kotlin, Swift and Javascript and I already hate it.

The present is already mobile but the backends serving those mobile devices run on servers. There's also no reason mobiles can't run Rust/Go/Python - Android already runs Java.

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

#393

Post by dingnuts »

madeofpalk wrote: post #239
spirit-sparrow wrote: post #217

I wonder what makes someone go such a great length to bash a language, any language. I say bashing, because even the few valid points in the post are not written in a constructive style. After all is there a language that can't be criticised? Is the post written to make one feel better having a failed a project the language? (It's not me, it's the language) Or is it the failure to understand that not everyone thinks…

It's just some person's blog and they're having a rant. It's okay, it doesn't have to be that deep. I would guess the 'why' is because OP feels like they have an opinion that they don't feel is sufficiently represented 'out there'. Indeed, as a not-a-fan-of-go, in 2022 I was confused at go's popularity because it always felt to me to have some pretty glaring shortcomings that were seemingly ignored. Note that people…

Speaking a someone who has written Go full time since 2014:

Go is used in a lot of places for unglamorous things where the most important thing is explicitness, and where all these features that the PL nerds want, do nothing but make things more implicit.

It's not perfect, but it's a great language. People who like it, though, like me, are pragmatists. The shortcomings of the language that are apparent in complex code are strengths when writing the simple straightforward code that makes up most Go projects, because all of THAT becomes much simpler than it would be in a fancier language.

The reason I've never bothered to write a response to these kinds of screeds against Go is that usually I'm too busy getting shit done with it.

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

#394

Post by stouset »

LinXitoW wrote: post #272
jonathanstrange wrote: post #96

Earlier quoted context omitted.

I have no idea why anyone would say it's not simple, it's super-simple. Learning how duck typing works with interfaces and how to use it is perhaps the only hurdle. In my experience, only certain BASIC dialects like VisualBasic are simpler.

I think the sticking point is what people mean when they say simple. To me, and likely to many saying Go isn't simple, simple is not a synonym for easy. Go is easy, but it is not simple. For example, solving the problem of generics in a generic way from the start so the same problem can be addressed in the same way everywhere, would be simple, but maybe not (as) easy. Contrast that to giving the runtime/standard libr…

Frankly code generators to fake generics aren’t remotely easy either.

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

#395

Post by coffeebeqn »

spirit-sparrow wrote: post #217

I wonder what makes someone go such a great length to bash a language, any language. I say bashing, because even the few valid points in the post are not written in a constructive style. After all is there a language that can't be criticised? Is the post written to make one feel better having a failed a project the language? (It's not me, it's the language) Or is it the failure to understand that not everyone thinks…

Bjarne said it best; There are only two kinds of languages: the ones people complain about and the ones nobody uses.

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

#397

Post by robocat »

masklinn wrote: post #78
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…

> 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 MRV, go does not have tuples. Go is not the only language with MRV (as a special case) and they’re not necessarily bad, iirc Common Lisp uses them as auxiliary data channels and has a whole host of functions to manipulate and refit them. Go is singularly incompetent at…

> MRV

Acronym for Multiple Return Values https://gobyexample.com/multiple-return-values

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

#398

Post by Arnavion »

sshine wrote: post #265
biorach wrote: post #210

Earlier quoted context omitted.

> These are fully equivalent in outcome They are so different in DX, ergonomics, implementation and traceability that I'm not sure this is true other than in the most abstract sense

There is some DX similarity between checked exceptions and Result types. Because the compiler will fail if you don't explicitly mention each possible exception. But checked exceptions are coming out of style: They're unchecked in C#, and frameworks like Spring Boot in Java catch all checked exceptions and rethrow them as Spring Boot flavored unchecked ones. For unchecked exceptions and Result types: The DX is very di…

>Because the compiler will fail if you don't explicitly mention each possible exception.

But only the first time. Once you add `throws FooException` to the caller signature, the compiler won't complain about any future callees that also happen to throw FooException, even if you did care about handling their exceptions yourself. With callees that return Result you do get to make that decision for every callee.

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

#399

Post by monksy »

kybernetikos wrote: post #362
monksy wrote: post #79

Earlier quoted context omitted.

> consistency of code There are many stylecheck tools that should be apart of a good stack. Accepting the creator's style is putting a lot of weight on their opinion. Most organizations have their own preferences for good reason. > short ramp up for junior engineers Junior engineers aren't a place you're concerned on being productive. Most of the time at that stage in someone's career they should be learning more, ge…

> Both of those things have very little to do with server environments My experience of bigcorp is that they need lots of servers (http is the modern bailer twine) and want developers to act as far as possible as indistinguishable resource. They will have rotating, high churn, globally distributed teams of vendors, contractors, consultants, internal staff and the teams will encompass a vast range of skill levels and…

This is where I would argue that it's a terrible language choice for the environment. (The need for rest frameworks) There aren't a lot of established or mature options for this, and a lot of them don't give you very much to work off of. It's going to be a bumpy road for exploits in this area.

> act as a indistinguishable resource rotating high churn, globally distributed teams of vendors, contactors, consultants, internal staff...

So this is a huge organizational problem that isn't helped by Go. This is more of a higher level problem and the lack of technical leadership in the company. Any language you go with .. you're not going to do well by trying to utilize everyone there. Picking a language that gives you the impression that you can blend the skill levels will end up with a disastrous mistake with a lot of slippage on the development side. Will you generate a ton of code? Yes, the language encourages it.

What I do agree with you: It does encourage the mass hiring of developers with low to no expectations of performance. (Seems like that's google's focus these days) But that's a bad thing for the developer who wants to achieve a lot of results (not just write lines), and to develop our teams.

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

#400

Post by sanderjd »

prmph wrote: post #376
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…

So here is my take on this, once again: Start with JavaScript. The basic syntax is delightfully direct, it has massive adoption already, the ecosystem is large, the runtimes are getting better all the time, compilation is here with WASM, Now remove the weird parts (e.g., too much flexibility to redefine things, too much use of the global scope, too much weirdness with numbers, etc.), and add: - Types (including sum/p…

I think this is a really wise take, and one that I honestly haven't seen before. I would certainly try a language like this.

The one thing I would add: Provide a well-trodden path to easily drop down into Rust/C/C++ for performance critical functionality. I have found this to be a big point in Python's favor over Go; you can write things the slow way (ie. executing in the Python runtime), then profile and figure out where to push things down into an extension. Often you're doing something that already exists in a library like numpy or pandas or polars, but if needed, you can write your own extension.

Does WASM enable FFI on its own?

Post reply on HN