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

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

blog.carlmjohnson.net

Post reply on HN
Print view View original

111–120 of 305 posts

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

#111

Post by pie_flavor »

Veraticus wrote: post #94
woooooo wrote: post #91

Earlier quoted context omitted.

Collections obviously need to be generic though. Slices and maps were generic from day 1 in go so it's not like this is controversial.

For sure — a lot of language features need to be generic. But most people aren’t coding language features, and giving them the ability to do so can lead to, well, CodeFactoryFactoryMakerGenericMethodHelpersFactory, rather than good, clear, usable code.

There is no language feature for a tree map. Many problems require a tree map. Either inclusion of generics was a good thing, or it is worth sacrificing static typing or requiring codegen for these use cases. Repeat for numerous collections and APIs.

Disallowing someone from using easy statically typed tree maps is not accomplishing any of the simplicity virtues people trumpet Go for having. While the much-warned-of castles of inappropriately applied generics have yet to be found in any codebase I've worked with in any language, including Rust.

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

#112

Post by nateb2022 »

za3faran wrote: post #70
softirq wrote: post #57

Earlier quoted context omitted.

> anyone who knew anything about programming languages rolled their eyes at pretty much everything about Go's type system And Go has succeeded despite these condescending diatribes on how a language needs to have a Hindley-Milner type system with ADTs and type classes to be useful. Go made me truly realize how insufferable the PLT community is, and why they are so absolutely lost when it comes to creating successful…

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 more adopted for cross-platform use than C# ever was. Regarding language features, Go's devotion to staying intentionally bare-bones is worth a lot. C# may be more elegant in a lot of ways, however it seems to be in the process of being choked by Microsoft's continuous feature-creep.

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

#113

Post by LastMuel »

stevemk14ebr wrote: post #106

"What I got right...Using capitalization for the public/private distinction in functions, methods, variables, and fields" I disagree with this strongly. Due to this when you need to change one of these things to the opposite it involves changing every use site as well. This has far reaching implications for refactoring, wrapping external code when you really do need to expose its guts, etc. Any time you need to do th…

Short of changes within the module itself, if you switch a Public function to a private function in another language, how are you not having to go change everywhere it's being used?

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

#114

Post by joshuamorton »

Veraticus wrote: post #69
rowanseymour wrote: post #60

Earlier quoted context omitted.

The reason is the same reason that anyone ever writes a generic function (outside of writing a library) - to keep code DRY and avoid duplication. There is no upside to maintaining a large number of identical function implementations, and no scenario in which that is preferable to using generics.

But you probably will have to differentiate at some point between what you're inserting. Why not just do that, instead of artificially combine it into one function? Nevertheless I feel like I'm getting lost in the weeds of this example. Obviously DRY and less duplication is good. However, you have to strike a balance between being clever and being clear. And frankly I would prefer 3 lines of clear code to 1 line of h…

> But you probably will have to differentiate at some point between what you're inserting. Why not just do that, instead of artificially combine it into one function?

Why prematurely optimize for differences that may not (and in practice aren't really likely to) happen?

Keep in mind that the tradeoff with generics is usually not 3 lines of clear or 1 line of hard to read, it's one line of clear code (T -> T), one line of unclear code (Interface{} -> Interface{} + casts), or n lines of complex code (concretely reimplementing the function for your particular case).

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

#115

Post by john-radio »

nullwarp wrote: post #62
softirq wrote: post #57

Earlier quoted context omitted.

> anyone who knew anything about programming languages rolled their eyes at pretty much everything about Go's type system And Go has succeeded despite these condescending diatribes on how a language needs to have a Hindley-Milner type system with ADTs and type classes to be useful. Go made me truly realize how insufferable the PLT community is, and why they are so absolutely lost when it comes to creating successful…

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…

That's such a interesting experiment, but I can't help but think that whichever language's project was tackled first was playing at a serious disadvantage, even if the projects were somewhat different...

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

#116

Post by philosopher1234 »

tsss wrote: post #110
softirq wrote: post #57

Earlier quoted context omitted.

> anyone who knew anything about programming languages rolled their eyes at pretty much everything about Go's type system And Go has succeeded despite these condescending diatribes on how a language needs to have a Hindley-Milner type system with ADTs and type classes to be useful. Go made me truly realize how insufferable the PLT community is, and why they are so absolutely lost when it comes to creating successful…

Go has "swept up entire markets" because they have an unlimited marketing budget. It has nothing to do with the merits of the language itself.

Can you point to something Go has spent this hypothetical marketing budget on?

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

#117

Post by nateb2022 »

stpedgwdgfhgdd wrote: post #27

Worked with Go over 6 years; my biggest annoyance at the beginning, verbosity of error handling, has mostly gone away. In most cases the explicit error handling helped us hardening the code. What does still bother me is the lack of proper enum support. I remember when Java boosted their enum support and the way it impacted the quality of the code. Sure would love to see something similar in Go.

While not perfect, there are ways to generate enums automatically using go:generate, e.g. https://github.com/abice/go-enum

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

#118

Post by Calamitous »

iamcalledrob wrote: post #43

I am immensely thankful for Go. The simplicity of the language and the stdlib is shockingly well thought out -- things like io.Reader are so obvious and yet not part of many other languages. The language has made me a better programmer. And the cross-compilation story is chefs kiss . Working on a cross-platform project where in Go, I write code and it just builds. In Java, I fight with Gradle. In Swift, I fight the t…

> I wish the protobuf library wasn't awful

I’m curious what you don’t like about it? I haven’t used Go in anger, but I love protobufs, and it’s shocking that Go, of all languages, would have a substandard implementation.

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

#119

Post by aptenoforst »

Night_Thastus wrote: post #103
aptenoforst wrote: post #71

Its a shame that Go as a language is so lacking, the tooling is amazing. I wish there was something like Go but with an actually good programming language attached.

What do you think Go is missing?

Anything that made programming easier in the last 30 years.

I miss Hindley Milner type inference, ADTs, default immutability, sane error handling, pattern matching, and functional collection manipulation.

I'm not even mentioning the time it took to add generics to the language, which should've come from the beginning, and we got a bad implementation of it.

Not saying that it HAS to have all of this, but at least 1 or 2 things of that list would already make Go have much better ergonomics.

Go has no excuse since it's a relatively new programming language, and it could've got some of those from the start.

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

#120

Post by omegabravo »

monksy wrote: post #90
softirq wrote: post #57

Earlier quoted context omitted.

> anyone who knew anything about programming languages rolled their eyes at pretty much everything about Go's type system And Go has succeeded despite these condescending diatribes on how a language needs to have a Hindley-Milner type system with ADTs and type classes to be useful. Go made me truly realize how insufferable the PLT community is, and why they are so absolutely lost when it comes to creating successful…

> you can learn in a day and keep in your head. I'm not sure that this successpoint is really that valuable. It sounds more valuable for those who want butts in seats than it does for long term satisfaction and survivability of your code base.

Being able to read your code you wrote 2 years ago does wonders for survivability, which is a gross simplification of course.

It's a great language for some problems, horrible for others. The problem is people tend to talk as though everyone works in their domain.

Post reply on HN