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

41–50 of 217 posts

Re: Thirteen Years of Go

#41

Post by lordgroff »

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…

I have about 30 years of coding experience, try again. C++ to Python, C to Go. Often I want to get shit done and not marvel at how smart I am.

Re: Thirteen Years of Go

#42

Post by quaffapint »

candiddevmike wrote: post #20
throwawaaarrgh wrote: post #19

Quoted post unavailable.

If you can't learn Go, you're going to have a bad time with Rust.

I do c# in my day job, and so far Rust has been much easier to pick up than Go. Maybe it just happens to be more similar to c#, but given it can be used as a system level lang like c++ I've been very surprised how quick it can be picked up (at least for basic tasks).

Re: Thirteen Years of Go

#43

Post by Xeoncross »

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 instant. Built artifacts are a single binary - not 1,200 files that must be moved. Every single package that has any traction is both easy to read and has documentation inline or via published go.dev docs.

It's easy enough the frontend JS guy can write it. It's complex enough you can use goa.design or go-kit to auto generate openapi specs and complex microservice designs that support multiple transports (like gRPC). Errors always get handled because the linter points them out and the devs don't cheat by setting up multi-function try/catch blocks.

I've had less issues with production Go applications than any other language. I don't want it to win over Rust though, Rust is awesome. I want Go to replace Java.

Re: Thirteen Years of Go

#44

Post by doorman2 »

0x445442 wrote: post #35
doorman2 wrote: post #32

Earlier quoted context omitted.

Go workspaces are amazing. You create a go.work file, add a line with each module you're working on, and then the Go language server handles the rest. Solutions and projects seem way more complicated, but also not entirely congruent. A Go workspace is used when you have two modules that depend on each other and you want to work on both concurrently. The two modules are still independent and could be worked on individ…

By amazing do you mean specifically for Go? Because I don’t see how it differs from working on two Maven projects simultaneously in Java where one depends on the other.

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 you add a file to workspace/go.work, then local versions of mod1 and mod2 can be used without changing either mod1 or mod2.

Re: Thirteen Years of Go

#45

Post by Queue29 »

dartharva wrote: post #40
smithcoin wrote: post #21

Earlier quoted context omitted.

> Lack of docs, broken and confusing functionality, limited language features, bizarre operations. You are painting with a pretty broad brush, can you provide a concrete example of these?

I don't know how applicable this is, but even the basic if-else syntax can hit you with hours of frustrating struggles. The parantheses have to be arranged in a specific way that was never mentioned in the online language specs over at go.dev, otherwise the code will fail: if (cond) { return x } else { return y } works, but if (cond) { return x } else { return y } doesn't.

> never mentioned in the online language specs over at go.dev

hmm, what's this then?

https://go.dev/doc/faq#Does_Go_have_a_ternary_form

Re: Thirteen Years of Go

#47

Post by dartharva »

Queue29 wrote: post #45
dartharva wrote: post #40

Earlier quoted context omitted.

I don't know how applicable this is, but even the basic if-else syntax can hit you with hours of frustrating struggles. The parantheses have to be arranged in a specific way that was never mentioned in the online language specs over at go.dev, otherwise the code will fail: if (cond) { return x } else { return y } works, but if (cond) { return x } else { return y } doesn't.

> never mentioned in the online language specs over at go.dev hmm, what's this then? https://go.dev/doc/faq#Does_Go_have_a_ternary_form

That's the FAQ. The official Language Specification says nothing about this little gimmick, at least in the if-else section: https://go.dev/ref/spec#If_statements

You'd think one would want to look for it in that instead of an FAQ page.

Re: Thirteen Years of Go

#48

Post by metaltyphoon »

doorman2 wrote: post #44
0x445442 wrote: post #35

Earlier quoted context omitted.

By amazing do you mean specifically for Go? Because I don’t see how it differs from working on two Maven projects simultaneously in Java where one depends on the other.

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)

Re: Thirteen Years of Go

#49

Post by _ph_ »

lordgroff wrote: post #41
valenterry wrote: post #36

Earlier quoted context omitted.

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…

I have about 30 years of coding experience, try again. C++ to Python, C to Go. Often I want to get shit done and not marvel at how smart I am.

Seconded. I have been bitten far more often by too fancy abstractions then by not having more fancy abstractions in my tooling. And Go has quite a few fundamental ones, like first class functions and closures.

Re: Thirteen Years of Go

#50

Post by jjice »

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.

Post reply on HN