Ask HN: What do you like/dislike about Golang?

I&#x27;m a sysadmin type, so take this with a grain of salt.<p>Like:<p>- Compiled and can be run as a scripting language.<p>- Easy to learn, quite simple to use (even concurrency!)<p>- Cross compilation is an environment variable setting.<p>- Fast compilation, though apparently this gets worse with reflection and generics (and it&#x27;s not <i>that</i> important to me honestly)<p>Dislike:<p>- The opinionated build&#x2F;dependency system, which sort of doesn&#x27;t work with monorepos unless you do things that &quot;are not recommended&quot; like `insteadOf`<p>- When deserialising things (JSON for example), an omitted key becomes an empty value. As many will tell you, there is a difference between 0 and Null&#x2F;None.<p>- Case based visibility. That feels like the opposite of clear.<p>- Slice semantics, easy to accidentally override values if you&#x27;re not careful. (slices are references to arrays, you can reference a subset of a slice which looks like a new slice, but appending to it will overwrite a value in original array, because when you do `var slice_new := slice_old[0:30]`; it&#x27;s really just a reference to slice_old, not a new slice with the contents from 0-30.

My big complaint with Golang is the way they (don&#x27;t) handle nulls.<p>Golang treats null as a memory initialization problem, while ignoring its semantic use.<p>You still encounter nulls when interacting with external systems, and Golang has inconsistent ways of handling them. From memory (it&#x27;s been a while):<p>- Nullable DB columns return a struct with the value, and a boolean for whether the value is <i>actually</i> the value, or a placeholder for null<p>- Requesting a non-existent query parameter from an inbound HTTP request returns an empty string. That&#x27;s &quot;fun&quot; to debug.<p>- Decoding a JSON object with a null value omits the key+value completely. There&#x27;s no way to tell the key was ever present. This is a problem when you don&#x27;t control the originator of the JSON.<p>- I think maybe sometimes null pointers are used?

At 2&#x2F;3 of every screen, error handling is absurdly noisy. A DSL for wrapping and bubbling up errors (the 99% case) is desperately needed.<p>The builtin containers just suck. They’re always mutable. Map write conflicts might panic, yet there’s no support for preventing them. They aren’t comparable, which can cause panics elsewhere. You have to pretend slices have move semantics, because copies may or may not share state after an append. They don’t implement any interfaces, so you can’t even replace them or reuse their sugar.<p>Functions can return tuples, but tuples aren’t first-class, there are no maps or channels of tuples.<p>No overloading, each type sig needs its own func name and IDE refactoring won’t choose the right one.<p>Reflection is very limited. No access to types or functions by name. No type or func or arg annotations, just a single string on a struct field.<p>The GC design is pretty old and people go out of their way to avoid relying on its throughput.<p>Liked: The memory footprint is pretty small. Parts of the community are starting to rely on code generation to work around the base language (e.g., piles of ignored boilerplate because Mockito can’t be implemented at runtime).

1. Static linking. I&#x27;m astonished by how many languages expect the end user to install dependencies&#x2F;runtime themselves, and something about it feels very <i>impure</i>.<p>2. The &quot;go&quot; keyword (and the whole goroutine system underneath it). Threads are clunky, somewhat unportable and generally unscalable. Goroutines just feel right.<p>3. Ability to use multiple major versions of a library. Diamond dependencies are an unsolved problem in many languages I&#x27;ve worked with, but with Go you don&#x27;t ever even think about them.<p>4. Implicit interfaces. Having to write &quot;implements X&quot; just to be able to use a type always felt wrong. Implicit interfaces just make sense.<p>5. The gopher mascot. I just love that little guy.

Go lacks things I decided I must have, including Sum types and a string type which doesn&#x27;t just think &quot;string&quot; is a fancy word for &quot;Some bytes&quot;. So I no longer use it in anger. As a result these judgements are perhaps a year or two out of date:<p>I don&#x27;t like the error handling, and I don&#x27;t like that they basically punted the hard problem when it comes to data races.<p>I do like the broad range of stuff in the standard library, and I like how slim its garbage collector and runtime in general feel under use. Start-up time in particular is pretty good for a language with garbage collection.

Without adding another comment about syntax or language specifics, I just like that you can get shit done and stay sane. I have fewer bugs in Go because it&#x27;s easy to read and because adding unit tests is easy. Deployment is simple because it compiles to a single binary. I don&#x27;t need to mess with libraries too much because the standard library is almost all I could have asked for. I can show code to other devs, and they understand it even if they don&#x27;t know the language.<p>What I don&#x27;t like is that Rust is also very intriguing to me :D

Likes:<p>- Big standard lib, including SQL base classes, allowing very consistent DB code. No 6 different ORMs and slightly different DB code for every DB type. Ahem Rust.<p>- Cross-compiling is easy and consistent<p>Dislikes:<p>- Error handling. Done to death, but it direly needs some syntax sugar like Rust&#x27;s `?` operator. Seems like 3&#x2F;4 of any function that does anything significant is `if err` branches.<p>- Nullabilty and the way references work feels like a footgun. Rust feels more clear about what&#x27;s happening when. Not sure there&#x27;s much to be done about it now though.

The quality of the standard library, especially net, time, and to a lesser extent, strings.<p>The tooling, including the built-in testing package and test tool, and go doc. Also vet and fmt, if for no other reason than it precludes most arguments over braces and tabs vs spaces. I don&#x27;t have cause to use it much, but pprof is a dream.<p>I like the idea of the go module system, and the fact that dependency management is part of the language ecosystem. It&#x27;s still a bit clunky, especially if you end up, like I did, stuck with a system that has lots of libraries with poorly-thought out dependency relationships.<p>interfaces, especially single-method ones. But also the fact that your code doesn&#x27;t have to declare it&#x27;s implementing an interface, and has no dependencies on the interface declaration itself.

As someone who likes async&#x2F;await&#x2F;coroutines, I really miss them in Go. Channels are the GOTO of synchronisation, they lead to confusing spaghetti code because there is no structure.<p>Go is really nice to read (once you get used to the fact that half the lines of code in any function are for error handling) unless it uses a lot of channels. Then you need to take great care to understand every &lt;-.

For me Go is unique in that it can produce a fully static binary that can fetch from a HTTPS endpoint. It also supports many architectures. On top of that the package system and it&#x27;s just way more convenient to use than other languages. Easy to learn, easy to put somewhere in practice.<p>Not every program has to be 100% safe and delivering 2M req&#x2F;s. Sometimes you just want to build a program once and ship it.<p>What other language has that? Go isn&#x27;t perfect though. It&#x27;s startup sequence is long, the API towards C (and other languages) is quite bad, and if you build a fibonacci program and compare it with C it&#x27;s 3x slower despite requiring no allocations whatsoever.

Like:<p>- Concurrency. Can shoot yourself in the foot still, but it&#x27;s overall pretty simple to get started and use.<p>- Small language surface. Fairly easy to keep most or all of it in your head.<p>- Good ecosystem, and easy to pull in libraries.<p>- Good standard library that does a lot out of the box.<p>- Easy for new people to get started with it.<p>- Compiles to a single static binary.<p>Dislike:<p>- Cluttering of my code with boilerplate error returns (a common criticism!).<p>- Can&#x27;t stop consumers of a library from doing the wrong thing. E.g., ensuring that someone always initialises an internal map of a new struct instances is challenging, with tradeoffs for each option.<p>- In line with previous, overall lacking the language tools to enforce correct usage or behaviour.<p>- Lots of footguns.

It&#x27;s been a long time since I last looked at golang, but the first time I met it, I instantly disliked the way it imposed its own idea of filesystem organization onto the user. I wanted to run a Heartbleed checker, and instead of being able to clone the repository into a new subdirectory inside my ~&#x2F;projects and compiling and running from there, like I would do for projects written in any other language, the go compiler required that the project was cloned into a global centralized path, where all projects written in golang would end up, mixed together without any separation.

Like: get things done mentality, green threads, duck typing, default formatter.<p>Dislike: still no easy way to dynamically create mocks -maybe some brave soul will try to solve it after generics :)- I don&#x27;t like code generation or manual mocking, we have a large codebase, 1000+ file and so much noise in the repo because of generated mocks. And yes we are fan of unit tests and aiming 100% coverage on business logic.

What I like,<p>It is a nice language had it been released in the mid-90&#x27;s, following the footsteps of Oberon and Limbo.<p>What I dislike,<p>Being designed a decade later ignoring everything that happened in mainstream computing since Oberon and Limbo came to be, then adopting features that weren&#x27;t properly backed in from the get go.

Like:<p>- Compiles to a static binary that&#x27;s relatively small compared to something like .NET AOT.<p>- Structural typing.<p>- No semicolons.<p>Dislike:<p>- Lack of exceptions. I can understand wanting to avoid exceptions for safety critical software like avionics, but for most application programming, requiring manual error handling for every function call is cumbersome and unnecessary.<p>- Too verbose &#x2F; lacking features. For example, there&#x27;s not a short syntax for lambda expressions, like the =&gt; operator in C# or JavaScript.<p>- Public &#x2F; private access modifiers at the package level rather than the class level (there are no classes).<p>- Language development is driven primarily by Google, who has a history of killing products.

Pro:<p>- Community. Pragmatic, high signal to noise ratio in online resources, little magic, sympathetic to the needs of production operations. Consider for example httptrace [0]. This kind of introspection isn&#x27;t even normally possible in many languages and their library ecosystems. In Go world, people care about this stuff.<p>- Standard library. High quality and flexible packages for stuff like web servers and clients, TLS certificate manipulation, SQL, various data encodings, etc.<p>- AST package, strong first-party support for manipulating Go source files.<p>- Table driven testing norm is very cool in certain circumstances.<p>Con:<p>- Verbosity. Something like making an HTTP request is ~7 different operations, each with their own error branches.<p>- The tedium of meeting coverage mandates. Having to code-generate tons of mocks and type out very elaborate test tables for what feels more like busywork than genuine confidence-building. Partly this is my employer&#x27;s fault for having high coverage standards though.<p>- Despite its apparent simplicity, there are significant footguns lying around slices, loop variable captures, channel deadlocks, etc.<p>- The Go community&#x27;s solution to a lot of language shortcomings (verbosity, type system, etc) is code generation. For example, we have an internal framework for parallel task graph execution, which is much safer and cleaner than manually managing channels and goroutines. But this kind of thing cannot be expressed as a regular library like it would be in other languages.<p>- Despite the prevalance of code generation, Go does not quite have a macro system, leading to third-party build systems like Bazel in companies that do a lot of code generation with their Go. This then leads to rough edges with the other tools&#x27; handling of &quot;de-materialized&quot; generated code and the need for stuff like GOPACKAGESDRIVER for proper editor support. Editor and debugger support for generated code, the way things stand, can be rough.<p>- Certain syntax rules such as trailing commas and unused variables&#x2F;imports (especially when commenting stuff out temporarily to debug something!) can get on my nerves.<p>[0] <a href="https:&#x2F;&#x2F;pkg.go.dev&#x2F;net&#x2F;http&#x2F;httptrace@go1.19.3" rel="nofollow">https:&#x2F;&#x2F;pkg.go.dev&#x2F;net&#x2F;http&#x2F;httptrace@go1.19.3</a>

Like: The package and build system is amazing and just works. Simple, yet intuitive and powerful with the introduction of modules. It&#x27;s hard to quantify the number of hours I&#x27;ve saved over other tools hunting down build&#x2F;linker&#x2F;dependency management issues.<p>Dislike: Error handling feels extremely verbose. I like the design choice to return errors explicitly, but it feels like there needs to be a return-if-error syntactic sugar introduced to avoid the endless if err != nil ... return err peppered everywhere.

Aside: has anyone read “100 Go Mistakes and How To Avoid Them” [1] and would care to share their takeaways?<p>After getting back to it after quite some years I’m still conflicted about the language and its tooling. It’s a frustratingly (and seemingly) primitive&#x2F;simple language but also a very productive one. I personally don’t <i>love</i> golang but it’s a great tool “for the common programmer &#x2F; worker”.<p>The unix philosophy is baked in without the excitement (to me). That’s OK.<p>Also the stdlib has similarly great &#x2F; lacking characteristics. It’s strong but then often missing basic functionality that you just don’t want to maintain yourself any more (e.g. try to do a unix like sort &#x2F; unique on a slice of strings - afaik only lexicographical sorting in there).<p>I would say that the main driver for my rekindled interest in the language stems from its current Lingua-Franca aspects for “higher level systems programming”. I’m thinking Kubernetes and Terraform here for example.<p>In many ways but especially in this one it’s similar to Python actually - which I also don’t love at all - but which FWIW found its niche as the current go-to scientific computing and machine learning language &#x2F; ecosystem.<p>[1] <a href="https:&#x2F;&#x2F;www.manning.com&#x2F;books&#x2F;100-go-mistakes-and-how-to-avoid-them" rel="nofollow">https:&#x2F;&#x2F;www.manning.com&#x2F;books&#x2F;100-go-mistakes-and-how-to-avo...</a>

I think it&#x27;s a very pragmatic language and I like that.<p>I hate the error handling.<p>I dislike implicit interfaces - they make refactoring harder. The existence of interface assertions is an anti pattern.<p>The standard library leaves a lot to be desired. It&#x27;s very much not a &quot;batteries included&quot; language.<p>The go community are super defensive and resistent to criticism. So many times I see people ask reasonable questions about something lacking g in go only to be told that it&#x27;s their fault for wanting it.<p>I may sound negative but I actually rather like go. But no language is perfect, obvs.

LIke:<p>- Decent speed of compiling and execution.<p>- Expressiveness.<p>- I like the struct&#x2F;receiver&#x2F;interface interplay to create an analog of classes.<p>- Nice standard library.<p>- Cross compilation.<p>Things I wish for:<p>- Ternary operator.<p>- Something a bit closer to inheritance. Embedding structs in other structs fools you into thinking there&#x27;s inheritance, but you quickly learn that it doesn&#x27;t work the way you think it will.<p>- At the same time, fully implementing a functional programming paradigm isn&#x27;t particularly easy either.<p>But all in all, I&#x27;m a big fan.

The answer to both is &quot;it&#x27;s boring&quot;.

Like: standard library and readability. The &quot;If it ain&#x27;t broke, don&#x27;t fix it&quot; philosophy that I miss from the earlier Python days.<p>Dislike: awkward error handling and testing &#x2F; mocking

Go is the best.<p>Go’s culture of minimalism, pragmatism, and just get things done is also amazing.<p>What could be better:<p>- Even faster runtime.<p>- Even more efficient garbage collector.<p>- Sum types would have been nice to have.<p>- Structured logging would be great to have.<p>- Structured error would be nice as well.<p>- Cgo could be better.<p>- Memory arena would be great for database applications.<p>- Buffered channel is not as useful as I thought.<p>- Better channel performance would be nice.<p>- Closing a channel is not safe and easy to make a mistake doing it.<p>- Embedding could be improved.<p>- Standard library needs a lot more data structures.<p>- It needs a tuple data structure so that users can return (result, result2, error). If this exists, we can create a nice chainable libraries.<p>- gopls automatically generating test struct as a second implementation of an interface would be super nice to have.

Likes:<p>- The build&#x2F;test tool is pretty good<p>- Opinionated formatting&#x2F;style is nice (even if I disagree with some choices, it removes a huge organizational bikeshedding problem)<p>- Explicit error handling<p>Dislikes:<p>- The generics implementation leaves a lot to be desired<p>- Structural typing: may as well be a dynamically typed language (I know it’s not that bad, but sometimes it feels like it)<p>- The terrible implementation of nested&#x2F;embedded errors and lack of support for structured, pattern match inspection of error return values tend to make error handling unnecessarily verbose<p>- The insane use of interfaces literally everywhere, and the tendency for hidden&#x2F;unexpected use of “reflect” leading to funky performance issues

I dislike:<p>- Duck Typed interfaces<p>- Unused variables are compiler errors<p>- Lack of Ternary operator<p>- Variable short declaration (:=)<p>- Using case for exported names instead of access modifier

Like:<p>- Ecosystem<p>- Static linking<p>- goroutines<p>- small and light runtime<p>- fast compilation speed<p>Dislike:<p>- missing shorthand lambda functions, making functional programming very painful<p>- typed nils<p>- billion dollar mistake (lack of non-nullable types)<p>- implicit&#x2F;automatic copying on value types. Value types as a whole need to be re-thought.<p>- too much error handling boilerplate<p>- unused variables are compiler errors<p>- struct init not exhaustive

The simplicity is nice. It&#x27;s one of the more readable languages. I particularly like that reflection has sensible limitations, so you can&#x27;t produce the ridiculous frameworks that appear in Java and friends.<p>I wish channels and goroutines were more strict, so that you could have some basic assurance no race conditions can be present.<p>Defer is very convenient, which is a problem, as it is a source of bugs. It&#x27;s usually used to ensure file-like objects get closed, but generally those return important errors when closed. A simple &quot;defer file.Close()&quot; will silently ignore the errors generated.

Like:<p>-The go AST package was a pleasure to use<p>Dislike:<p>- Boilerplate error handling<p>- Excessive verbosity<p>- Multiple return not being of a type<p>- Duck Typed interfaces and the empty interface<p>- Go generate that makes verbosity worse<p>- Case-sensitive namespacing that leads to hunts for all the<p>instances<p>- Namespacing in modules that leads very large files<p>- Shadowing rules that let you shoot yourself in the<p>- Rules around =, := and var<p>- Slice tricks and for loops try to encompass iteration instead of something like list comprehensions<p>- Nullability and default values<p>- Short variable names to the point of being meaningless even in the standard library<p>- The go community&#x27;s seeming insistence on a singular or idiomatic way to do things<p>- The standard library is missing basics<p>Edit: Added some formatting.

Languages must choose tradeoffs, and I think Go gears its tradeoffs towards large projects.<p>Generally the larger a project becomes, the longer it takes to add features and fix bugs - so to combat this Go favors quick compile times, easy monorepos, simple tooling, and most of all: very consistent code. Go&#x27;s limited syntax is a feature, not a bug.<p>Syntax sugar in a language allows for writing code quickly, but it (arguably) opens up more opportunities for bad code - e.g. using language features inappropriately, mixing the &quot;sugar&quot; approach with the &quot;manual&quot; approach in the same codebase, being terse and hard to read, etc. If most of a developer&#x27;s interaction with code is spent reading rather than writing, then it makes sense to value quick to read but long to write code. Go&#x27;s philosophy of there being &quot;one way&quot; to do things (arguably) achieves that.<p>Having a very transparent control flow (including treating errors as simply values) is in line with that. Yes errors pollute one&#x27;s code - I would like an operator for that, but I&#x27;m glad the error conditions are being represented clearly.<p>Go is perhaps not a good language if you want to get an MVP going quickly, or write something with a performance focus.<p>Disclaimer: I love Go. I taught myself Go while I was working as a Java dev and it was a big factor in me finding a new job.

Having to use reflection and the interface{} (now &#x27;any&#x27;) escape hatch to see what fields are in an unknown JSON object &quot;the pragmatic way&quot;

Like:<p>- `go generate` for embedding resources into the executable. So intuitive and beautiful.<p>- Strict curating. It&#x27;s the kind of language that things don&#x27;t get into unless they&#x27;re the right solution.<p>- Performance! Python was my favorite language before Go got sufficiently mature. It was refreshing to have that much efficiency coming from Python.<p>- `if err != nil {`, dammit!<p>- Imports referring to the location where the code can be got. `import &quot;github.com&#x2F;fogleman&#x2F;gg&quot;` for instance.<p>- `go fmt`. Nuff said.<p>- Tabs as the standard indentation character.<p>- `fallthrough`<p>- `init()`<p>Dislike:<p>- nil. I wish nil had a smller role in the language. It&#x27;s an agreed best practice in Go that a zero value should be a ready to use thing. I feel like that would be easier to do (and more true of the core language) if the zero value of a slice&#x2F;map was an empty slice&#x2F;map, the zero value of a pointer was a pointer to a zero value of the type it points to, etc. Maybe this can&#x27;t be done for all types (function and interface types, for instance), and maybe there are good reasons for the way it is that I&#x27;m not smart enough to realize, but if it could be done for some types, it would be nice.<p>Things I Pretty Much Eschew:<p>- Generics are limited. Maybe I&#x27;m missing something, but I doubt I&#x27;ll be using generics as they are very extensively at all. If we could make generic <i>types</i> that would be something I could see myself using more.<p>- Embedding. It&#x27;s rare I find a use for that.<p>- `defer`, honestly.

I dislike job descriptions. For some reason, most Golang positions are actually DevOps positions (Kubernetes, AWS, etc...).

It&#x27;s a very practical language, and I like its affinity for static binaries.<p>A downside is Google&#x27;s approach to handling modules: <a href="https:&#x2F;&#x2F;drewdevault.com&#x2F;2021&#x2F;08&#x2F;06&#x2F;goproxy-breaks-go.html" rel="nofollow">https:&#x2F;&#x2F;drewdevault.com&#x2F;2021&#x2F;08&#x2F;06&#x2F;goproxy-breaks-go.html</a>

Below are my current feelings having worked with it as my primary language over the last 16 months. My previous 7 years of development focused on Java, C++, Python, and JavaScript.<p>Like:<p>- Standard Tooling: formatting coverage, dependencies, BIN install, versioning, vendoring all done in Go CLI<p>- Opinionated, minimal design: often I feel like there are fewer ways to do things in Go than in other languages.<p>- Readability: fewer operators and minimal language design make it feel easier to ramp up and read most go programs<p>Dislike:<p>- Hard to master: some elements are very unintuitive coming from other languages (interfaces). I feel like a lot of content on go.dev is out of date (Effective Go). The Google Style guide is helping to light a path and when they publish Go Tips I think it will get better.<p>- Too Minimal: in some cases it feels like Go went too far in not building language features (no set, use map[$TYPE]bool instead or map[$TYPE]struct{} for more efficiency but less readable imo)

Like:<p>Errors as values. Would I prefer Results&#x2F;Options baked into the language? Yes. Am I glad we don’t have to deal with exceptions? God yes.<p>Stdlib, the ecosystem, and globally the mentality of the community regarding dependencies.<p>Mostly self contained binary that’s easy to (cross) compile and deploy<p>Performance<p>Dislike:<p>Lack of ternary expressions<p>Lack of some standard interfaces (Iterable is a big one)

Not too many complaints. I like it much better than Java backend.<p>Go and Typescript are now my go to for everything I think.

I migrated my scrapers from Python + BeautifulSoup to Go + Colly and it was a pleasure: the new programs are impressive fast (1&#x2F;3 of the time) and managing the concurrency and parallelism is a lot easier in Go that messing up with asyncio. Even the dependency management is a pleasure, no need for virtualenv or other tools.<p>If there is something that I don&#x27;t like it&#x27;s the serialize&#x2F;deserialize of JSON objects: you need to know the structure of JSON in advance and define in your struct. When you are scraping an unofficial API and this change silently, this can be a pain.

Like: 1. Expansive Stdlib: it’s great to know there’s a working library I can rely on that will have long term investment for most things 2. Compile times are fast 3. Readable libraries. It’s pretty easy to folllow go library code Dislike: 1. Interface{} and gotos. They are easily avoidable in production code, but they open up some weaknesses in working with third parties. 2. Error handling. It should be a compile error not to handle a Retuned error without an _.

Like:<p>- Simple concise syntax - Great std lib - Most of the times it&#x27;s easy to do the right thing<p>Dislike:<p>- No concept of NULL values and what it means especially when dealing with JSON - Limited handling of TCP connections life-cycle<p>I&#x27;ll add something which is not a language issue per se but I had to deal with a lot: often new devs to Go will try to force certain mental models acquired with other languages&#x2F;frameworks onto Go and that makes for some terrible Go code.

What I like:<p>- Easy to deploy<p>- Short learning curve<p>- goroutines<p>What I don&#x27;t like:<p>- c bindings are not the best<p>- Error handling code gets old, but at least it&#x27;s always consistent and never magical

Go&#x2F;XML dislikes:<p>XML decoding into structs is an annotational nightmare.<p>XML namespaces are broken and getting no development love.<p>Go&#x2F;XML likes:<p>Otherwise quite OK.

Don&#x27;t like error handling taking multiple lines (<a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=raJGZaIPhOc" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=raJGZaIPhOc</a>)<p>Like everything else.

Love: - Ecosystem - Clean code - Single executable file<p>Dislike: - Pointers -- maybe I am still getting the hang of it. But I feel like pointers throw off a lot of beginner programmers. Would love some practical advice here

I&#x27;m new to golang, but i&#x27;ve had bad experiences with it so far compared to other languages.<p>- method declarations are hard to grep for because the related struct appears before the method name (like &quot;grep &#x27;func String&#x27;&quot; will not find &quot;func (s <i>Struct) String&quot;), and because a module&#x27;s types&#x2F;functions can be declared across several files<p>- many pointer-related footguns, many others have mentioned the nil pointer exception issue, but as a newcomer to golang i found it confusing that i could accept value params in methods&#x2F;functions and mutate those params... only to have those mutations silently discarded because they were a copy of the original data to start with<p>- do you even concurrency?! i ran into a deadlock by using the stdlib in a very simple way, in a sequential manner, in a single-threaded program. i still have no clue why that is, and the program maintainers don&#x27;t either. i&#x27;m probably doing it all wrong, but it was so easy to shoot myself in the foot. If someone more experienced wants to teach me what i did wrong, here&#x27;s the code: <a href="https:&#x2F;&#x2F;github.com&#x2F;ooni&#x2F;probe-cli&#x2F;pull&#x2F;989#discussion_r1032585034" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ooni&#x2F;probe-cli&#x2F;pull&#x2F;989#discussion_r10325...</a><p>- the module system is entirely broken: i&#x27;ve had the go command </i>panic* on me for simply using &quot;go get&quot;... the problem is old and well-known, and has quite a few tickets open on the golang bug tracker: <a href="https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;47979" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;47979</a><p>- the attributes exposed by marshaling libraries are different from one library to the next... i mean that&#x27;s a problem in most languages but after trying out serde.rs briefly i feel like that should be the way in every language to just standardize those fields<p>- golang is not structured for commenting out parts of the code to test something quickly: unused imports&#x2F;variables is a compilation error, and apart from naming a variable &quot;_&quot; there is no way to ignore its usage (using &quot;_&quot; as a prefix like in rust would be an awesome addition)<p>- struct declaration and instantiation has inconsistent syntax: why would i use comma after a field instantiation but not after a field declaration?<p>- the difference between &quot;:=&quot; and &quot;=&quot; is clunky... as you refactor code you end up having a lot of this variable doesn&#x27;t exist, or this variable already exists kind of error... i understand the need for proper variable instantiation and type declaration in general, however &quot;:=&quot; does neither as you require an entirely different syntax (var) for explicit types, and golang is very happy with passing around nil&#x2F;empty values<p>- publicity based on case makes it super hard to decide later whether you want a method&#x2F;field to be public because you need to change the entire API, instead of simply adding a keyword<p>- no standard way to define default fields for a struct? there may be one but across all libraries i&#x27;ve used so far there was weird NewStruct() or NewDefaultConfigStruct() methods which were hard to grep for in the docs&#x2F;code<p>All in all, it&#x27;s not the worst programming language i&#x27;ve used. JavaScript is a lot worse. But from a week of working with it full-time, i feel like go has massively failed at being a better C or a better Python... it feels to me like it combined the failure modes from both ecosystems into a new rather incoherent language.<p>If you&#x27;re looking for quick scripting, i would still recommend Python or PHP which in my humble opinion have much better developer UX. If you&#x27;re looking for serious systems programming, i would recommend Ocaml, Rust, or plain old C, all three of which have amazing tooling. It may be weird to recommend C as an alternative to golang, because C is so low-level it&#x27;s easy to shoot yourself in the foot... but that&#x27;s the thing, C does not try to pretend to be a safer high-level language, it gives you raw tooling. golang tries to be higher-level but i think it failed at that.<p>Sorry for the rant, i don&#x27;t mean to be rude. I just don&#x27;t understand the hype around golang.