12 ms·

Go's Sweet 16

317 points by 0xedb 11mo ago

tschellenbach 11mo ago
10 week onboarding program we use here for go backend devs: https://www.reddit.com/r/golang/comments/1eiea6q/10_week_plan_to_master_go_getstreams_onboarding/ https://www.reddit.com/r/golang/comments/1eiea6q/10_week_pla... go is amazing. switches from python to go 7 years ago. It's the reason our startup did well
- thunderbong 11mo ago
  Direct link https://stream-wiki.notion.site/Stream-Go-10-Week-Backend-Eng-Onboarding-625363c8c3684753b7f2b7d829bcd67a https://stream-wiki.notion.site/Stream-Go-10-Week-Backend-En...
- zerr 11mo ago
  One thing I don't like when it comes to Golang jobs - it is rare to see pure software engineering positions. For some reason, most Go jobs requirements include AWS, Kubernetes/Docker, CI/CD setup, etc... DevOps stuff, which is not the case for positions in other stacks.
  - millerm 11mo ago
    I haven't been able to find a job anywhere, using any language, that didn't require all that stuff these days. I wish I could go back to pure development, but now we all get this entire infra-crap thrown at us too. Which then means... you support the environments, the runtime, and the code. It's a 24/7 world and I don't care for it anymore.
    - arccy 11mo ago
      it's alignment of incentives. nowadays devs are less inclined to pump out crappy code that ends up with some ops guy having to wake up in the middle of the night
Xeoncross 11mo ago
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 sure there are plenty of reasons this is wrong, but it feels like Go gets me 80% of the way to Rust with 20% of the effort.
- tialaramex 11mo ago
  > I'm sure there are plenty of reasons this is wrong, but it feels like Go gets me 80% of the way to Rust with 20% of the effort. I don't see it. Can you say what 80% you feel like you're getting? The type system doesn't feel anything alike, I guess the syntax is alike in the sense that Go is a semi-colon language and Rust though actually basically an ML deliberately dresses as a semi-colon language but otherwise not really. They're both relatively modern, so you get decent tooling out of the box. But this feels a bit like if somebody told me that this new pizza restaurant does a cheese pizza that's 80% similar to the Duck Ho Fun from that little place near the extremely tacky student bar. Duck Ho Fun doesn't have nothing in common with cheese pizza, they're both best (in my opinion) if cooked very quickly with high heat - but there's not a lot of commonality.
  - klodolph 11mo ago
    > I don't see it. Can you say what 80% you feel like you're getting? I read it as “80% of the way to Rust levels of reliability and performance.” That doesn’t mean that the type system or syntax is at all similar, but that you get some of the same benefits. I might say that, “C gets you 80% of the way to assembly with 20% of the effort.” From context, you could make a reasonable guess that I’m talking about performance.
    - Xeoncross 11mo ago
      Yes, for me I've always pushed the limits of what kinds of memory and cpu usage I can get out of languages. NLP, text conversion, video encoding, image rendering, etc... Rust beats Go in performance.. but nothing like how far behind Java, C#, or scripting languages (python, ruby, typescript, etc..) are from all the work I've done with them. I get most of the performance of Rust with very little effort a fully contained stdlib/test suite/package manger/formatter/etc.. with Go.
weakfish 11mo ago
I like Go. Coming from Python, I appreciate having most things be explicit in nature vs. magical, and having concurrency not feel like a bolted on nightmare. Writing microservices at $DAYJOB feels far easier and less guess-work, even if it requires more upfront code, because it’s clear what each piece does and why.
- _ea1k 11mo ago
  I've finally gotten around to learning Go this year and I'm having a pretty similar experience. It really feels like a simpler language and ecosystem compared to Python. On top of that, it performs much better!
jryio 11mo ago
Glad to see that the bowling development team is focusing on deterministic tooling like language server protocol in gopls and using static analysis for automatically restoring code with go fix. Recently I made the same assertions as to Go's advantage for LLM/AI orchestration. https://news.ycombinator.com/item?id=45895897 https://news.ycombinator.com/item?id=45895897 It would not surprise me that Google (being the massive services company that it is) would have sent an internal memo instructing teams not to use the Python tool chain to produce production agents or tooling and use Golang.
- somekyle2 11mo ago
  Even 15 years ago or so when Guido was still there I recall being told "we aren't supposed to write any new services in Python. It starts easy, then things get messy and end up needing to be rewritten." I recall it mostly being perf and tooling support, but also lack of typing, which has changed since then, so maybe they've gotten more accepting.
MichaelNolan 11mo ago
Go would probably be my favorite language if it just had a few more features around functional programming. Specifically around immutability and nullness, and maybe exhaustive switch statements. Then it just might be perfect. At work we use Uber’s NillAway, so that helps bit. https://github.com/uber-go/nilaway https://github.com/uber-go/nilaway Though actually having the type system handle it would be nicer.
- kellpossible2 11mo ago
  Go with Sum types and no nil pointers would be fantastic! Is it too much to dream of? It feels like Gleam gets pretty close but it flies off in a bunch of other directions.
  - HL33tibCe7 11mo ago
    vlang is pretty much this
- qouteall 11mo ago
  There is borgo https://github.com/borgo-lang/borgo https://github.com/borgo-lang/borgo but it's not yet mature and not being actively developed
tail_exchange 11mo ago
I was very skeptical of Go when I started learning it, but it quickly became my favourite language. I like how simple but powerful it is. If I had a magic wand, the only things I would add is better nulability checks, add stack traces by default for errors, and exhaustive checks for sum types. Other than that, it does everything I want.
- deleted 11mo ago
  [deleted]
- thegeekpirate 11mo ago
  > exhaustive checks for sum types Linters such as https://golangci-lint.run https://golangci-lint.run will do this for you.
- trenchpilgrim 11mo ago
  > better nulability checks In development: https://github.com/uber-go/nilaway https://github.com/uber-go/nilaway
srameshc 11mo ago
Go is my favorite programming language. I remember when I first found Go and it was because I was using Java back then and learnign Akka framework for concurrent programming . I realized Go was so much less code compared to Java and I could understand it effortlessly. Since then I have been using it very regularly but still I don't feel I am good at this language. But it helps me get the work done. Cheers to the 16th anniversary of Go.
sedatk 11mo ago
I remember when Go was born, then, it turned out there was already another programming language called "Go!", but nobody cared, and everybody forgot about that other Go!. So, happy birthday, Go, and rest in peace, Go! https://en.wikipedia.org/wiki/Go!_(programming_language)#Conflict_with_Google https://en.wikipedia.org/wiki/Go!_(programming_language)#Con...
p2detar 11mo ago
I recently finished my first ever side gig in Go - a web platform that organizes business processes between multiple actors. Got paid and more feature requests are coming in. Fronted with Caddy, the whole thing runs flawlessly on a $5 VPS. I love Go.
ashishb 11mo ago
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.
- stOneskull 11mo ago
  i've just started learning Go and i really like this aspect. one way to do things, one way to format.. the % operator is a bit confusing for a negative number - that took me down a little rabbit-hole, learning about how a remainder can be different to how i normally think about it.
- trenchpilgrim 11mo ago
  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.
  - ashishb 11mo ago
    > 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.
    - trenchpilgrim 11mo ago
      My group's repos enforce strict rules, theirs does not.
      - millerm 11mo ago
        Yeah, I've been there. I would get passed down horribly formatted code from another repo and it showed the data scientists writing it barely knew what they were doing. It was their repo, we couldn't do anything about it. They wouldn't reformat the code, because they were afraid it would break. They also passed us a lot of Python, and you can see where they got this fear from.
threemux 11mo ago
I use Go every day at work and it's still the first thing I reach for when completing personal projects. It gets better every year. Keep up the good work Go team!
bobjordan 11mo ago
I tried to use go in a project 6-7 years ago and was kind of shocked by needing to fetch packages directly from source control with a real absence of built in versioning. That turned me off and I went back to python. I gather that now there’s a new system with go modules. I should probably revisit it.
kasperset 11mo ago
I am not really familiar with Go but I wonder where it would be without Google's support and maintenance. I have no doubt it is a solid language with some really smart people in programming language design behind it. It is so much easy to release programming language but so much difficult to maintain and curate it over time.
rishabhaiover 11mo ago
Love Go! It gently introduced me to the systems programming world.
nicodjimenez 11mo ago
Golang to me is a great runtime and very poor language. I could maybe get used to the C pointer-like syntax and to half of my code checking if err != nil, but the lack of classes is a step too far. The Golang idiomatic approach is to have a sprawling set of microservices talking to each other over the network, to manage complexity instead of having classes. This makes sense for things like systems agents (eg K8) but doesn't make sense for most applications because it complicates the development experience unnecessarily and monoliths are also easier to debug. I would not use Golang for a big codebase with lots of business logic. Golang has not made a dent in Java usage at big companies, no large company is going to try replacing their Java codebases with Golang because there's no benefit, Java is almost as fast as Golang and has classes and actually has a richer set of concurrency primitives.
- wanderlust123 11mo ago
  I think lack of classes is highly desirable. So much enterprise code is poorly put together abstractions. I think go needs some more functional aspects, like iterators and result type/pattern matching.
  - robryan 11mo ago
    Go does have iterators: https://pkg.go.dev/iter https://pkg.go.dev/iter
    - wanderlust123 11mo ago
      Thanks! Did not see this until your message, looking forward to make use of this
  - nicodjimenez 11mo ago
    The solution to bad abstractions it not to make it very difficult to create abstractions at all. For systems code I think it's fine but for application code you probably want some abstractions or else it's very hard to scale a codebase.
ModernMech 11mo ago
Oh wow, so it's already been 16 years since Google steamrolled the Go! language, which had existed a decade before Go and had every right to the name. This was when they were still pretending "do no evil" was their brand. There may be no honor amongst thieves but there is honor amongst langdevs, and when they did Go! dirty, Google made clear which one they are. Status changed to Unfortunate https://github.com/golang/go/issues/9#issuecomment-66047478 https://github.com/golang/go/issues/9#issuecomment-66047478
- MagicMoonlight 11mo ago
  Does anyone use that other language? No!
  - ModernMech 11mo ago
    That's not the point, no one uses 99% of languages, so if that's the standard then it's a free-for-all. The PL community is small, so norms are important. PL naming code is: 1. Whoever uses the name first, has claim to the name. Using the name first is measured by: when was the spec published, or when is the first repo commit. 2. A name can be reused IFF the author has abandoned the original project. Usually there's a grace period depending on how long the project was under development. But if a project is abandoned then there's nothing to stop someone from picking up the name. 3. Under no circumstances should a PL dev step on the name of a currently active PL project. If that happens, it's up to the most recently named project to change their name, not the older project even if the newer project has money behind it. 4. Language names with historical notoriety are essentially "retired" despite not being actively developed anymore. All of this is reasonable, because the PL namespace is still largely unsaturated*. There are plenty of one syllable English words that are out there for grabs. All sorts of animals, verbs, nouns, and human names that are common for PLs are there for the taking. There's no reason to step on someone else's work just because there's some tie in with your company's branding. So it's pretty bottom basement behavior for luminaries like Ken Thompson and Rob Pike to cosign Google throwing around their weight to step on another dev's work, and then say essentially "make me" when asked to stop. * This of course does not apply to the single-letter langs, but even still, that namespace doesn't really have 25 langs under active development.
zmj 11mo ago
I'm glad Go exists. If nothing else, it cemented that tooling is at least as important as the language.
MagicMoonlight 11mo ago
I just can’t get over the idiotic syntax. Instead of “int x” You have “var x int” Which obscures the type, making it harder to read the code. The only justification is that 16 years ago, some guy thought he was being clever. For 99.99% of code, it’s a worse syntax. Nobody does eight levels of pointer redirection in typical everyday code.
- LexiMax 11mo ago
  16 years is a bit of an under-estimate. I think the first popular language with this form of declaration was Pascal. var foo: char; Go was developed by many of the minds behind C, and inertia would have led them to C-style declaration. I don't know if they've ever told anybody why they went with the Pascal style, but I would bet money on the fact that Pascal-style declarations are simply easier and faster for computers to parse. And it doesn't just help with compile speed, it also makes syntax highlighting far more reliable and speeds up tooling. Sure, it's initially kind of annoying if you're used to the C style of type before identifier, but it's something you can quickly get to grips with. And as time has gone on, it seems like a style that a lot of modern languages have adopted. Off the top of my head, I think this style is in TypeScript, Python type hints, Go, Rust, Nim, Zig, and Odin. I asked Claude for a few more examples and apparently it's also used by Kotlin, Swift, and various flavors of ML and Haskell. But hey, if you're still a fan of type before variable, PHP has your back. class User { public int $id; public ?string $name; public function __construct(int $id, ?string $name) { $this->id = $id; $this->name = $name; } }
  - mxey 11mo ago
    > don't know if they've ever told anybody why they went with the Pascal style I don’t know if this is the reason but Robert Griesemer, one of the three original guys, comes from a Pascal/Modula background.
  - anal_reactor 11mo ago
    Golang exists in this weird place where it's similar enough to C so that intuition connects it with C, but at the same time different enough that you keep tripping over.
captainkrtek 11mo ago
Been happily working in Go since 2014. My career has spanned C, Python, C#, Ruby, and a smattering of other languages, but am always quite fond and preferential towards Go.
Pbhaskal 11mo ago
It has been my go to language since 2020. I was given a task to complete in a week and my lead told just go through Go playground and write the code (it was some snmp receiver/transmit stuff). To my surprise it was so easy to learn, write and more importantly test. Only recent thing i have not learned is generics, hopefully will get their sooner. Coming from java background the things Go did felt so clever and just too good to believe
adamddev1 11mo ago
I'm thankful for Go because it was an easy first introduction to static typing. I remember making a little web app and seeing the type errors pop up magically in all he right places where I missed things in my structs. It was a life-changing experience.
culebron21 11mo ago
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
- alain_gilbert 11mo ago
  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 https://github.com/alaingilbert/agl
- 9rx 11mo ago
  > proper enums It has proper enums. Granted, it lacks an enum keyword, which seems to trip up many. Perhaps what you are actually looking for is sum types? Given that you mentioned Rust, which weirdly[1] uses the enum keyword for sum types, this seems likely. Go does indeed lack that. Sum types are not enums, though. > sensible arrays & slices, without any magic and awkward syntax Its arrays and slices are exactly the same as how you would find it in C. So it is true that confuses many coming from languages that wrap them in incredible amounts of magic, but the issue you point to here is actually a lack of magic. Any improvements to help those who are accustomed to magic would require adding magic, not taking it away. > iterators Is there something about them that you find lacking? They don't seem really any different than iterators in other languages that I can see, although I'll grant you that the anonymous function pattern is a bit unconventional. It is fine, though. > result unwrapping shorthands Go wants to add this, and has been trying to for years, but nobody has explained how to do it sensibly. There are all kinds of surface solutions that get 50% of the way there, but nobody wants to tackle the other 50%. You can't force someone to roll up their sleeves, I guess. [1] Rust uses enums to generate the sum type tag as an implementation detail, so its not quite as weird as it originally seems, but still rather strange that it would name it based on an effectively hidden implementation detail instead of naming it by what the user is actually trying to accomplish. Most likely it started with proper enums and then realized that sum types would be better instead and never thought to change the keyword to go along with that change. But then again Swift did the same thing, so who knows? To be fair, its "enums" can degrade to proper enums in order to be compatible with Objective-C, so while not a very good reason, at least you can maybe find some kind of understanding in their thinking in that case. Rust, though...
tapirl 11mo ago
> 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-in-go-1.22.html 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 https://go101.org/bugs/go-build-directive-not-work.html
- gf000 11mo ago
  It's especially funny considering that this issue has been known from lisps for 50+ years..
  - tapirl 11mo ago
    They can fix the issue by just changing the semantics of "for-range" loops, almost no negative effects. But they also applied the change to 3-clause-for loops, which causes many problems, some of which have been pointed out before the change was made. So the rookie mistake is totally caused by arrogance.
- 0x696C6961 11mo ago
  The new toolchain continues to compile old code using the old semantics. Only modules which specify Go 1.22 in go.mod have the new bahivour.
  - tapirl 11mo ago
    The problem is, when you modified the go version in go.mod, the behaviors of some code change, but the change is not easy to detect in time. Go team never plan to develop a tool to identify/detect code affected by such breaking changes, leaving developers without guarantees for safe migration. And when running go scripts without go.mod files, the v1.22 toolchain doesn't respect the "//go:build go1.xx" directives: https://go101.org/bugs/go-build-directive-not-work.html https://go101.org/bugs/go-build-directive-not-work.html And consider that some people run go scripts even without the "//go:build go1.xx" directives ... (Please don't refute me. The Go toolchain allows this and never warns on this.)
pjmlp 11mo ago
And still so many programming language design history lessons to learn from. Maybe by 18, or 21, the maturity finally settles in.
rollulus 11mo ago
I love Go. It makes that I get shit done. I picked up Go more than ten years ago, because it was HN’s darling and when I didn’t know about hype cycles. No regrets.
tmoertel 11mo ago
The introduction of automatic code modernizers to keep legacy code up to date with modern Go idioms is interesting: > With gopls v0.18.0, we began exploring automatic code modernizers. As Go evolves, every release brings new capabilities and new idioms; new and better ways to do things that Go programmers have been finding other ways to do. Go stands by its compatibility promise—the old way will continue to work in perpetuity—but nevertheless this creates a bifurcation between old idioms and new idioms. Modernizers are static analysis tools that recognize old idioms and suggest faster, more readable, more secure, more modern replacements, and do so with push-button reliability. What gofmt did for stylistic consistency, we hope modernizers can do for idiomatic consistency. Modernizers seem like a way make Large-Scale Changes (LSCs) more available to the masses. Google has internal tooling to support them [1], but now Go users get a limited form of opt-in LSC support whenever modernizers make a suggestion. [1] https://abseil.io/resources/swe-book/html/ch22.html https://abseil.io/resources/swe-book/html/ch22.html
liampulles 11mo ago
I love Go. One thing I haven't seen noted here is how great it is for use in monorepos. Adding a new application is just a matter of making a folder and putting a main packaged go file with a main() func. Running go install at the root ./.. takes care of compiling everything quickly and easily. This combined with the ease of building CLI programs has been an absolute godsend in the past when I've had to quickly spin up CLI tools which use business logic code to fix things.
- linhns 11mo ago
  Agreed. This use case is not mentioned enough.
- liveoneggs 11mo ago
  I don't understand how this isn't also true for practically every other language?
  - vlovich123 11mo ago
    It’s not true of C/C++ which need changes to the build system. Also true for rust workspaces which is how I’d recommend structuring monorepos although it is generally easy (you just need to add a small cargo.toml file) or you can not use a workspace but you still need to declare the binary if I recall correctly.
    - o11c 11mo ago
      It's true for any C/C++ project which bothers to write 10 lines of GNU `make` code. The problem is that many projects still pander to inferior 1980s-era `make` implementations, and as such rely heavily on the abominations that are autotools and cmake.
      - duskwuff 11mo ago
        C/C++ library dependencies are a thing, and there's no universal solution to acquiring and installing them.
Zardoz84 11mo ago
I tough that would be about SWEET16
insurancesucks 11mo ago
Every Go thread on this site is the same. "Man I love Go, it's so simple, plenty fast, really easy to pick up, read, and write. I really love that it doesn't have dozens of esoteric features for my colleagues to big brain into the codebase" "Oh yeah? Well Go sucks, it doesn't have dozens of esoteric features for me to big brain into the codebase" Repeat
- dlock17 11mo ago
  Yep, and I personally feel like it's been the biggest stealth marketing of Go through the years.
disintegrator 11mo ago
When you turn on exhaustive, exhaustruct and wrapcheck linters in golangci-lint. You get such a massive safety boost and it makes you fly through writing Go.
mikewarot 11mo ago
And here I was anticipating a release of Go for the Apple ][ computer[16] [16] https://en.wikipedia.org/wiki/SWEET16 https://en.wikipedia.org/wiki/SWEET16
- duskwuff 11mo ago
  It might be possible. TinyGo exists, and can target some devices with even less memory than the Apple II, like the ATmega328 microcontroller.
submeta 11mo ago
Been writing Python code for over twenty years, and using it for personal and work projects, not mainly, but to suppport my work. Recently I ported some of my code to Go and was blown away: Cross compiler, creating binaries, concurrency done right, super fast code. I come very late to the party, and writing software is not my main job, but Go is such a nice complement for my toolbelt. Python for prototyping or writing small services with fastapi, go for network realted stuff, serving lots of users. Super happy with this. And I am wondering if Rust would be a good addition. Or rather go with Typescript to complement Python and Go.
iainctduncan 11mo ago
Curious if anyone has real-world stories/data around Green Tea's pause times....

317 points by 0xedb 11mo ago

10 week onboarding program we use here for go backend devs: https://www.reddit.com/r/golang/comments/1eiea6q/10_week_plan_to_master_go_getstreams_onboarding/ https://www.reddit.com/r/golang/comments/1eiea6q/10_week_pla... go is amazing. switches from python to go 7 years ago. It's the reason our startup did well

thunderbong 11mo ago
Direct link https://stream-wiki.notion.site/Stream-Go-10-Week-Backend-Eng-Onboarding-625363c8c3684753b7f2b7d829bcd67a https://stream-wiki.notion.site/Stream-Go-10-Week-Backend-En...
zerr 11mo ago
One thing I don't like when it comes to Golang jobs - it is rare to see pure software engineering positions. For some reason, most Go jobs requirements include AWS, Kubernetes/Docker, CI/CD setup, etc... DevOps stuff, which is not the case for positions in other stacks.
- millerm 11mo ago
  I haven't been able to find a job anywhere, using any language, that didn't require all that stuff these days. I wish I could go back to pure development, but now we all get this entire infra-crap thrown at us too. Which then means... you support the environments, the runtime, and the code. It's a 24/7 world and I don't care for it anymore.
  - arccy 11mo ago
    it's alignment of incentives. nowadays devs are less inclined to pump out crappy code that ends up with some ops guy having to wake up in the middle of the night

Xeoncross 11mo ago

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 sure there are plenty of reasons this is wrong, but it feels like Go gets me 80% of the way to Rust with 20% of the effort.

tialaramex 11mo ago
> I'm sure there are plenty of reasons this is wrong, but it feels like Go gets me 80% of the way to Rust with 20% of the effort. I don't see it. Can you say what 80% you feel like you're getting? The type system doesn't feel anything alike, I guess the syntax is alike in the sense that Go is a semi-colon language and Rust though actually basically an ML deliberately dresses as a semi-colon language but otherwise not really. They're both relatively modern, so you get decent tooling out of the box. But this feels a bit like if somebody told me that this new pizza restaurant does a cheese pizza that's 80% similar to the Duck Ho Fun from that little place near the extremely tacky student bar. Duck Ho Fun doesn't have nothing in common with cheese pizza, they're both best (in my opinion) if cooked very quickly with high heat - but there's not a lot of commonality.
- klodolph 11mo ago
  > I don't see it. Can you say what 80% you feel like you're getting? I read it as “80% of the way to Rust levels of reliability and performance.” That doesn’t mean that the type system or syntax is at all similar, but that you get some of the same benefits. I might say that, “C gets you 80% of the way to assembly with 20% of the effort.” From context, you could make a reasonable guess that I’m talking about performance.
  - Xeoncross 11mo ago
    Yes, for me I've always pushed the limits of what kinds of memory and cpu usage I can get out of languages. NLP, text conversion, video encoding, image rendering, etc... Rust beats Go in performance.. but nothing like how far behind Java, C#, or scripting languages (python, ruby, typescript, etc..) are from all the work I've done with them. I get most of the performance of Rust with very little effort a fully contained stdlib/test suite/package manger/formatter/etc.. with Go.

weakfish 11mo ago

I like Go. Coming from Python, I appreciate having most things be explicit in nature vs. magical, and having concurrency not feel like a bolted on nightmare. Writing microservices at $DAYJOB feels far easier and less guess-work, even if it requires more upfront code, because it’s clear what each piece does and why.

_ea1k 11mo ago
I've finally gotten around to learning Go this year and I'm having a pretty similar experience. It really feels like a simpler language and ecosystem compared to Python. On top of that, it performs much better!

jryio 11mo ago

Glad to see that the bowling development team is focusing on deterministic tooling like language server protocol in gopls and using static analysis for automatically restoring code with go fix. Recently I made the same assertions as to Go's advantage for LLM/AI orchestration. https://news.ycombinator.com/item?id=45895897 https://news.ycombinator.com/item?id=45895897 It would not surprise me that Google (being the massive services company that it is) would have sent an internal memo instructing teams not to use the Python tool chain to produce production agents or tooling and use Golang.

somekyle2 11mo ago
Even 15 years ago or so when Guido was still there I recall being told "we aren't supposed to write any new services in Python. It starts easy, then things get messy and end up needing to be rewritten." I recall it mostly being perf and tooling support, but also lack of typing, which has changed since then, so maybe they've gotten more accepting.

MichaelNolan 11mo ago

Go would probably be my favorite language if it just had a few more features around functional programming. Specifically around immutability and nullness, and maybe exhaustive switch statements. Then it just might be perfect. At work we use Uber’s NillAway, so that helps bit. https://github.com/uber-go/nilaway https://github.com/uber-go/nilaway Though actually having the type system handle it would be nicer.

kellpossible2 11mo ago
Go with Sum types and no nil pointers would be fantastic! Is it too much to dream of? It feels like Gleam gets pretty close but it flies off in a bunch of other directions.
- HL33tibCe7 11mo ago
  vlang is pretty much this
qouteall 11mo ago
There is borgo https://github.com/borgo-lang/borgo https://github.com/borgo-lang/borgo but it's not yet mature and not being actively developed

tail_exchange 11mo ago

I was very skeptical of Go when I started learning it, but it quickly became my favourite language. I like how simple but powerful it is. If I had a magic wand, the only things I would add is better nulability checks, add stack traces by default for errors, and exhaustive checks for sum types. Other than that, it does everything I want.

deleted 11mo ago
[deleted]
thegeekpirate 11mo ago
> exhaustive checks for sum types Linters such as https://golangci-lint.run https://golangci-lint.run will do this for you.
trenchpilgrim 11mo ago
> better nulability checks In development: https://github.com/uber-go/nilaway https://github.com/uber-go/nilaway

srameshc 11mo ago

Go is my favorite programming language. I remember when I first found Go and it was because I was using Java back then and learnign Akka framework for concurrent programming . I realized Go was so much less code compared to Java and I could understand it effortlessly. Since then I have been using it very regularly but still I don't feel I am good at this language. But it helps me get the work done. Cheers to the 16th anniversary of Go.

sedatk 11mo ago

I remember when Go was born, then, it turned out there was already another programming language called "Go!", but nobody cared, and everybody forgot about that other Go!. So, happy birthday, Go, and rest in peace, Go! https://en.wikipedia.org/wiki/Go!_(programming_language)#Conflict_with_Google https://en.wikipedia.org/wiki/Go!_(programming_language)#Con...

p2detar 11mo ago

I recently finished my first ever side gig in Go - a web platform that organizes business processes between multiple actors. Got paid and more feature requests are coming in. Fronted with Caddy, the whole thing runs flawlessly on a $5 VPS. I love Go.

ashishb 11mo ago

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.

stOneskull 11mo ago
i've just started learning Go and i really like this aspect. one way to do things, one way to format.. the % operator is a bit confusing for a negative number - that took me down a little rabbit-hole, learning about how a remainder can be different to how i normally think about it.
trenchpilgrim 11mo ago
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.
- ashishb 11mo ago
  > 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.
  - trenchpilgrim 11mo ago
    My group's repos enforce strict rules, theirs does not.
    - millerm 11mo ago
      Yeah, I've been there. I would get passed down horribly formatted code from another repo and it showed the data scientists writing it barely knew what they were doing. It was their repo, we couldn't do anything about it. They wouldn't reformat the code, because they were afraid it would break. They also passed us a lot of Python, and you can see where they got this fear from.

threemux 11mo ago

I use Go every day at work and it's still the first thing I reach for when completing personal projects. It gets better every year. Keep up the good work Go team!

bobjordan 11mo ago

I tried to use go in a project 6-7 years ago and was kind of shocked by needing to fetch packages directly from source control with a real absence of built in versioning. That turned me off and I went back to python. I gather that now there’s a new system with go modules. I should probably revisit it.

kasperset 11mo ago

I am not really familiar with Go but I wonder where it would be without Google's support and maintenance. I have no doubt it is a solid language with some really smart people in programming language design behind it. It is so much easy to release programming language but so much difficult to maintain and curate it over time.

rishabhaiover 11mo ago

Love Go! It gently introduced me to the systems programming world.

nicodjimenez 11mo ago

Golang to me is a great runtime and very poor language. I could maybe get used to the C pointer-like syntax and to half of my code checking if err != nil, but the lack of classes is a step too far. The Golang idiomatic approach is to have a sprawling set of microservices talking to each other over the network, to manage complexity instead of having classes. This makes sense for things like systems agents (eg K8) but doesn't make sense for most applications because it complicates the development experience unnecessarily and monoliths are also easier to debug. I would not use Golang for a big codebase with lots of business logic. Golang has not made a dent in Java usage at big companies, no large company is going to try replacing their Java codebases with Golang because there's no benefit, Java is almost as fast as Golang and has classes and actually has a richer set of concurrency primitives.

wanderlust123 11mo ago
I think lack of classes is highly desirable. So much enterprise code is poorly put together abstractions. I think go needs some more functional aspects, like iterators and result type/pattern matching.
- robryan 11mo ago
  Go does have iterators: https://pkg.go.dev/iter https://pkg.go.dev/iter
  - wanderlust123 11mo ago
    Thanks! Did not see this until your message, looking forward to make use of this
- nicodjimenez 11mo ago
  The solution to bad abstractions it not to make it very difficult to create abstractions at all. For systems code I think it's fine but for application code you probably want some abstractions or else it's very hard to scale a codebase.

ModernMech 11mo ago

Oh wow, so it's already been 16 years since Google steamrolled the Go! language, which had existed a decade before Go and had every right to the name. This was when they were still pretending "do no evil" was their brand. There may be no honor amongst thieves but there is honor amongst langdevs, and when they did Go! dirty, Google made clear which one they are. Status changed to Unfortunate https://github.com/golang/go/issues/9#issuecomment-66047478 https://github.com/golang/go/issues/9#issuecomment-66047478

MagicMoonlight 11mo ago
Does anyone use that other language? No!
- ModernMech 11mo ago
  That's not the point, no one uses 99% of languages, so if that's the standard then it's a free-for-all. The PL community is small, so norms are important. PL naming code is: 1. Whoever uses the name first, has claim to the name. Using the name first is measured by: when was the spec published, or when is the first repo commit. 2. A name can be reused IFF the author has abandoned the original project. Usually there's a grace period depending on how long the project was under development. But if a project is abandoned then there's nothing to stop someone from picking up the name. 3. Under no circumstances should a PL dev step on the name of a currently active PL project. If that happens, it's up to the most recently named project to change their name, not the older project even if the newer project has money behind it. 4. Language names with historical notoriety are essentially "retired" despite not being actively developed anymore. All of this is reasonable, because the PL namespace is still largely unsaturated*. There are plenty of one syllable English words that are out there for grabs. All sorts of animals, verbs, nouns, and human names that are common for PLs are there for the taking. There's no reason to step on someone else's work just because there's some tie in with your company's branding. So it's pretty bottom basement behavior for luminaries like Ken Thompson and Rob Pike to cosign Google throwing around their weight to step on another dev's work, and then say essentially "make me" when asked to stop. * This of course does not apply to the single-letter langs, but even still, that namespace doesn't really have 25 langs under active development.

zmj 11mo ago

I'm glad Go exists. If nothing else, it cemented that tooling is at least as important as the language.

MagicMoonlight 11mo ago

I just can’t get over the idiotic syntax. Instead of “int x” You have “var x int” Which obscures the type, making it harder to read the code. The only justification is that 16 years ago, some guy thought he was being clever. For 99.99% of code, it’s a worse syntax. Nobody does eight levels of pointer redirection in typical everyday code.

LexiMax 11mo ago
16 years is a bit of an under-estimate. I think the first popular language with this form of declaration was Pascal. var foo: char; Go was developed by many of the minds behind C, and inertia would have led them to C-style declaration. I don't know if they've ever told anybody why they went with the Pascal style, but I would bet money on the fact that Pascal-style declarations are simply easier and faster for computers to parse. And it doesn't just help with compile speed, it also makes syntax highlighting far more reliable and speeds up tooling. Sure, it's initially kind of annoying if you're used to the C style of type before identifier, but it's something you can quickly get to grips with. And as time has gone on, it seems like a style that a lot of modern languages have adopted. Off the top of my head, I think this style is in TypeScript, Python type hints, Go, Rust, Nim, Zig, and Odin. I asked Claude for a few more examples and apparently it's also used by Kotlin, Swift, and various flavors of ML and Haskell. But hey, if you're still a fan of type before variable, PHP has your back. class User { public int $id; public ?string $name; public function __construct(int $id, ?string $name) { $this->id = $id; $this->name = $name; } }
- mxey 11mo ago
  > don't know if they've ever told anybody why they went with the Pascal style I don’t know if this is the reason but Robert Griesemer, one of the three original guys, comes from a Pascal/Modula background.
- anal_reactor 11mo ago
  Golang exists in this weird place where it's similar enough to C so that intuition connects it with C, but at the same time different enough that you keep tripping over.

captainkrtek 11mo ago

Been happily working in Go since 2014. My career has spanned C, Python, C#, Ruby, and a smattering of other languages, but am always quite fond and preferential towards Go.

Pbhaskal 11mo ago

It has been my go to language since 2020. I was given a task to complete in a week and my lead told just go through Go playground and write the code (it was some snmp receiver/transmit stuff). To my surprise it was so easy to learn, write and more importantly test. Only recent thing i have not learned is generics, hopefully will get their sooner. Coming from java background the things Go did felt so clever and just too good to believe

adamddev1 11mo ago

I'm thankful for Go because it was an easy first introduction to static typing. I remember making a little web app and seeing the type errors pop up magically in all he right places where I missed things in my structs. It was a life-changing experience.

culebron21 11mo ago

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

alain_gilbert 11mo ago
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 https://github.com/alaingilbert/agl
9rx 11mo ago
> proper enums It has proper enums. Granted, it lacks an enum keyword, which seems to trip up many. Perhaps what you are actually looking for is sum types? Given that you mentioned Rust, which weirdly[1] uses the enum keyword for sum types, this seems likely. Go does indeed lack that. Sum types are not enums, though. > sensible arrays & slices, without any magic and awkward syntax Its arrays and slices are exactly the same as how you would find it in C. So it is true that confuses many coming from languages that wrap them in incredible amounts of magic, but the issue you point to here is actually a lack of magic. Any improvements to help those who are accustomed to magic would require adding magic, not taking it away. > iterators Is there something about them that you find lacking? They don't seem really any different than iterators in other languages that I can see, although I'll grant you that the anonymous function pattern is a bit unconventional. It is fine, though. > result unwrapping shorthands Go wants to add this, and has been trying to for years, but nobody has explained how to do it sensibly. There are all kinds of surface solutions that get 50% of the way there, but nobody wants to tackle the other 50%. You can't force someone to roll up their sleeves, I guess. [1] Rust uses enums to generate the sum type tag as an implementation detail, so its not quite as weird as it originally seems, but still rather strange that it would name it based on an effectively hidden implementation detail instead of naming it by what the user is actually trying to accomplish. Most likely it started with proper enums and then realized that sum types would be better instead and never thought to change the keyword to go along with that change. But then again Swift did the same thing, so who knows? To be fair, its "enums" can degrade to proper enums in order to be compatible with Objective-C, so while not a very good reason, at least you can maybe find some kind of understanding in their thinking in that case. Rust, though...

tapirl 11mo ago

> 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-in-go-1.22.html 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 https://go101.org/bugs/go-build-directive-not-work.html

gf000 11mo ago
It's especially funny considering that this issue has been known from lisps for 50+ years..
- tapirl 11mo ago
  They can fix the issue by just changing the semantics of "for-range" loops, almost no negative effects. But they also applied the change to 3-clause-for loops, which causes many problems, some of which have been pointed out before the change was made. So the rookie mistake is totally caused by arrogance.
0x696C6961 11mo ago
The new toolchain continues to compile old code using the old semantics. Only modules which specify Go 1.22 in go.mod have the new bahivour.
- tapirl 11mo ago
  The problem is, when you modified the go version in go.mod, the behaviors of some code change, but the change is not easy to detect in time. Go team never plan to develop a tool to identify/detect code affected by such breaking changes, leaving developers without guarantees for safe migration. And when running go scripts without go.mod files, the v1.22 toolchain doesn't respect the "//go:build go1.xx" directives: https://go101.org/bugs/go-build-directive-not-work.html https://go101.org/bugs/go-build-directive-not-work.html And consider that some people run go scripts even without the "//go:build go1.xx" directives ... (Please don't refute me. The Go toolchain allows this and never warns on this.)

pjmlp 11mo ago

And still so many programming language design history lessons to learn from. Maybe by 18, or 21, the maturity finally settles in.

rollulus 11mo ago

I love Go. It makes that I get shit done. I picked up Go more than ten years ago, because it was HN’s darling and when I didn’t know about hype cycles. No regrets.

tmoertel 11mo ago

The introduction of automatic code modernizers to keep legacy code up to date with modern Go idioms is interesting: > With gopls v0.18.0, we began exploring automatic code modernizers. As Go evolves, every release brings new capabilities and new idioms; new and better ways to do things that Go programmers have been finding other ways to do. Go stands by its compatibility promise—the old way will continue to work in perpetuity—but nevertheless this creates a bifurcation between old idioms and new idioms. Modernizers are static analysis tools that recognize old idioms and suggest faster, more readable, more secure, more modern replacements, and do so with push-button reliability. What gofmt did for stylistic consistency, we hope modernizers can do for idiomatic consistency. Modernizers seem like a way make Large-Scale Changes (LSCs) more available to the masses. Google has internal tooling to support them [1], but now Go users get a limited form of opt-in LSC support whenever modernizers make a suggestion. [1] https://abseil.io/resources/swe-book/html/ch22.html https://abseil.io/resources/swe-book/html/ch22.html

liampulles 11mo ago

I love Go. One thing I haven't seen noted here is how great it is for use in monorepos. Adding a new application is just a matter of making a folder and putting a main packaged go file with a main() func. Running go install at the root ./.. takes care of compiling everything quickly and easily. This combined with the ease of building CLI programs has been an absolute godsend in the past when I've had to quickly spin up CLI tools which use business logic code to fix things.

linhns 11mo ago
Agreed. This use case is not mentioned enough.
liveoneggs 11mo ago
I don't understand how this isn't also true for practically every other language?
- vlovich123 11mo ago
  It’s not true of C/C++ which need changes to the build system. Also true for rust workspaces which is how I’d recommend structuring monorepos although it is generally easy (you just need to add a small cargo.toml file) or you can not use a workspace but you still need to declare the binary if I recall correctly.
  - o11c 11mo ago
    It's true for any C/C++ project which bothers to write 10 lines of GNU `make` code. The problem is that many projects still pander to inferior 1980s-era `make` implementations, and as such rely heavily on the abominations that are autotools and cmake.
    - duskwuff 11mo ago
      C/C++ library dependencies are a thing, and there's no universal solution to acquiring and installing them.

Zardoz84 11mo ago

I tough that would be about SWEET16

insurancesucks 11mo ago

Every Go thread on this site is the same. "Man I love Go, it's so simple, plenty fast, really easy to pick up, read, and write. I really love that it doesn't have dozens of esoteric features for my colleagues to big brain into the codebase" "Oh yeah? Well Go sucks, it doesn't have dozens of esoteric features for me to big brain into the codebase" Repeat

dlock17 11mo ago
Yep, and I personally feel like it's been the biggest stealth marketing of Go through the years.

disintegrator 11mo ago

When you turn on exhaustive, exhaustruct and wrapcheck linters in golangci-lint. You get such a massive safety boost and it makes you fly through writing Go.

mikewarot 11mo ago

And here I was anticipating a release of Go for the Apple ][ computer[16] [16] https://en.wikipedia.org/wiki/SWEET16 https://en.wikipedia.org/wiki/SWEET16

duskwuff 11mo ago
It might be possible. TinyGo exists, and can target some devices with even less memory than the Apple II, like the ATmega328 microcontroller.

submeta 11mo ago

Been writing Python code for over twenty years, and using it for personal and work projects, not mainly, but to suppport my work. Recently I ported some of my code to Go and was blown away: Cross compiler, creating binaries, concurrency done right, super fast code. I come very late to the party, and writing software is not my main job, but Go is such a nice complement for my toolbelt. Python for prototyping or writing small services with fastapi, go for network realted stuff, serving lots of users. Super happy with this. And I am wondering if Rust would be a good addition. Or rather go with Typescript to complement Python and Go.

iainctduncan 11mo ago

Curious if anyone has real-world stories/data around Green Tea's pause times....