Hacker News Reader

I have been using Go at work for a few years after having used rust for years before that (and still using it for other things), and I agree with you.

In my experience, you can not make complexity disappear: it can be reduced to a point, but there's a domain specific lower bound on any project.

So the question is: where do you move it?

Rust decided to move it into the language, whereas Go prefers to move it into your code. I guess that beauty is in the eye of the beholder, but I stand strongly in the first camp, for the simple reason that I find more complex, but more concise and specific forms, to better carry over the thoughts of the people whose code I'm reading.

On top of that Go is pretty silly on many more minor aspects (unused import & variables are a no-go, but dead functions are A-OK; I have to change my session-wide git settings to access private repos; the formatter is very poor; ...).

> Rust decided to move it into the language, whereas Go prefers to move it into your code. I guess that beauty is in the eye of the beholder, but I stand strongly in the first camp, for the simple reason that I find more complex, but more concise and specific forms, to better carry over the thoughts of the people whose code I'm reading.

Put another way, language complexity will be consistent in every project that uses the language, but complexity in the project code can vary drastically from one project to the next. The tradeoff here is that once something gets put into the language (or the standard library, since effectively they share the same compatibility concerns), you can't easily change it later. People coming to Rust from other languages often are surprised that the standard library seems to be "missing" things like a HTTP client or regexes, and to a certain extent, they're right that it appears to be inconsistent with the philosophy of being willing to allow complexity in the language. I think the misunderstanding stems from the fact that decisions driving the development of the Rust language tend to be a lot more conservative than realize due to the (not entirely undeserved) reputation of the Rust community at large. As a somewhat orthogonal example, there's a common perception that the Rust community wants to rewrite the entire world of C/C++ code in Rust, and while the idea of that certain does excite a lot of Rust programmers, the people who are in charge of Rust have actually put a _lot_ of effort into making interop between Rust and C a viable way of working, and there's a surprising amount of tooling in the ecosystem to help bootstrap wrapping C libraries. On the other had, it's fairly well accepted that Go is not intended to be a replacement for 100% of the use cases of C, and yet almost everyone I've talked to who is passionate about Go has had a fairly negative view of the experience of using cgo. I've really come to appreciate how well-thought language-level decisions are made for Rust, and it's unfortunate that strong emotions in discussions comparing languages (generally on both sides) tend to drown out the higher-level insights that would probably be more useful given the low likelihood of succesfully convincing someone online that your language of choice is in fact superior in some way.

> The tradeoff here is that once something gets put into the language (or the standard library, since effectively they share the same compatibility concerns), you can't easily change it later.

That's another axis: it's how big should be the stdlib on a scale from Python to C.

E.g. Python is much closer to Rust than Go w.r.t. the complexity of the language, and it has a huge standard library like Go.

That's a fair point! I guess that's how you end up with three different versions of `urlib` and then still have some people go out of their way to use a different dependency like `requests`.

I've been writing exclusively Go professionally for six or seven years now so I think I'm qualified to contradict your experience

The types of problems I get hired to solve are messy, real world problems. There's not much that you can do with fancy abstractions when everything you deal with is a corner case, so explicitness is extremely appreciated.

I do find Go projects remain understandable even when they get large, and in my field -- distributed systems -- they are often used in tandem with a service oriented architecture that limits the size of any particular component, anyway.

I used to write Python. I don't miss it. Go keeps my coworkers from writing code that's too clever for me to understand, and keeps me from doing the same to my team.. and to myself, in the future.

> Go keeps my coworkers from writing code that's too clever for me to understand

Until someone whips out `import “reflect”`.

I’ve always found it confusing that people claim Go is simple when it contains runtime type reflection, which is hiding just under the surface of lots of the standard library like `json.Marshall`. Trying to explain to a new Go developer why []int isn’t assignable to []interface{} is always fun.

if you let people use reflect in non testing, that's on your reviewers and training.

How do you square that away with its use in the standard library, and many third party libraries? Someone’s gotta write the reflection code.

I’ve not worked with Go (although I did read The Go Programming Language), but use in a library is a different beast than use in an application. In Java-land (where I make my money these days), I would reject any pull request for application code that used reflection but at the same time, I happily use libraries that push reflection to its limits.

To take one common use case for reflection, Json marshalling/unmarshalling, if I were writing an application that needed to do this, and for some reason I could not use a library, I absolutely would not use reflection, but would write code that specifically targeted the classes that I was marshalling/unmarshalling. Conversely, if I’m writing a library, I don’t know what those classes are so I must use reflection to manage this. That’s the key difference here.

You aren't writing std lib.

So Go only keeps your coworkers from writing code that's too clever for you to understand if you don't let them write certain kinds of code? But then Go isn't doing anything, and it's you who's keeping your coworkers from writing code that's too clever for you to understand.

People can write bad code in any language if you let them. Film at 11.

Right, that's my point. I'm trying to refute the claim that Go is somehow an exception to that rule.

Go can be better at this without being perfect at it. No one worth talking to would claim go prevents all bad or confusing code.

If you're using `json.Marshal`, you're using `reflect` [0]. It's slow and it's an absolute gold mine for runtime errors, but sometimes it's the best tool for the job.

[0] https://cs.opensource.google/go/go/+/refs/tags/go1.19.5:src/...

Are there alternatives ? I thought everybody was using the go stdlib for json marshalling..

reflect is *ubiquitous* in go code, though. It's just barely hidden under many of the most commonly used standard library functions: like those in the encoding and error packages, for example. It's like Rust's "unsafe": the admonition is "don't use it", yet even a cursory audit of popular Rust crates shows that "unsafe" is everywhere.

Why isn't []int assignable to []interface{}? It's 6am and my brain hasn't kicked on yet.

They have different runtime representations. []interface{} is a slice of fat pointers to interfaces.

One of the best things I like about Go projects is that I can jump in at any state and it’s easy to reason about it. A project with one person working in a silo doesn’t look much different than a project with 5 contributors.

You can look at any of HashiCorp’s old projects to test this hypothesis. Vault, Nomad, Terraform, and Consul are all over 7 years old at this point. With the exception of perhaps Terraform they’re fairly monolithic as well: significant network services that have steadily accreted features for almost a decade.

I’ve worked on Nomad and so am far too biased for my opinion to carry much weight but: Nomad and Consul share a lot of code structure so I find both fairly trivial to navigate and find what I’m looking for most of the time.

I believe there’s always a cost to managing the complexity and the complexity never diminishes. It depends on whether you are efficient at managing it that way or another. Go doesn’t give you many tools to control it but forces you to certain behavior while developing the code. If you are strict about your code structure and the use of certain perhaps untypical design patterns, then you’ll be fine when the code base grows large. There are well-managed C projects that thrive. But they solve specific problems and to them they do lend well. For other kinds of projects the cost of managing the complexity that way might become prohibitive. Go is well-suited for such problems that the HashiCorp stack solves. But Vagrant has a Ruby code base. Many similar tools were written in Python. Gentoo Linux package manager is Python. Homebrew is Ruby.

The complexity of your specific problem distributes itself unevenly across all knobs and bolts of the development process. Some teams tend to manage Python code bases more efficiently, while others might prefer C++ over Rust. Some languages have libraries available that take away a lot of complexity from your immediate control by solving some part of your problem—you delegate it in the hope that it’s managed properly over there.

Hashi repos was my go-to place to study Go best practices and good patterns, but there are not that many places out there can pull off a large Go codebase without it being a complete mess. It requires a LOT of discipline and coordination.

People who claim that "you can learn Go in a couple of days and just run with it" have no idea what they are talking about. Writing Go is easy. Writing good Go is very hard.

My personal impression is that the Go fans simply assume that Rob Pike and Ken Thompson are language design gods and can do no wrong, but what I saw instead was language decisions and inconsistencies stuck in the decades past, incompatible with the complexities and scale of modern software development.

They are also overengineered and incredibly fragile. The HashiCorp stack has been an absolute nightmare to use at the company I work for.

I agree.

There are things about Go that are outstanding, like the ease of cross compilation and self contained static binaries making the development of CLI tools trivial.

However the language design itself is too rigid and inconsistent to allow for software engineering paradigms that even the community itself advocates for.

Without highly skilled software engineers at the start, my experience has been that Go projects tend to devolve into spaghetti reasonably quickly.

I feel there are a lot of similarities with the JavaScript ecosystem where we see a lot of bad advice in community posts that people feel passionate about.

I think Go was an innovative language back in the early 2010s when they started thinking of design patterns to improve the ergonomics of concurrency. Since then I have felt continually frustrated by how close it is to my perfect language but how they just keep missing the mark.

I still use it to write CLI tools though. I would use Rust more but it's annoying to cross compile (particularly for MacOS)

I agree with you. It's not about surface level complexity.

Some modern language complexity is abstraction that allow us more complexity while still being manageable.

You are spot on about "schemaless" databases.

I would also add "Patterns".

When the compiler doesn't provide enough features, the programmer has to do some of the work the compiler would do. This extra work are the software patterns.

Functions are a software pattern in assembler. They are a language feature in structured programming languages.

ADT are a software pattern in structured programming languages. ADT are a language feature in object-oriented programming languages.

And so on...

<rant>Having recently started writing Java once again, i am horrified at the mess that it has become. Between reactive streams, completable futures, guice wiring, it feels like voodoo. It’s hard to even reason which code is running synchronously and what is asynchronous. Not to mention the upcoming lightweight threads. </rant> I crave for the simplicity of go routines and explicitness.

Why would you need all of these things at the same time? That just sounds like incompetency on someone’s part.

I don’t think any language can prevent poor structure or poor design. And it certainly can’t prevent debt like parameter inflation (rather than refactoring layers, using encapsulation, etc.).

I think that the simplicity and explicitness actually help to make these kinds of flaws more obvious. This is probably better than hiding poor structure with clever language features. (I’m not saying that those features are always bad — Go is certainly missing some upsides from these — but they can also be used to mask deeper issues.)

In other words, Go’s simple language won’t stop you from seeing bad code, but hopefully means it’s easier to see and understand structure (and improve it?). Maybe the awfulness of a codebase is more a consequence of the team culture and history, but the language can influence how difficult it is to see the problems. I certainly think this would apply to C/C++ (with C being less powerful and harder to hide).

I think some languages are better suited than others for certain styles of code and specific kinds of software. Go’s syntax might appear simple as opposed to Scala say, but Go’s semantics have enough idiosyncrasies to seed a lot of bugs which an inexperienced gopher wouldn’t manage to detect even after all linters having been applied and the compiler being satisfied.

Considering older languages such as C++ and Java, the latter has several frameworks for web apps where a lot of complexity is opaque to the user as long as the user sticks to the defaults. For C++ there are few.

In either case, over time certain patterns of design emerge. Typical concepts such as dependency injection makes sense with some semantics but but less so with others, e.g., with Scala’s implicits, while still being applicable in another style of Scala. With Go, one can alter receivers on a per-package base.

The complexity never goes away, it’s always somewhere and there’s always some cost to managing it. With Spring, you pay with performance as long as you stick to the defaults and they don’t match exactly your model of execution. With Scala and Haskell, it’s on the type level and mostly implicit but the compiler has got more skin in the game and gets to help you a lot—you sort of ask the compiler to assist you more the more explicit you are about your types. With Go, the complexity is scattered and smeared across your code structure. And it’s on you to properly chase it. With generics it’s a bit simpler now. And abstractions are a boon in the hands of an experienced developer. And sometimes they really should be discovered and not imposed—depends on whether the problem is formulated beforehand or in the process of an agile cycle.

I think you’re painting with too broad a brush. Of course Go has some idiosyncrasies, but I think the number is fairly low because of the relatively small number of language features. With frameworks you’re still making a bunch of parts implicit for more expressivity, which is not something Go favors. Even the testing has a core philosophy of no magic assertions or frameworks, just regular code.

There are indeed trade-offs in terms of where complexity lives, but I would not say that with Go it is smeared across the code structure. That depends on design. However, some complexity is more explicit and apparent in the code itself, which I believe the language philosophy holds as a good thing (hidden complexity is worse than complexity). For example, the classic “if err := …; err != nil” is the complexity of error handling in your face. There’s no lovely “!” operator or exceptions to hide that away and produce a beautiful, minimal function. But exceptions are an obvious example of the danger of these kinds of features; they will hide all kinds of unexpected code paths and behaviors. The Go programmer is forced to deal with these things in a “dumb” way, but I think this ends up being beneficial in most cases.

I don't find this to be true. Go projects of a particular size are generally more comprehensible than Ruby projects of the same size, but that's _only_ because Go uses explicitly-declared typing. Large Ruby projects and large Go projects are both pretty terrible to try to understand.

Large Ruby projects are by the far the worst in my experience, far worse than Python, Java, C++, or JavaScript. So if Go is just as bad as Ruby than IMO you are agreeing with the parent, not disagreeing.

Of course team quality matters much more than language choice, so my experience will differ from others.

Go's allure is that is dead simple to get a basic http service off the ground: practically "hello world" level simple. Then complexity sets in. Go has the same problem with interfaces, mocks, and work arounds that enterprise Java does, for one thing. Then there's go's concurrency: deceptive simplicity is not good. Go makes it trivial to write concurrent code. Concurrent code that's resilient and efficient? Not so much. And with all the other little footguns and antipatterns/antifeatures in the language, it also makes it trivial to write regular code that is fragile and prone to error.

Rust has better features for programming "in the large" compared to Go, but they still require proper discipline and awareness to use. You simply can't entrust a large, complex project to a horde of code monkeys and cowboy coders, regardless of the language. Modularity boundaries must be part of the high-level design, either at the outset or refactored-in at some point as the project grows.

> No database is schemaless.

You can certainly have a database of JSON files without imposing any schema on them, apart from perhaps some form of id. Whether it makes sense is a different story.

That's only technically true. As soon as you need to implement anything beyond

    func (db* Database) GetEmployee(id int) (string, error)
    func (db* Database) SetEmployee(id int, value string) error

even just something like

    func (db* Database) ListByDepartment(departmentID int) ([]string, error)

You have some builtin assumptions about the shape of your data, i.e. a schema.

Nope. That's a problem of your code, not a schema on the database. You could have those functions return something optional, where a None is returned when the data doesn't conform to the assumed schema, and you're safe again. You could have cats and dogs and cars in your employee database and not run into problems.

In fact, this is how you have to work when you're dealing with large amounts of unstructured data.

> You could have those functions return something optional, where a None is returned when the data doesn't conform to the assumed schema

Again, you have a schema. It's just invisible and implicit, and you have no tools to manage, enforce, or deal with it.

If you define it like that, what's the point of the concept of schema at all?

When I say no schema, I mean the user has no control over what's in the data. They can query for employee id's, pet names, birthdays, etc., and get back meaningful data or just Nones.

Thinking about a schema this way is useful.

The big thing I find that strict type aficionados get wrong is that it is immensely useful in practice to be able to read data that your program only needs to understand a subset of, while still being able to reserialize it intact and pass it on.

It allows you to e.g. evolve systems in a backwards compatible way without having to update every single component in a pipeline in lockstep.

Most marshalling/unmarshalling systems can't do this.

Can you elaborate on which systems those are? Every one I've used so far can deal with incomplete types, either through a document-level or type-level escape hatch. For example, in Go, encoding/json has an option to DisallowUnknownFields that even defaults to false. And even if you enable that, there's the option of soaking up unknown object keys into a map[string]any member field on the level of each individual struct type.

It depends. Sometimes the marshalling layer doesn't support it, because it's directly unserializing to a native struct via codegen. Often the app 's other types are too rigid to carry extra hierarchical metadata along even if you did unserialize it. And often it's the devs themselves that are averse to anything not rigidly typed or capable of inconsistent or incomplete states, because it's less pure or ergonomic... even though being able to store an incomplete record as a draft is an affordance everyone needs.

ie. doesn't matter if Go can unserialize like this if the devs on your team hate the idea

Extra parameters is the complaint you come up with? That happens across all languages.

Copy paste? Again all languages.

You are complaining about the authors not the programming language.

I am very, very sorry I didn't exhaustively enumerate every possible way I've seen large golang projects become unmaintainable?

You could write unmaintainable code in any language. Rust have more opportunities for it than for Go, C++ has even more of them.