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

201–210 of 217 posts

Re: Thirteen Years of Go

#201

Post by rob74 »

valenterry wrote: post #194
mahogany wrote: post #189

Earlier quoted context omitted.

But you said: > 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. which implies that people who use Go have not grown and become as productive as people that use more expressive languages (because such languages are a "must" to grow in this way). At the very least, you are obviously disparaging Go pro…

> which implies that people who use Go have not grown and become as productive That's not what it says, or at least not what I meant. People are different and can accept a different amounts of repetitive work. Heck, there are even people who really like it and want to think as little as possible. So all I'm saying is that there exist people in Go that grow and then want to improve their productivity but are now restr…

So there are two categories of Go programmers in your opinion: (1) the beginners, who will eventually feel its limitations and will advance to a better language; and (2), those who don't mind repetitive work and want to think as little as possible, those will happily use Go until retirement. Still not really flattering, is it?

Re: Thirteen Years of Go

#202

Post by lakomen »

pipeline_peak wrote: post #71

Why exactly is Go so special? For a compiled language it's not very fast and doesn't seem to be making much traction. I think people simply like it because of it's Bell Labs heritage and pretty syntax.

It's a language with a dynamic feel, that isn't dynamic. It's 2 times faster than Java on average with half the resource usage in average.

Re: Thirteen Years of Go

#204

Post by metaltyphoon »

doorman2 wrote: post #55
metaltyphoon wrote: post #48

Earlier quoted context omitted.

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

Yeah the VS sln file is outdated and meant only to be used by the IDE. There are talks about revamping it, like the C# csproj had.

I wasn’t aware about “not checking in go.work”. What if you want separate modules to be aware of each other but keep them in the same repo?

Re: Thirteen Years of Go

#205

Post by Gwypaas »

ColonelPhantom wrote: post #193
tptacek wrote: post #191

Earlier quoted context omitted.

I'm not saying it caught syntax errors. I'm saying it caught actual bugs in my code. I don't want to be allowed to blow those off.

>I'm saying it caught actual bugs in my code. It did so 5 times, versus how many times it gave a false positive where you just had to delete the import or underscore the variable? Warnings are intended precisely for this type of "hey, you probably made a mistake here". Errors should imo be reserved for cases where the compiler is more or less sure you are wrong. Rust has probably the biggest possible focus on "making…

Together with that any reasonable codebase denies any warnings from the compiler, Clippy or changes from running Rustfmt when running CI. Which is pretty much equal to Go best practice, using something like Golangci-lint instead.

Although, I guess this is the difference between being 13 years old and 7. For Rust easily accessible CI has always existed, for Go at the time of launch it took effort setting it up. Therefore best practices were pushed into the compiler to the detriment of the users, giving the same benefit trading effort writing the code.

Re: Thirteen Years of Go

#206

Post by playingalong »

another_devy wrote: post #166
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++

Golang tend to be used for application programming these days. Not only system works. Including today's top page article.

Re: Thirteen Years of Go

#207

Post by valenterry »

rob74 wrote: post #201
valenterry wrote: post #194

Earlier quoted context omitted.

> which implies that people who use Go have not grown and become as productive That's not what it says, or at least not what I meant. People are different and can accept a different amounts of repetitive work. Heck, there are even people who really like it and want to think as little as possible. So all I'm saying is that there exist people in Go that grow and then want to improve their productivity but are now restr…

So there are two categories of Go programmers in your opinion: (1) the beginners, who will eventually feel its limitations and will advance to a better language; and (2), those who don't mind repetitive work and want to think as little as possible, those will happily use Go until retirement. Still not really flattering, is it?

Common! My example of people who don't want to think at all was clearly not in the context of developers. I'm talking about factory workers or sometimes even office workers.

For golang there's certainly devs how just don't mind a certain amount of repetitive work and are happy to use Go until retirement. And I don't think that's a problem at all. People are different and I think we should embrace that. If you think being called a "factory worker" is not flattering, then that's more your personal judgement than me being objectively disregarding factory workers.

Again: Try to read my response in the right context. I'm explaining why some people dislike (or even hate) the language. It was a response. Please try to keep that in mind when you reply.

Re: Thirteen Years of Go

#208

Post by surajrmal »

KingOfCoders wrote: post #88
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 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…

You can avoid Arc in rust the same way you avoid mutexes in go - use channels instead. I find programming rust with channels between tasks feels quite ergonomic. Also, at least to me, it seems like it's a no brainier to pick a language with a GC if your target runtime environment allows for it.

Re: Thirteen Years of Go

#209

Post by cschep »

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.

I think gofmt will fix this for you?

Re: Thirteen Years of Go

#210

Post by Casperin »

surajrmal wrote: post #208
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…

You can avoid Arc in rust the same way you avoid mutexes in go - use channels instead. I find programming rust with channels between tasks feels quite ergonomic. Also, at least to me, it seems like it's a no brainier to pick a language with a GC if your target runtime environment allows for it.

Mine does. Still picked Rust, and so happy I did. The type system alone does it for me.
Post reply on HN