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

Thirteen Years of Go

go.dev

Post reply on HN
Print view View original

51–60 of 217 posts

Re: Thirteen Years of Go

#51

Post by tptacek »

Laiho wrote: post #37

I really want to love this language, a fast and simple garbage collected lang, but feel like they missed the spot a little. I just wish they did something different with error handling / nil, doesn't feel right for the language. Also whats up with stuff like unused imports being such a big deal?

I keep count in my own code of the number of bugs Go's "damnable use requirement" has caught for me, and I'm now up to 5. It's not a big number, but they were real bugs that would have annoyed the shit out of me if they'd made it into shipping code. I think this is one of the polarizing decisions Go made that is going to turn out to be universal orthodoxy 10 years from now.

I think error handling is the thing about Go that people get most wrong. I believe that what's happened is that Go expected its users to be people fleeing C++ (they definitely got that one wrong), and instead they got a flood of Python and Java developers. Systems programming is error programming. Hiding and abstracting errors in systems code isn't a win; it's a handicap. Fiddly decisions about errors is the whole ballgame. But that's not the case in application code (EAFP!) and Go has been beset by that countervailing sentiment ever since.

That's not to say Go's got error handling perfect; it would be better with matching. But no mainstream language gets errors perfect. What unifies the strong systems languages is that they enable the overt programming of errors.

Re: Thirteen Years of Go

#52

Post by para_parolu »

Laiho wrote: post #37

I really want to love this language, a fast and simple garbage collected lang, but feel like they missed the spot a little. I just wish they did something different with error handling / nil, doesn't feel right for the language. Also whats up with stuff like unused imports being such a big deal?

What’s about unused imports? Imports usually added/removed automatically by editor.

Re: Thirteen Years of Go

#53

Post by tptacek »

jjice wrote: post #50
Xeoncross wrote: post #43

I've enjoyed writing Go for years. However, it's not been the language that does it for me. It's been the combination of features and ecosystem that makes it a default. It's hard to explain, but the language is one you can throw into a team of random developers and come out with benchmarks, tests, CI/CD pipelines, unified code formatting, and good parallel work models (via goroutines) almost every time. Builds are in…

Wholely agree that Go tooling is fantastic, especially since most of it is bundled and directly supported by the language. Honestly my biggest gripe is nillability, but it really doesn't bite me nearly as much as it did in Java or C#. There's a reason it's sliding into the "boring and effective" (that's a good thing) camp of languages, but it's still got some cool factor.

Strong agree. Go isn't my favorite language, but it is my favorite programming tool.

Re: Thirteen Years of Go

#54

Post by roguesherlock »

candiddevmike wrote: post #22
criddell wrote: post #4

Earlier quoted context omitted.

What are some examples? I've always thought of Go as a server-side language.

I built Homechart using Go and documented why/how here: https://homechart.app/blog/tech-stack-api/

I really loved your blog post. Also, your site is an interesting combination of bold, clean and simple. Really well done.

Re: Thirteen Years of Go

#55

Post by doorman2 »

metaltyphoon wrote: post #48
doorman2 wrote: post #44

Earlier quoted context omitted.

In maven, don't you need to update the pom file of the projects to point to the local copy? What's nice about the Go workspace system is that the workspace lives above the individual modules, meaning that the individual modules don't need any modification to pull in local dependencies. E.g. if your workspace looks like this: workspace/ mod1/ mod2/ Then both mod1 and mod2 will pull their dependencies remotely. But if…

This is how a VS Solution is. You can have it anywhere in the file system and points to different projects. How those projects are on your file system its up to you (aka git clone, git submodule)

You can read about the VS solution format here: https://learn.microsoft.com/en-us/visualstudio/extensibility...

As you can see it's quite complicated. The contents of go.work is literally

    mod1/
    mod2/
Also, the go.work file is meant to be your local workspace. If mod1 and mod2 have dependencies between each other, they should declare them explicitly and pull them in from the remote in most cases. The go.work file is only when you want to work on both modules locally. Meaning you don't check in go.work to your github repository in most cases.

Re: Thirteen Years of Go

#56

Post by seanw444 »

valenterry wrote: post #36
lordgroff wrote: post #29

Earlier quoted context omitted.

I honestly have no idea why so many hate the language but I guess the Bjarne Stroustrup rule applies. For me it's a language I always wanted to have: essentially C with a GC, small enough you can carry it in your head with most of the footguns removed. I honestly also have no idea why Rust always makes an appearance in a Go thread, I can't think of two languages with such a diametrically opposite learning complexity.

Simply because it's limiting. Which is good if you are inexperienced, but not so great once you grow and try to become more productive. A more expressive language is a must then or you'll be stuck. For some people it's this feeling of being stuck that they don't like - others can live with it more easily. > I honestly also have no idea why Rust always makes an appearance in a Go thread Both Rust and Go people are ver…

The language is limited, but I do not find it limiting.

Re: Thirteen Years of Go

#57

Post by makestuff »

Xeoncross wrote: post #43

I've enjoyed writing Go for years. However, it's not been the language that does it for me. It's been the combination of features and ecosystem that makes it a default. It's hard to explain, but the language is one you can throw into a team of random developers and come out with benchmarks, tests, CI/CD pipelines, unified code formatting, and good parallel work models (via goroutines) almost every time. Builds are in…

Yeah I was at a startup where maybe 10% of engineering had used go before and 20% had used Java before (it was a PHP monolith so most people were PHP developers). The Java code that was written was pretty awful (I was hired probably due to my java experience, so I had a decent idea of good java). However, the Go services were actually really good. There is something about having a simple language that works really well for backend CRUD services.

Re: Thirteen Years of Go

#58

Post by seanw444 »

lordgroff wrote: post #39
dimgl wrote: post #34

Earlier quoted context omitted.

What is it with people who love Rust? If a language is not an absolute behemoth, it's a kid's language. Do you feel the same way about Lua? Like, this notion is wild to me. > Rust IMO is much more advanced and expressive. It's a joy to write It can be argued that in a professional setting, this isn't what a business cares about. Businesses care about getting stuff done, not whether you like to write your code and you…

Rust is the new "I use Arch btw"

It really is.

Re: Thirteen Years of Go

#60

Post by rob74 »

valenterry wrote: post #36
lordgroff wrote: post #29

Earlier quoted context omitted.

I honestly have no idea why so many hate the language but I guess the Bjarne Stroustrup rule applies. For me it's a language I always wanted to have: essentially C with a GC, small enough you can carry it in your head with most of the footguns removed. I honestly also have no idea why Rust always makes an appearance in a Go thread, I can't think of two languages with such a diametrically opposite learning complexity.

Simply because it's limiting. Which is good if you are inexperienced, but not so great once you grow and try to become more productive. A more expressive language is a must then or you'll be stuck. For some people it's this feeling of being stuck that they don't like - others can live with it more easily. > I honestly also have no idea why Rust always makes an appearance in a Go thread Both Rust and Go people are ver…

> Which is good if you are inexperienced, but not so great once you grow and try to become more productive. A more expressive language is a must then or you'll be stuck.

Ok, I get it that there are developers that can't live with languages that don't have tons of shiny features to play with, but please don't disparage the others as "inexperienced"! If you have ever gone back to some "expressive" code you wrote months/years ago while feeling very productive and were left wondering "WTF was I thinking when I wrote that? Can someone explain it to me?", then you start to understand the reasoning behind Go's simplicity.

Post reply on HN