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

I want off Mr. Golang’s Wild Ride (2020)

fasterthanli.me

Post reply on HN
Print view View original

141–150 of 477 posts

Re: I want off Mr. Golang’s Wild Ride (2020)

#141

Post by recuter »

bb88 wrote: post #131
recuter wrote: post #118

Earlier quoted context omitted.

Lately I've had comments swing wildly dozens of points in each direction and also flagged. Brigadiering has come to HN and is getting worse over time. There seems to be a growing segment of internet users who wish to cleanse perceived wrong think, it is disturbing and not what flags/downvotes are for. It also feels like there is more bots.

Go look at HCQ/Ivermectin/Cryptocurrency for examples of such brigadiering.

Well yeah, there are a lot of those "controversial" subjects that attract far-left far-right flamewars and this has normalized using downvotes/flags as a weapon. Even about innocuous things. Which is... weird and sad.

Re: I want off Mr. Golang’s Wild Ride (2020)

#142

Post by Mawr »

mcronce wrote: post #81
throwaway894345 wrote: post #76

Earlier quoted context omitted.

> Screen real estate is limited, especially vertical real estate. Compared to languages with saner error handling, I can read approximately 25% as much Go code at once. In my experience, people can't actually read everything on the screen at one time anyway, and the more dense/terse things are the harder it is to read (otherwise we would minify everything). > I'd much rather the program crash by default than attempt…

> In my experience, people can't actually read everything on the screen at one time anyway, and the more dense/terse things are the harder it is to read (otherwise we would minify everything). Whether or not you can read everything on the screen at one time is missing the point entirely. The point is that context matters, and the more frequently you have to scroll to find it is more cognitive burden. > It's not likel…

> > in practice, Go seems to have fewer error handling bugs than exception-based languages

>

> This is based on?

By explicitly annotating functions as fallible the language hints to the programmer that errors need to be accounted for.

With exceptions, the hints only appear at runtime - when your program crashes. There's nothing that nudges you towards handling errors at the point of writing code, so you end up with brittle software.

Re: I want off Mr. Golang’s Wild Ride (2020)

#143

Post by mmcdermott »

jitl wrote: post #65
lumost wrote: post #9

My Anecdotal Experience: Golang is great for spinning up new services and tools with very little overhead, the language is well designed for the backend - and the lack of avoids "odd" decisions which other engineers will dislike in the future. If your job is building lots of new things using relatively common building blocks, then Golang looks fantastic! However on mature services, engineers often need because they a…

The Kubernetes codebase is huge, but in my (limited) experience I really felt like it was delivering on Go’s promise: that I can read any given file and understand what’s happening. At least when I needed to debug Kubernetes issues 4 years ago, I could grep around, dive into a file, and command-click to “go to definition” and quickly build a local understanding of the code around my problem. No spooky action. Everyth…

I hadn't thought of it that way. Trading verbosity for clarity was always COBOL's shtick. I had always thought of Java as this gen's COBOL, but maybe the reflection oriented frameworks in common use undercut that use case and Golang would do it better.

Re: I want off Mr. Golang’s Wild Ride (2020)

#144

Post by t43562 »

"Cross platform handling is bad."

That's all I've had the energy to extract. Isn't cross-platform software always a nasty compromise between not being able to do anything useful and being too specific to some OS or another. IMO go write a library if it really annoys you.

There are much more unpleasant problems that I've had with the language but I've had more with C++ so ... it's a step up for me.

Re: I want off Mr. Golang’s Wild Ride (2020)

#145

Post by tonyarkles »

AnimalMuppet wrote: post #127
reedjosh wrote: post #122

Earlier quoted context omitted.

> It is tedious. > to reduce the variance between the best programmer on a project and the worst. In my experience the only way this can be done as with trying to level anything is to bring down the level of the best. I find this awful.

It may be awful to the best programmer. But if you're looking at the team as a whole, well, how many of the best do you have on the team? It's really hard to create large teams where the average programmer on the team is better than the average programmer in the country. If you can bring up the lower half of the team, that may be a net win, even if it brings down the best one on the team. The effect of that may be th…

I used Go (didn’t choose it exactly) at an olds job of mine 4 or 5 years ago. I was definitely the most senior and very likely the best developer at the company. Organizationally, many of their backend services were Java-based using Spring Boot, although there were a few Python and NodeJS ones as well. My general observation was:

The people who called themselves Java programmers or Python programmers or JavaScript programmers complained a ton about Go. The people who weren’t committed to any particular language didn’t seem to mind at all.

(I am in the whatever-language-let’s-write-code camp myself)

We weren’t in love with it. I don’t use it for spare time projects (woo Common Lisp with SBCL). The only super positive feedback I really remember is “wow! It’s so easy to just walk through from when the program starts to knowing where all the endpoints are and where you can find the source!” which isn’t so much praise of Go but an indictment of Spring Boot.

Re: I want off Mr. Golang’s Wild Ride (2020)

#146

Post by zasdffaa »

lumost wrote: post #9

My Anecdotal Experience: Golang is great for spinning up new services and tools with very little overhead, the language is well designed for the backend - and the lack of avoids "odd" decisions which other engineers will dislike in the future. If your job is building lots of new things using relatively common building blocks, then Golang looks fantastic! However on mature services, engineers often need because they a…

> or implement the same function N times over to support the different numeric data types

Did you consider using a preprocessor or suchlike

Re: I want off Mr. Golang’s Wild Ride (2020)

#147

Post by proctrap »

fasterthanlime wrote: post #64

Author here: I wrote this in 2020, have changed jobs twice since. Both jobs involved Go in some capacity, where it's supposed to shine (web services). It has not been a pleasant experience either - I've lost count of the amount of incidents directly caused by poor error handling, or Go default values. If folks walk away with only one new thought from this, please let it be that: defaults matter. Go lets you whip some…

I think you can add this to your original post.

Re: I want off Mr. Golang’s Wild Ride (2020)

#148

Post by BobbyJo »

reedjosh wrote: post #122
jitl wrote: post #65

Earlier quoted context omitted.

The Kubernetes codebase is huge, but in my (limited) experience I really felt like it was delivering on Go’s promise: that I can read any given file and understand what’s happening. At least when I needed to debug Kubernetes issues 4 years ago, I could grep around, dive into a file, and command-click to “go to definition” and quickly build a local understanding of the code around my problem. No spooky action. Everyth…

> It is tedious. > to reduce the variance between the best programmer on a project and the worst. In my experience the only way this can be done as with trying to level anything is to bring down the level of the best. I find this awful.

I've found Go's compromises help good programmers too over the long run.

It isn't lowering the variance by slowing down the quick, it does it by shrinking the space of possible solutions. Bad programmers and good programmers wind up making similar "good enough" design choices. You don't wind up with over engineered frameworks for every bit of logic in you backend.

Re: I want off Mr. Golang’s Wild Ride (2020)

#149

Post by tonyarkles »

gmfawcett wrote: post #133
AnimalMuppet wrote: post #127

Earlier quoted context omitted.

It may be awful to the best programmer. But if you're looking at the team as a whole, well, how many of the best do you have on the team? It's really hard to create large teams where the average programmer on the team is better than the average programmer in the country. If you can bring up the lower half of the team, that may be a net win, even if it brings down the best one on the team. The effect of that may be th…

If the skill difference among your devs is really high, it may be preferable to have the best programmer leave, or at least change roles (architect, team lead, trainer), as this may increase productivity of the median workers. At least the skill difference should be treated as a risk and properly mitigated.

In the role in my sibling comment, I somewhat filled the role of the developer that went away. Hardcore Java/Spring Boot guy who could wrap his head around these amazingly complex code bases he made that the younger/less experienced devs could not manage on their own. I spent a ton of time mentoring in my role, and hopefully helped undo some of the mental damage the previous guy did :D. Things were running much smoother when I left then they did when I first joined at least, with teams that could have chosen whatever language they wanted choosing Go voluntarily.

Re: I want off Mr. Golang’s Wild Ride (2020)

#150

Post by dhzhzjsbevs »

AnimalMuppet wrote: post #127
reedjosh wrote: post #122

Earlier quoted context omitted.

> It is tedious. > to reduce the variance between the best programmer on a project and the worst. In my experience the only way this can be done as with trying to level anything is to bring down the level of the best. I find this awful.

It may be awful to the best programmer. But if you're looking at the team as a whole, well, how many of the best do you have on the team? It's really hard to create large teams where the average programmer on the team is better than the average programmer in the country. If you can bring up the lower half of the team, that may be a net win, even if it brings down the best one on the team. The effect of that may be th…

Meh, the best developers sound like whiny brats.

I'm not the best developer but I've been around long enough to know that bringing the bottom half of development up to the plate does more for me in my day job than catering to what magic bullshit the "best" developers are pumping.

Post reply on HN