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

Go's Sweet 16

go.dev

Post reply on HN
Print view View original

81–90 of 280 posts

Re: Go's Sweet 16

#81

Post by Measter »

kermatt wrote: post #36
roncesvalles wrote: post #23

Earlier quoted context omitted.

The nice thing about Go is that you can learn "all of it" in a reasonable amount of time: gotchas, concurrency stuff, everything. There is something very comforting about knowing the entire spec of a language. I'm convinced no more than a handful of humans understand all of C# or C++, and inevitably you'll come across some obscure thing and have to context switch out of reading code to learn whatever the fuck a "part…

> I'm convinced no more than a handful of humans understand all of C# or C++ How would the proportion of humans that understand all of Rust compare?

For Rust vs C++, I'd say it'll be much easier to have a complete understanding of Rust. C++ is an immensely complex language, with a lot of feature interactions.

C# is actually fairly complex. I'm not sure if it's quite at the same level as Rust, but I wouldn't say it's that far behind in difficulty for complete understanding.

Re: Go's Sweet 16

#82

Post by trenchpilgrim »

ashishb wrote: post #31

Contributing to a new Go codebase is easy. The Go codebases look all alike. Not only the language has really few primitives but also the code conventions enforced by standard library, gofmt, and golangci-lint implies that the structure of code bases are very similar. Many language communities can't even agree on the build tooling.

I'm still trying to convince the scientists I work with that they should format their code or use linters. Making them mandatory in Go was a good decision.

Re: Go's Sweet 16

#83

Post by Measter »

throw1111221 wrote: post #54
pkaye wrote: post #52

Earlier quoted context omitted.

Doesn't Google use mostly C++?

Just because it was a design goal doesn't mean it succeeded ;) From Russ Cox this time: "Q. What language do you think Go is trying to displace? ... One of the surprises for me has been the variety of languages that new Go programmers used to use. When we launched, we were trying to explain Go to C++ programmers, but many of the programmers Go has attracted have come from more dynamic languages like Python or Ruby."…

It's interesting that I've also heard the same from people involved in Rust. Expecting more interest from C++ programmers and being surprised by the numbers of Ruby/Python programmers interested.

I wonder if it's that Ruby/Python programmers were interested in using these kinds of languages but were being pushed away by C/C++.

Re: Go's Sweet 16

#84

Post by the_gipsy »

throw1111221 wrote: post #50
Xeoncross wrote: post #3

I know they say that your programming language isn't the bottleneck, but I remember sitting there being frustrated as a young dev that I couldn't parse faster in the languages I was using when I learned about Go. It took a few more years before I actually got around to learning it and I have to say I've never picked up a language so quickly. (Which makes sense, it's got the smallest language spec of any of them) I'm…

Well that's good, since Go was specifically designed for juniors. From Rob Pike himself: "It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical." However, the main design goal was to reduc…

> This is why unused dependencies are a compile time error.

https://go.dev/doc/faq?utm_source=chatgpt.com#unused_variabl...

> There are two reasons for having no warnings. First, if it’s worth complaining about, it’s worth fixing in the code. (Conversely, if it’s not worth fixing, it’s not worth mentioning.) Second, having the compiler generate warnings encourages the implementation to warn about weak cases that can make compilation noisy, masking real errors that should be fixed.

I believe this was a mistake (one that sadly Zig also follows). In practice there are too many things that wouldn't make sense being compiler errors, so you need to run a linter. When you need to comment out or remove some code temporarily, it won't even build, and then you have to remove a chain of unused vars/imports until it let's you, it's just annoying.

Meanwhile, unlinted go programs are full of little bugs, e.g. unchecked errors or bugs in err-var misuse. If there only were warnings...

Re: Go's Sweet 16

#85

Post by allset_ »

pkaye wrote: post #52
throw1111221 wrote: post #50

Earlier quoted context omitted.

Well that's good, since Go was specifically designed for juniors. From Rob Pike himself: "It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical." However, the main design goal was to reduc…

Doesn't Google use mostly C++?

No.

Re: Go's Sweet 16

#86

Post by 9rx »

zer00eyz wrote: post #66
cwbriscoe wrote: post #55

Earlier quoted context omitted.

Error handling isn't even a pain to write any more with AI autocomplete which gets it right 95%+ of the time in my experience.

You're not wrong but... there is a large contingent of the Go community that has a rather strong reaction to AI/ML/LLM generated code at any level. I keep using the analogy, that the tools are just nail guns for office workers but some people remain sticks in the mud.

> there is a large contingent of the Go community that has a rather strong reaction to AI/ML/LLM generated code at any level.

This Go community that you speak of isn't bothered by writing the boilerplate themselves in the first place, though. For everyone else the LLMs provide.

Re: Go's Sweet 16

#87

Post by culebron21 »

To me, Go is like Rust oversimplified beyond reason. It edits your code when you don't ask, removing things you just started; it lacks iterators -- every time you must write a big cycle instead. It lacks simple things like check if a key exists in a map.

Proponents say it has nothing under the hood. I see under-the-hood-magic happen every time.

1) The arrays append is one example. Try removing an element from an array - you must rely on some magic and awkward syntax, and there's no clear explanation what actually happens under the hood (all docs just show you that a slice is a pointer to a piece of vector).

2) enums creation is just nonsense

3) To make matters worse, at work we have a linter that forbids merging a branch if you a) don't do if err != nil for every case b) have >20 for & if/else clauses. This makes you split functions in many pieces, turning your code into enterprise Java.

It feels like, to implement same things, Go is 2x slower than in Rust.

On the positive side,

* interfaces are simpler, without some stricter Rust's limitations; the only problem with them is that in the using code, you can't tell one from a struct

* it's really fast to pick up, I needed just couple of days to see examples and start coding stuff.

I think Go would have been great with

* proper enums (I'll be fine if they have no wrapped data)

* sensible arrays & slices, without any magic and awkward syntax

* iterators

* result unwrapping shorthands

Re: Go's Sweet 16

#88

Post by tapirl »

> Go stands by its compatibility promise—the old way will continue to work in perpetuity ...

It is so weird that they still claim this after they have made the the semantic change for 3-clause for-loop in Go 1.22.

When a Go module is upgraded from 1.21- to 1.22+, there are some potential breaking cases which are hard to detect in time. https://go101.org/blog/2024-03-01-for-loop-semantic-changes-...

Go toolchain 1.22 broke compatibility for sure. Even the core team admit it. https://go101.org/bugs/go-build-directive-not-work.html

Re: Go's Sweet 16

#89

Post by alain_gilbert »

culebron21 wrote: post #87

To me, Go is like Rust oversimplified beyond reason. It edits your code when you don't ask, removing things you just started; it lacks iterators -- every time you must write a big cycle instead. It lacks simple things like check if a key exists in a map. Proponents say it has nothing under the hood. I see under-the-hood-magic happen every time. 1) The arrays append is one example. Try removing an element from an arra…

I worked on a toy programming language (that compile down to golang), which is a fork of the go lexer/parser, but it changes how functions can only return one value allowing the use of Result[T]/Option[T] and error propagation operators `!` and `?`.

It has enums (sum type), tuple, built-in Set[T], and good Iterator methods. It has very nice type inferred lambda function (heavily inspired by the swift syntax)... lots of good stuff!

https://github.com/alaingilbert/agl

Re: Go's Sweet 16

#90

Post by ashishb »

trenchpilgrim wrote: post #82
ashishb wrote: post #31

Contributing to a new Go codebase is easy. The Go codebases look all alike. Not only the language has really few primitives but also the code conventions enforced by standard library, gofmt, and golangci-lint implies that the structure of code bases are very similar. Many language communities can't even agree on the build tooling.

I'm still trying to convince the scientists I work with that they should format their code or use linters. Making them mandatory in Go was a good decision.

> I'm still trying to convince the scientists I work with that they should format their code or use linters.

Consider adding a pre-commit hook if you are allowed to.

Post reply on HN