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

121–130 of 305 posts

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

#121

Post by tialaramex »

LastMuel wrote: post #113
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?

I'd guess the typical situation is you had thought maybe a public API featuring enunciate_spools() was a good idea, but eventually you realised actually nobody actually wants to enunciate spools and few people know how, when you see other people's code that calls enunciate_spools, it's always either a bug (and they shouldn't have) or test code that is inappropriately testing your stuff not their stuff.

So you make it private, in say Rust that's an ABI break, so you need a semver bump, but you aren't changing your code. Internally normal_operation does need to enunciate spools, not to mention the acrobatic use of it in complex_operation and fancy_coroutine but that's because it knows intimately what spools are and why it's enunciating them - it's an internal design element, not an API.

In Go, you have to rename it everywhere. Maybe your tooling helps with that. OK, but, not having to do it also helps with that and for everybody.

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

#122

Post by dogleash »

cempaka wrote: post #72
nullwarp wrote: post #62

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…

> 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?

pmuch.

I migrated a team off of an aging enterprise application to the product that was rapidly gaining popularity in industry. I had some expertise and believed in it, I won't name products (and it wouldn't mean anything to HN anyway) but this was a painfully obvious change. We were the pilot project at the company, and went though 6 months of most users struggling. It was about 18 months after adoption that my boss told me he felt like the new product was both better and that the slow down had been worth it.

Life isn't long enough for too many of those experiments. Not everything takes that long. And the experiment could have failed. But the experience really put lots of decisions into perspective.

There's a saying that nobody uses technologies that their boss didn't learn in college. Factually inaccurate, quite astute in message.

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

#123

Post by irq-1 »

j1elo wrote: post #65

I'd categorize not being able to convert "unused thing" errors into warnings during development iterations as one of "The Bad". Just today I had a couple blocks of code which were causing erratic issues. Wanted to see if it was the second one, so I quickly commented it out. This is just an exploratory development session, no need to comply with code quality guidelines. Still, the code failed to compile because now I…

This is just an intractable problem: if there is any way for people to leave unused code, they will. If you want the code to be clean, you cannot have (for example) a debug mode that allows unused code, because the code will just be left in 'debug' format. Eventually the community shared code will have so much debug-but-it-works code that you'll never get a system of clean code.

And think of what the current strict rule has done: go is the only(?!) language that has a consistently clean ecosystem. When's the last time you looked at go code that huge chunks commented out?

That said... it is annoying. More annoying the less import the script, and the faster you want to test something.

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

#124

Post by vl »

The biggest go problem in practice is ironically omitted in both blog posts:

Verbosity of error handling!

There should be a shorthand for returning if last ret value is non-nil in one line. Otherwise all you code is littered with:

    if err != nil {
        return err
    }
and it makes it four times as long and way less readable as a result. This needless verbosity really reminds me of Java.

Also, go fmt is not opinionated enough! There really should be one way to line break and max width. Right now you can't rely on it to magically format it as it "should be" and fire-and-forget when typing.

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

#125

Post by Capricorn2481 »

nateb2022 wrote: post #112
za3faran wrote: post #70

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…

C# has way, way more market share than Go as well as a bigger ecosystem and it's not even close. I would hardly call a Java replacement a "niche" since that's everywhere.

There are, of course, other benchmarks that rank c# above go, but benchmarks are flawed. I imagine people are comparing C# to go because it's got a pretty solid type system

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

#126

Post by arcanemachiner »

drBonkers wrote: post #76
macintux wrote: post #54

Earlier quoted context omitted.

Erlang had a better concurrency story than Go, and better error handling. But alas marketing wins.

Erlang is dynamically typed.

The process of bringing types to Elixir is officially underway:

https://elixir-lang.org/blog/2023/06/22/type-system-updates-...

It's not Erlang specifically, but it is a BEAM language, so tomato tomahto.

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

#127

Post by btilly »

wk_end wrote: 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 through internal access to a very large and actively maintained codebase at Google. A codebase into which they had inserted several other languages that they had devised for various purposes.

I'm pretty sure that nobody in the external programming languages community had the same depth of experience in the practical use of programming languages that the Go team had. And so it was bizarre to them to see the Go team deliberately leave features out because of concerns about how those features are used in practice.

Few of the critics who "knew about programming languages" have created any language that ever made it into the top 10 programming languages in the world. It is therefore funny to me that they were complaining about exactly the kinds of choices that lead to Go becoming popular.

I'll generally take the design choices of a team with 2 popular languages under their belt over academics in the ivory tower.

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

#128

Post by candiddevmike »

vl wrote: post #124

The biggest go problem in practice is ironically omitted in both blog posts: Verbosity of error handling! There should be a shorthand for returning if last ret value is non-nil in one line. Otherwise all you code is littered with: if err != nil { return err } and it makes it four times as long and way less readable as a result. This needless verbosity really reminds me of Java. Also, go fmt is not opinionated enough!…

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.

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

#129

Post by SiVal »

j1elo wrote: post #65

I'd categorize not being able to convert "unused thing" errors into warnings during development iterations as one of "The Bad". Just today I had a couple blocks of code which were causing erratic issues. Wanted to see if it was the second one, so I quickly commented it out. This is just an exploratory development session, no need to comply with code quality guidelines. Still, the code failed to compile because now I…

I completely agree. The wonderful speed of the compiler allows for quick small-change, test, small-change, test development. In theory. They then sabotage it by making "unused" warnings into errors, which forces you to waste the time the fast compiler could have saved, making temporary changes (ex: commenting out/in) that aren't needed for the test and won't be needed for production.

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

#130

Post by recursive »

stefncb wrote: post #34
recursive wrote: post #6

Earlier quoted context omitted.

The documentation for DBNull [1] seems to have some idea that DBNull represents something entirely different. > Do not confuse the notion of null in an object-oriented programming language with a DBNull object. In an object-oriented programming language, null means the absence of a reference to an object. DBNull represents an uninitialized variant or nonexistent database column. For all the explanation though, I coul…

I don't know C#, but I'll take a guess: I think it's exactly the same issue as null in Lisp and Lua — you sometimes want to differentiate between null as in "I returned no value", and null as in "I returned the fact that there is no value". Or null vs false vs empty list in the context of Lisp. This distinction becomes very clear (and sometimes very annoying) when you realize that in Lua, setting a table key to null…

I don't know lua. But the behavior you describe seems like a quirk of lua tables. Instead of having `table.get(key)` return a sentinel value, you can replace it with `table.has_key(key)` and `table.get(key)`.

I'm not sure about the ergonomics of the trade in lua. But in C# the ergonomics of `DBNull` are terrible. If it were just replaced with `null` everywhere, everything would just be better.

IMHO.

Post reply on HN