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

161–170 of 217 posts

Re: Thirteen Years of Go

#161

Post by throwaway894345 »

rahen wrote: post #152
throwaway894345 wrote: post #143

Earlier quoted context omitted.

You don't even need CGo or unsafe to deal without a GC. Go's GC is written in Go and it obviously doesn't depend on a GC! You just need to know which features imply a GC/allocation and you need to take care to avoid those features. Conceivably, you could devise a linter that statically verifies your no-GC requirement.

> You just need to know which features imply a GC/allocation and you need to take care to avoid those features. This is very insightful. Would you mind sharing more resources regarding that? I'd be interested in a list of such features. The GC can also be used manually by setting GOGC=off, then be triggered manually at the most convenient time.

I don't know of any resources, but basically you can intuit pretty easily about how to avoid allocations in Go (don't allocate or grow slices, don't use maps, avoid returning references to anything you allocate inside of your function call, etc), and there are flags you can pass to the compiler to log allocation points. If you don't allocate, then there's nothing to collect, and you can even turn off the GC altogether.

Re: Thirteen Years of Go

#162

Post by TrustPatches »

5e92cb50239222b wrote: post #126
TrustPatches wrote: post #113

Earlier quoted context omitted.

Not sure if it’s an exact parallel, but you can also embed files into rust binaries with “include_bytes!” and “include_str!”.

It's a bit more advanced than what Rust macros provided last time I checked. You can shove whole directories in there and then traverse them or serve as static resources with pretty much one line of code. Random blog post with a few examples: https://blog.carlmjohnson.net/post/2021/how-to-use-go-embed/

Very cool, I guess one the the advantages of rust macros is that you could write your own to do something more advanced in theory

Re: Thirteen Years of Go

#163

Post by tptacek »

masklinn wrote: post #155
tptacek wrote: post #51

Earlier quoted context omitted.

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 G…

> 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. Are you saying that you’ve had 5 bugs caused by unnecessary imports ?

I'm saying I've had that stupid import error pop up in my face 5 times and changed my code as a result, rather than the imports, because it surfaced an error.

Re: Thirteen Years of Go

#164

Post by super_flanker »

5e92cb50239222b wrote: post #126
TrustPatches wrote: post #113

Earlier quoted context omitted.

Not sure if it’s an exact parallel, but you can also embed files into rust binaries with “include_bytes!” and “include_str!”.

It's a bit more advanced than what Rust macros provided last time I checked. You can shove whole directories in there and then traverse them or serve as static resources with pretty much one line of code. Random blog post with a few examples: https://blog.carlmjohnson.net/post/2021/how-to-use-go-embed/

You can do the same in Rust with include_dir[1]

1: https://docs.rs/include_dir/latest/include_dir/

Re: Thirteen Years of Go

#165

Post by valzam »

eweise wrote: post #156
doorman2 wrote: post #141

Earlier quoted context omitted.

Personally, I hate writing Go. It's a very dull and boring language, but it's an amazing language (objectively speaking) for software development. 1) It's performant. The language itself is very fast, the GC is very fast and go routines make concurrency fast. 2) The tooling is great. Once you have the Go CLI installed, everything else "just works." Cross-compilation is super easy. Install dependencies is easy. Genera…

Not sure generics are amazing. I wish I could do something like addresses := persons.map(func(p Person) Address {p.address}) Actually what I really want is addresses := persons.map(p => p.address) But I understand Go doesn't allow that level of readability.

As someone who wrote scala and elixir for a few years and recently switched to a Go job I also dearly missed map and filter. However, people tend to loop unnecessarily often when it's so easy.

Say you have a list of classes and want to pull out certain fields. With immutability as default and easy map functions many people write something like this:

a = my list.map(e => e.foo)

b = mylist.map(e => e.bar)

This may or may not matter performance wise but I think Go has a strong culture of of making something like this easy vs writing a for loop that does everything in one go.

Re: Thirteen Years of Go

#166

Post by another_devy »

playingalong wrote: post #160

Anyone else feeling put off by golang? The syntax, the crazy error handling, etc. To me it's like taking a step back in programming, or actually 20 years back. Not better than Java (which is annoyingly verbose), maybe better than Pascal.

Java is in middle or to the end of userspace, it is verbose and less opinionated. Golang is very close to systems programming hence very opinionated, you can easily build API applications with it but that’s the most non system engineering you can get out of it. The error handling is probably the best design I feel from language that’s in category of c, c++

Re: Thirteen Years of Go

#167

Post by avgcorrection »

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…

> I don't want it to win over Rust though, Rust is awesome.

Why even perpetuate this red herring comparison—maybe over a decade old?—by making unprompted mentions of Rust though.

Re: Thirteen Years of Go

#168

Post by wting »

playingalong wrote: post #160

Anyone else feeling put off by golang? The syntax, the crazy error handling, etc. To me it's like taking a step back in programming, or actually 20 years back. Not better than Java (which is annoyingly verbose), maybe better than Pascal.

Yes, but in the end it's because people who like Go because they prioritize a certain set of features (language, community, ecosystem, etc), and those who prefer non-Go languages prioritize other features.

I don't like Go personally, but I have advocated for Go to be used in many situations depending on context. It's unproductive to start a language war here since it's generally situation-dependent.

Re: Thirteen Years of Go

#169

Post by erik_seaberg »

throwawaygal7 wrote: post #157
origin_path wrote: post #122

Earlier quoted context omitted.

"Errors always get handled because the linter points them out and the devs don't cheat by setting up multi-function try/catch blocks" My experience with Go has been that errors get "handled" by propagating them up the stack manually and then logging them, without keeping proper track of how the error got there. So there is error handling but only in theory, in practice what you get is a sort of hand-written stack unw…

In go, you either handle the error where it happens or close to it, or log it. No need to pass things up just to log. I like the simplicity, and the zero cost at runtime. If you could handle the error in another lang you could handle it in go, or youd just supress or log it anyway.

In a microservice, almost all errors are handled by doing nothing and returning the error to the caller. Retrying may be an option, but you have to be careful not to make your system into a cascading failure amplifier.

Re: Thirteen Years of Go

#170

Post by scruple »

TrustPatches wrote: post #113
KingOfCoders wrote: post #88

Earlier quoted context omitted.

I currently write a SaaS website in Go after doing quite some Rust. I do prefer Rust as a language - it's more expresive and I greatly prefer Result over error, but it has two major downsides for me compared to Go. First compilation is much slower and Go feels like a non-compiled language because of the compilation speed (my last startup I've used Scala with horrendous compilation speeds, the main reason not to use i…

Not sure if it’s an exact parallel, but you can also embed files into rust binaries with “include_bytes!” and “include_str!”.

I've gone as far as embedding a ReactJS app inside of Go's embedFS. It's pretty damn powerful.
Post reply on HN