[scoopdewoop]

I also have been using Go with Tcell recently. Making small games is how I have always learned new programming languages.

I am coming off of a couple of years of playing with C to understand languages better, and free myself from the complex stacks that I use at work. I've been chatting with a highly-educated PL friend of mine about my language likes/dislikes, and he would always remark on really pragmatic choices Go had made.

I had always dismissed Go, and that has really let me see a reddit/HN hivemind I'm susceptible to. It was so easy to think "GC? Google? No thanks". After a while I saw a pattern of people disparaging Go in favor of Rust, but then using Python/JS for their own actual code. It made me feel that maybe the hivemind had overlooked the actual use-cases.

I understand that the language had its problems, from sub-par GC performance to poor Windows support, to the "no generics" meme. But for someone just getting into it now, it has been SEAMLESS. VSCode is a first-class dev environment after being configured by the single official Go plugin. Modules are awesome, and coming from C its so nice to just "go build" and have that just work.

I really expect Go to pick up a lot of steam with hobby developers soon. For simple games, Go is capable of producing cross-compiled static Windows binaries with SDL2 from Linux. That kind of dev experience could really win over a lot of C++ holdouts from the itch.io and HandMade communities that would prefer if C++ was just C with classes and types. The GC is so fast that it doesn't even cut into a 60fps time budget, and all the preallocation tricks from C still work fine... it has pointers and arrays like we are used to.

I was shocked to find how much I'd enjoyed Go. If you are interested in C/Zig/Odin, I think it is certainly worth checking out Go as a tool to play with arrays and structs, a paradigm many programmers enjoy. Having high quality libraries in the stdlib like JSON (de)serializers and even animated GIF authoring means that a lot of the simple code you might write for your own amusement won't be subject to the fast bitrot of other ecosystems.

[skrtskrt]

I've been working professionally in Go for almost a year now and I do agree Go is really pragmatic and is largely nice for just "getting stuff done".

However there is an absurd amount of nil checking which can be easy to miss and not always caught by the common linting tools. Once you use Result/Option types and proper enums with pattern matching that is expressive and safe, it wears on you that Go does not have this.

[coryrc]

> it wears on you that Go does not have this

And it's a completely unforced error and doubled-down on by the development team.

[philosopher1234]

Where did they double down on this? They explicitly said that the design of generics was leaving the door open for sum types.

[nikki93]

Re: perf for hobby gamedev, I basically agree for native builds, but lately I've felt like Wasm support seems key for hobby gamedev (so you can have more people play your game / without downloading it / it works directly on mobile too without dealing with app or play store). And Go perf in Wasm unfortunately is not so good (I was hitting big GC pauses when trying to make a game with Ebiten and large images).

I ended up writing a Go -> C++ compiler. Go's standard library parser/typechecker made it very doable. The games I've done with it don't use the GC at all but also don't manually manage memory -- they use an ECS api which helps. https://github.com/nikki93/gx -- the README links to development workflow video and complete example game code. I get the perf, interop/libs and portability of C/C++ but with Go's developer experience (well the build system involves C/C++ of course but I have something set up there that I now just use).

[itake]

> after being configured by the single official Go plugin

Are you using a small or large code base? VSCode falls over at my job's monorepo. Goland has much better performance.

[shirogane86x]

I don't really buy into go (it's not my type of language), but I wanted to ask a genuine question: are there many semi-mainstream languages that don't have modules that _just work_, or an official plugin for VSCode that just works? I've never found that to be a "plus", as much as it is the bare minimum. and nowadays I don't see that many up and coming languages that miss out on it. Admittedly though the cross compilation is nice (not enough to win me over, at all, but still very nice. The very few times I've needed cross compilation in other languages I reached for nix, and that wasn't very pleasant)

[sk0g]

Most compiled languages have fractured build ecosystems, and may require some tricky invocation orders, external+not-included dependencies, or some funky flags depending on your compiler version. Or may just not work because you have the wrong compiler, missing their preferred build scripting runtime, etc.

NPM (packages) frequently go down, doesn't resolve packages, or just does something unexpected. Java has the Gradle/Maven split, C++ has a few extra common ones - Make/CMake, Autotools, Ninja, Meson, etc. Modern C# is the one that's got a similar scene to Go from what I've seen.

Go is simple and consistent. It adheres to the Zen of Python, particularly "There should be one– and preferably only one –obvious way to do it.", better than Python itself does (IMO). You check out a repo, you run go build, and 90% of the time you have a binary. A 5 line Python script could automate this process, good luck doing the same with Java or C++.

[shirogane86x]

That is 100% fair. I mostly develop on .NET+TS at $dayjob so I never really have experienced particular problems with nuget, and I've had the luck of never having an npm package go down on me either - so I just never really experienced the problems that people are frustrated about.

[adamgordonbell]

I wrote a post about this topic. Consistent tooling is very valuable.

https://earthly.dev/blog/programming-language-improvements/

[noodleman]

This is really the selling point of Go for me that makes up for it's shortcomings. I've probably lost years off my life thanks to gradle.

[sk0g]

When your build scripts require the power of a full-blown programming language, I do have to wonder what catastrophe lead to such complications! I'm sure there's a reason for it and all, but it's just not something I will deal with unless I am being paid (handsomely) to do so.

[scoopdewoop]

You tell me, what other language has a drop-in solution that provides module management, formatting, integration with the debugger, intellisense docs, linting with static analysis while I'm typing, and even testing? The plug-in is actually made by the Go Team at Google, its not like adding Black and Poetry etc. in python, its not even like the moving target that is create-react-app or whatever people use now in JS/TS. Those are much older languages, but what would you compare it to?

I'm not saying Go is the only modern language, its pretty retro in some ways, but it has an exceptional tooling story. The fact that its mainly based around the official go tool helps.

[hedora]

Rust also has those things. (It also has performance profiling, fuzz testing, benchmarking tools, etc, etc., as I'm guessing golang does.)

[scoopdewoop]

Thats dope, and I kind of figured.

The tooling is probably why Go and Rust get compared so often, despite having little in common. Its weird to see that written off as a common feature though. It was nothing like my experience with clojure or julia.

If there are any languages with Go-like tooling that have a bigger job market, I'd love to know.

[metaltyphoon]

I'm mainly do C#, TypeScript, C++ (occasionally) and for some reason I really like go. There are really only 4 things I wish was different and perhaps it would become my goto language.

1) Simplify error handling. It's annoying having to create your own stack frame by composing strings.

2) Let me use my variable names. I find it so annoying that I have to come up with names just because the variable is being shadowed. Either change the package scope to use :: or make types be PascalCase with an `pub` keyword for exports.

3) Add a shorthand for lambda instead of having to type `func()`.

4) Allow a file scoped, not package, variable.