Live data from Hacker News

Ten years of “Go: The good, the bad, and the meh”

blog.carlmjohnson.net

161–170 of 305 posts

Re: Ten years of “Go: The good, the bad, and the meh”

#161
post #127
post #46

> Again, it shows how things have changed that I praised Go’s type inference as an advance in the state of the art, but now the Hacker News crowd considers Go’s type inference to be very limited compared to other languages. "You either die a language nobody uses or live long enough to be one people complain about." This rubs me the wrong way. Even back when Go first came out, anyone who knew anything about programmin…

Even back when Go first came out, anyone who knew anything about programming languages rolled their eyes at pretty much everything about Go's type system, including the inference. The Go team was populated by people who had created one of the most influential languages of all time, C. Who created the new language based on theories about how to encourage good engineering practice. Theories that they were able to test…

One of the designers said that they had to dumb it down to the lowest common denominator Google engineer.

Re: Ten years of “Go: The good, the bad, and the meh”

#162

Earlier quoted context omitted.

This is a pretty arbitrary benchmark. I would guess, again, that 95% of programmers have never and will never need to create a tree map. Repeat for numerous collections and APIs that are totally irrelevant to most programmers' actual experience of programming. Go is optimized for use, not computer science edge cases. And as a result it is widely used, and some of the most complicated and widely-used open-source proje…

It's not about creating a tree map, it's just about using one. Maybe even one provided by a library, doesn't matter. I'm sure that 95% of the developers will need a tree map at least once in their career.

I've been using Golang professionally for about a decade. In that time the only place I've ever needed to use a tree map was an interview that specifically called for it.

Whose usage are you trying to optimize the language for? Golang is not a good academic language. But it is extremely good for actually solving problems with code.

Re: Ten years of “Go: The good, the bad, and the meh”

#163
post #42

Go didn't try to be overly clever and abstract. That rubs quite a few people the wrong way, but it also means you are less likely to have to work with people who try to be clever. My first reaction when seeing Go is that it smelled of "old fart". It looked straightforward and unexciting. I'm an old fart. I like straightforward and unexciting. It tends to lead to code that I can still read 6 months from now. I want to…

Since when has "clever" become something negative? If someone is clever, that's a good thing! I also try to be clever when I do things, be it repairing something, planning my workout routine or programming.

I've heard the drum against clever code for over a decade. This sums it up well:

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan

Re: Ten years of “Go: The good, the bad, and the meh”

#164
A bit off topic but...

I need some resources for evangelizing GO.

I do not use it, but...

I have a colleague who needs/wants to replace a PHP/Laravel mess. They are talking up Node.js

I think GO would be a better choice

This article is close to what I need, but is there anything better?

The server side code they are looking to replace is handling sensitive financial information and I am very queasy using Node.js in that domain

Re: Ten years of “Go: The good, the bad, and the meh”

#165
post #137

Earlier quoted context omitted.

Your code shouldn't be littered with that though, those errors should be wrapped or have some kind of logging/handling associated with them. If you find yourself just returning err all the time, you're not doing it right, IMO.

In practice if you look into existing codebases, it is littered. defer is used for RAII-style clean up, so in 95% of the cases it's just return the error and that's it.

Real world code base developed over a decade. Handles billions of emails.

Searching our prod code, "naked" if-err-return-err showed up in about 5% of error handling cases, the rest did something more (attempted a fallback, added context, logged something, metric maybe, etc).

If you are doing a naked return you are gonna have a bad time.

Re: Ten years of “Go: The good, the bad, and the meh”

#166
post #127

Earlier quoted context omitted.

Even back when Go first came out, anyone who knew anything about programming languages rolled their eyes at pretty much everything about Go's type system, including the inference. The Go team was populated by people who had created one of the most influential languages of all time, C. Who created the new language based on theories about how to encourage good engineering practice. Theories that they were able to test…

C is also a very low-level and close to the machine language. Just because you can build a microchip doesn't mean you can build a spaceship and vice versa. So I'm not surprised about that they e.g. left out generics and said they did so because they didn't know a good or right way to add them to the language. They were honest at least which I value a lot. As to the success of Go that you mention. Well, let's be hones…

Well, let's be honest: it targets junior developers, or at least that was originally a major goal. It is backed by Google and is marketed.

It actually targeted Google developers. It was a 20% project that was not backed by the company officially. Official backing only came *AFTER* others were convinced internally that it was worthy. Their marketing budget started at a grand total of $0.

So it stated with NONE of the factors that you cite as its advantages. Though, to be fair, its core team includes people who a lot of programmers respect.

... they demand language features that make them more productive - like generics. And they will be added...

You mean already were added about a year ago. See https://go.dev/blog/go1.18.

... it will be the new python.

Interestingly, internally at Google it replaced Python. As a reasonably fast to develop in language, with substantially lower maintenance costs. And let me assure you, Google has done a lot of work on looking at what both development and maintenance cost them internally.

But it is not by any means an advanced high-level language in any sense that I would know of.

Can you provide a reason why we should care about a language being "an advanced high-level language"?

Re: Ten years of “Go: The good, the bad, and the meh”

#167
post #131

Earlier quoted context omitted.

It still doesn't catch everything.

I am not aware of an option that "catches everything", in any langauge.

Any language with exceptions, checked or unchecked, will not allow errors to unintentionally get swallowed unless you write explicit code to do so. Rust and Zig's error handling also has the same property.

This comes from experience working on large golang code bases, with error linters, and seeing errors silently and unintentionally ignored.

Re: Ten years of “Go: The good, the bad, and the meh”

#168

Earlier quoted context omitted.

golang mainly ended up competing with and replacing the likes of python and ruby, where it was intended to compete with C and C++, where it didn't really change anything. It makes sense in retrospect of course, python and ruby are slow, dynamically typed languages, and any improvement in performance and typing is welcome. It doesn't mean that golang is inherently better somehow to other offerings. I still maintain th…

Why C#? It definitely has its own niche, and is good for building userspace Windows apps and games, however beyond Windows I don't think it has neither an established presence nor ecosystem. If anything, C# attempts to be more of a Java replacement than address Go's niche. Performance-wise, C# and Go are head-to-head: https://programming-language-benchmarks.vercel.app/go-vs-csh... I also would say Go has been much mo…

> however beyond Windows I don't think it has neither an established presence nor ecosystem

I'd respectfully disagree with this statement based on my personal experience. Ever since .NET Core was introduced, I've noticed a significant shift in the hosting of ASP.NET apps. Many developers, including myself, now prefer hosting applications in containers on Linux systems rather than relying solely on Windows. This change reflects a broader trend among C# developers.

While I understand that my perspective might not encompass the entire developer community, I strongly believe that the adoption of Linux-based hosting for ASP.NET applications has grown considerably. It demonstrates the expanding reach and influence of .NET Core beyond the Windows ecosystem, proving its establishment in other platforms.

Please note that this is solely my viewpoint based on my experiences and interactions with other developers. Other opinions may vary, but I remain confident in the growing prominence of .NET Core outside of the traditional Windows environment.

Re: Ten years of “Go: The good, the bad, and the meh”

#169
post #42

Go didn't try to be overly clever and abstract. That rubs quite a few people the wrong way, but it also means you are less likely to have to work with people who try to be clever. My first reaction when seeing Go is that it smelled of "old fart". It looked straightforward and unexciting. I'm an old fart. I like straightforward and unexciting. It tends to lead to code that I can still read 6 months from now. I want to…

Since when has "clever" become something negative? If someone is clever, that's a good thing! I also try to be clever when I do things, be it repairing something, planning my workout routine or programming.

Maintaining "clever" code is incredibly hard because the only "clever" person is the one that wrote it, everyone else is "dumb" to it. One can take hours debugging clever code. Obvious code won't wow anyone but will be immediately understandable, which is an advantage in a team setting.

Re: Ten years of “Go: The good, the bad, and the meh”

#170
post #72

Earlier quoted context omitted.

Go really is great. There was a big argument around a new project we were starting whether to do Go or Clojure. What we did to settle the debate was to ask an entry level dev that was just starting if he was interesting in writing two sample applications in each language, having known nothing of either. Nothing complicated but touched enough points (HTTP endpoints, database interaction) A full day later was still try…

As a method for choosing a language, doesn't this just inherently skew to the smaller and more simplistic one, which may not necessarily be the best for all tasks or over a longer run where the techniques of the more involved language could be learned? It's like hiring a new farmhand and saying, "here, dig two 3 foot holes, and we'll see what takes you longer, this shovel or an excavator you have no training or exper…

Go is basically C with training wheels, THAT CAN NEVER BE REMOVED.

It accelerates junior devs to production ready at the expense of everyone else.

It really feels like a language designed by people with utter contempt for those who actually write code.

Post reply on HN