Live data from Hacker News

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

fasterthanli.me

391–400 of 477 posts

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

#391
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…

What I wonder, is if by designing a language to enable happy corporates, rather than happy programers, is Go not shooting itself in the foot, as the now less happy programmers (because corp mandated Go) would move to other corps, creating more cost to the corporate than if they had use a more joy-inducing language. IOW, Go is probably great if you're quite big. But like most Google created dev tools, the questions we…

So the purpose of a programming language is to spark joy in developers? I mean, I get it, but it's a very selfish position to take and it's not in the interest of a business, in the end.

I mean, Java makes me feel dead inside, but I appreciate it for being ubiquitous and reliable, and that a business will be able to find half-decent Java developers any day of the week.

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

#392
I can definitely tell the author put a lot of time and energy into this article and is generally more intelligent than I am so I'm absolutely not trying to be difficult here, but I.. how to put it.. well, disagree. Kind of. It's complex.

You are raising valid engineering concerns. You rightly point out that the handling of permissions on Windows is subpar and Go really sucks balls when it comes to handling files named '\275\262=\274 ⌘'. I mean, it's hard to disagree here and I don't.

It's just hard to shake the feeling these things, in practice, just. do. not. matter. These are issues you solve once with an as ugly-as-needed solution and stow away in a package with a clean interface. I agree, it's not pretty and it would be awesome if the language would have handled this better by default but it just doesn't. Handling of files called '\275\262=\274 ⌘' is not going to convert me to Rust, which while generally awesome also its own - different - set of major issues. Everything is a trade off and Go just sometimes wins, even if it also sometimes sucks. The point is that the stuff it sucks at is usually not important for the domain it's meant to shine in. I'm sorry, handling files on Windows.. I don't know what to say. "I'm sorry" is all I can think of.

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

#393
post #177

Earlier quoted context omitted.

I have asked to myself and answer seems yes. I wrote a tool many years ago in Go. It has saved me at least 100 times the hours I put in to code it. And I put in couple of weeks at max. The point here is I created a tool (my application) using another tool (Go) and I care quite a bit more about my tool, features, usability and so on. Programing language provided few features like single binary so I can install on VMs,…

I don't care about past tense. If you had to write every day in Go, would you still be happy about it? (I sure wouldn't)

I write Go every day, and have done so for the past two years or so (along Typescript, JS and PHP, the latter two for a 'legacy' application), and I'm happy with the language.

If I were to criticise it, there's a few things that come to mind:

- Struct tags don't feel right; it's string-based annotations and some libraries design whole DSLs in them.

- The community seems to push towards using hexagonal or clean design, but unless I'm getting it wrong, this leads to a lot of really tedious conversion / adapter code.

- There's not many good tools out there (yet?) to make things easier, e.g. database abstraction layers. Writing lower level SQL and some utilities to help with that is still better, but it's tedious and voluminous (like using raw JDBC and iterating over ResultSets). I've used ent (which required manual mapping between every struct field and every column, unless I got it wrong) and gorm (which breaks down when you nest deeper than one level), currently have about 40 tables.

But these are issues that show up, I think, in any larger application.

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

#394
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…

Seems too many devs use go for something it is not meant for. Tried doing math calculations in go - not a good a idea. But for backend stuff like rest api, web servers, networking, sysadmin and devops tasks, it shines.

I mean, a lot of developers have or look for a golden hammer, coerce their favorite language in doing a task. And since every programming language is turing complete, it CAN work, but whether it's the most elegant is not guaranteed.

I mean for math, similarly, Java and co wouldn't work very well either.

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

#395
post #39

Golang is great because it was the first to include excellent tooling in addition to the language (strict compiler, linting, non-customizable gofmt, package manager, good html docs, online playground, etc.) It’s undeniable that it brought a lot of good ideas that languages like Rust borrowed. Golang is still undefeated in terms of battery included. Its standard library is top notch and full featured. On the other han…

Java and Erlang both have phenomenal tooling, especially when it comes to runtime introspection and debugging.

I'd say Java and the JVM is the most overcomplete language and ecosystem out there when it comes to available tooling.

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

#396

I am both bemused and empathetic for those who keep having this realization with Go. It is like an abusive relationship and people stay in it too long before realizing it is not going to get any better. I took a look early on at Go. I tinkered with it and decided it would not work for me. It lacked a lot of things that any new language should have, given the lessons learned in language design over the last few decade…

> I was working with Java before and after generics and saw what a mess it made to not design it in from the beginning.

Counterpoints; was the concept of generics a thing before Java implemented it? That is, could they have known?

Second, a ton of the Java spec and compilers and stuff is dedicated to generics; would it have been less complicated and voluminous if Java had it from the start?

With Go, they took their time to think about generics, just to avoid bloating half the compiler with implementations and workarounds and the like just to support generics, or to not end up with Scala's massive architecture. Their focus remains on a simple language, simple code, and a fast compiler; in many ways it's the antithesis of Scala in that regard.

anyway, just some Thoughts I have on the matter.

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

#397

Earlier quoted context omitted.

> What an extremely convenient template to dismiss any nuanced argument against "worse is better". You say that like its a bad thing. If there is an easy template to dismiss your argument, it means you did a bad job arguing. Part of making a good argument is anticipating likely objections and addressing then in your argument

Note that a "dismissal" is not the same as an actual rebuttal. A template can just as easily generate a tricky-to-dissect fallacy or bad-faith argument as actual logic.

I disagree - if its a template that is commonly used, someone only has to dissect it once.

Regardless, what exactly is tricky to disect or falacious about this template? The rebbutal is basically:

* go is trying to optimize for different things

* go makes no secret that its trying to optimize for different things

* some people like the things that go optimizes for (and some people don't).

* [with an implied] if you intentionally used a tool that made choices you don't like, and its not a secret they made those choices, is it really the tool's fault or your fault? Its like ordering ice cream and being mad the ice cream is cold.

If the original argument was more phrased as the types of design choices go makes are bad, it would probably be more palatable (but also less interesting, because whether worse really is better is flame war that has been going on for decades)

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

#398
post #310

Earlier quoted context omitted.

> What an extremely convenient template to dismiss any nuanced argument against "worse is better". Nuance is exactly what I'm arguing for, there's none in the article. > You even get to question my credentials a couple times! (I apparently pick metrics that are convenient to my argument, and fundamentally misunderstand programming language design). You're right, I apologize. I usually try hard to never directly addre…

Agreed. I just want to make clear that Rust/Ada/etc. don't give correctness guarantees! Their compiler is just more enforcing. It's all not black and white. Rust is promoted for its correctness, but those correctness related bugs Rust prevents are an extremely low fraction of real world bugs (comparing to managed memory languages). I mean, how many type-system related bugs are there in real world projects with Java,…

I mean, just yesterday while I was running the JetBrains Rider install workflow, I hit a NullReferenceException (or whatever it's called in Java). That is a type-system related bug which arises only because Java's type system trivially represents illegal state.

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

#399

Earlier quoted context omitted.

I've been developing Python professionally for 15 years, including almost a decade of deploying to containers. I think Go is much easier to use (especially in a container environment): 1. Static types make it much easier to read and write code for even a single individual, and the benefit scales superlinearly as the contributor count and code base age increase. Go also has a ton of other tooling which just outclasses…

> If you want reproducibility, it takes ~30 minutes just to resolve dependencies for relatively small-but-not-toy-sized projects. I will be the first to complain about Python packaging, but 30 minutes is far far beyond anything I have experienced.

It seems approximately correct to me. I always do `--no-dependencies` when I have a `pip freeze` output, for exactly this reason.

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

#400

Earlier quoted context omitted.

For small companies, variance can be good. For large companies, avoiding surprises is everything. So they cram a bunch of processes to make everyone a B player. That’s great if you’re naturally a C player, and can be less work if you’re a B+ player who wants to coast. But it’s hell hell if you’re an A player who is now working with handcuffs, and getting paid the same as the C player.

Can you consider yourself an A player if you think yourself too good to work with B / C players in a language that, as you say, handcuffs you? I mean it frees you up mentally to think about the bigger problems, beyond the bit of code you're working on right now. In the end, the person writing the code is just a cog in the machine. You can try and pretend you're an Important cog by being Very Clever and using very sma…

It’s not the people who handcuff, it’s the process.

I will use Sales since the metrics less ambiguous there. In a startup, without a lot of structure, a great salesperson will find deals that others can’t, and will close many more of them. They will have the autonomy to get things done and are rewarded when they crush their quotas.

In large companies, there are all kinds of Marketing and Sales support programs that lift the average salesman. But a great salesman is told “Only talk to companies on your list” and “All your deals must get approved by the deal desk” and “Don’t sell more than X because it will ruffle feathers downstream” These processes are good in aggregate but drive top performers nuts.

Post reply on HN