Go Is a Well-Designed Language

https://mattjhall.co.uk/posts/go-is-well-designed-actually.html

by PaulHoule • 1 year ago

71 186 1 year ago

mattjhall.co.uk

What “sorta just happened” is Swift 6. I knew Swift, I loved Swift. Swift designed itself right away from what I was willing to put up with anymore.

Go in comparison seems unnecessarily pedantic, occasionally too verbose, and occasionally unnecessarily terse. But it never makes me lolsob minus the lol

rob74• 1 year ago

Swift designed itself right away from what I was willing to put up with anymore.

I swear I can't tell if this phrase is supposed to be positive or negative? Then again, I'm not a native speaker...

UltraSane2• 1 year ago

This feels like SAT/ACT reading comprehension question! I think that "But it never makes me lolsob minus the lol" means he meant he doesn't like the changes Swift 6 made.

cageface• 1 year ago

I think SwiftUI is to blame. In order to make a nice terse DSL for WWDC talks they really contorted the language design.

jrimbault• 1 year ago

Where you see a hack I see an elegant design.

https://groups.google.com/g/golang-dev/c/r4rdPdsH1Fg/m/JG3Wl...

I can think of two examples of major aesthetic shifts in Go code that seemed ugly at the time but were adopted because they simplified software engineering and now look completely natural.

https://research.swtch.com/vgo-principles

type Duration int64

https://github.com/golang/go/blob/519c0a2323700934cbec97b75d...

default values

https://gotipplay.golang.org/p/jS6wwznSR7F

noelwelsh2• 1 year ago

I feel this article misses the point in many cases. Take, for example, error handling. It's labourious in Go, but that's not the only issue. I'm not going to go into all the details in this comment (others have covered this at length) but:

1. Go's error handling has four possible cases (result and no error, no result and error, result and error, no result and no error) when only two make sense.

2. A consequence of the above is that it requires null values (nil in Go)

I don't see how this can be considered good design.

9rx13• 1 year ago

Go's error handling has four possible cases

If you consider (T, error) to be logically coupled, there is actually effectively an infinite number of cases. (T, U, error), (T, U, V, error), (T, U, V, W, error), etc. Although I suspect this take is suffering from trying to project idioms from another language onto Go.

catlifeonmars2• 1 year ago

(T, error) is just a special case of (T, E).

Zanfa• 1 year ago

1. Go's error handling has four possible cases (result and no error, no result and error, result and error, no result and no error) when only two make sense.

A partial success, that returns both a result and an error definitely makes sense. For example, you’re streaming data over a network, receive some bytes, but get disconnected before it’s complete. It would make sense to have both the data received so far as well as the error, in order to resume.

I’m sure there’s an appropriate situation for the 4th case as well.

WolfCop• 1 year ago

Streaming data, there was no error but also no new data available.

murderfs• 1 year ago

Does it make sense for every function to have those four cases, though?

guappa10• 1 year ago

Your example doesn't make sense because that's not how the syscall works.

gr3ml1n• 1 year ago

I can think of situations where all four make sense. Not sure what you mean?

result+no error: data returned, no error happened. - Typical function call where you want some data.

no Result+error: nothing to return, error happened. - That typical call failed.

result+error: partial result, up to error. - Wrote x bytes to disk, then ran out of space.

no result+no error: nothing to return, no error. - Data for a passed query. Nothing came back, but that's not an error.

nejsjsjsbsb2• 1 year ago

But not every situation. Make illegal state unreprestable is a good ideal.

Animats• 1 year ago

Go is an OK language, and that's the point. An average programmer can write web services in Go without too much trouble.

Goroutines mean the programmer doesn't have to struggle to avoid blocking, or decide what should be "sync" and what should be "async".

Garbage collection means the programmer doesn't have to think much about ownership.

The error handling is a bit verbose. If Go had generics from the beginning, it could have benefited from something like Rust's Result type and "?" operator. That's effectively the same thing as Go's usual error handling, but more concise.

9rx13• 1 year ago

and "?" operator.

To be fair, Go almost go the "?" operator like Rust. The proposal was well received. It wasn't the lack of "Result" that held it back, it was that nobody could figure out how to deal with the handling problem. It's not entirely clear what the Rust-equivalent is for all the other moving pieces associated with "?" (e.g. its defined traits). The latest "?" proposal forces a handling body on each use to address that issue. But at that point all you've done is added another way to write "if". Is that a win?

theoryofx5• 1 year ago

The criticism that Go is for "average programmers" almost universally comes from people overestimating how good they are.

I've worked directly with hundreds of highly paid programmers over decades. I can count on my fingers the number that would be at all constrained by using Go where it's a suitable choice (an important caveat).

The rest would have their work highly improved by using Go as much as possible, precisely because it's harder to write bad code in Go compared with most languages.

stouset4• 1 year ago

it's harder to write bad code in Go compared with most languages

I have worked in many, many codebases and I just can’t say I agree. There are some ways in which go programmers don’t write code as badly as they might have in other ecosystems, but there are plenty of other ways in which they’re actively encouraged to by the language.

And it’s not particularly maintainable. Yes, I can always “just read the code” to figure out what something is doing. But I often have to read more than five times the amount of code to understand what’s being accomplished. On top of that, due to the lack of abstraction power, I have to mentally decompile algorithmic implementations into the actual high-level task they’re actually performing. The (minor, but obvious and) classic example is having to mentally parse every single loop to determine if it’s a map, a reduce, filter, or something else.

usrnm4• 1 year ago

Adding an element to a nil slice works, but adding an element to a nil map panics. time.Time uses its own epoch incompatible with anything else. defers are function-scoped instead of block-scoped. The list goes on, these are just the first ones that came to my mind. And they are not some magical tradeoffs, they are just poor choices. I like go, but no, it is not well-designed

mirekrusin• 1 year ago

Also missing null safety in modern language is weird.

physicsguy5• 1 year ago

And enums.

xarope• 1 year ago

I got caught with maps initially, and had to question why everything else was just "var x string", which also gives it a value, but maps needed a "var x = make(make[string]string)", otherwise on first assignment it panics.

There's a good explanation somewhere, ah here it is: https://go.dev/blog/maps

But you get used to it, and move on, especially with the sort of TDD workflow that go test encourages

usrnm4• 1 year ago

I know why it works the way it works, it doesn't make it a good design, which is the point of this discussion

q3k• 1 year ago

time.Time uses its own epoch incompatible with anything else.

Could you please elaborate?

theoryofx5• 1 year ago

time.Time uses its own epoch internally but has methods like .Unix() which convert to Unix epoch time. Never seen this be a problem.

indulona• 1 year ago

i think he means that internally, time objects simply use unix nano and the location dictates the offset. since it is internal thing, not sure why that is relevant.

roncesvalles7• 1 year ago

I don't think that's weird. You can only append to a slice using the `append` built-in function. `append` may initialize and return a new slice at any call. It would be weird for it to not do so when passed a nil slice.

usrnm4• 1 year ago

Adding elements to a map allocates memory and moves stuff all the time under the hood, it's no different from append. If panicking on nil is weird for append, it's just as weird for maps

shakiXBT• 1 year ago

If language specific quirks lead to a language being "not well-designed", how many languages do you think are actually well-designed (if any)?

oconnor663• 1 year ago

defers are function-scoped instead of block-scoped.

I think this is a basic tradeoff with defer and not a problem per se. Are users more likely to need to clean up resources every time through a loop, or more likely to acquire resources that outlive the loop? And which is more confusing if you expected the other? I think it's a tough call. (I understand why a systems programming language would insist on block scoping to avoid allocating.)

cle• 1 year ago

Why are they poor choices? What tradeoffs are they making?

I can't really evaluate/judge them without understanding that first.

kgf1980• 1 year ago

I’m not a coder day-to-day (I was in the past, mainly C#) but I still write toy stuff to make my life easier, and the stuff I write in Go I’m more likely to be able to return to a year later and be able to quickly understand what I was doing, why I was doing it and fix/enhance what I need to.

prisenco• 1 year ago

The readability of Go is why I defend it all day every day.

The fact that a programmer with no Go experience can look at a codebase and quickly get a sense of what's going on is a massive advantage for large teams, code handoffs or long term maintainability.

Go is nobody's favorite language but that's why it's my favorite language.

LtWorf4• 1 year ago

can look at a codebase and quickly get a sense of what's going on

I don't even need to look. Error checking is going on :D

WesBrownSQL• 1 year ago

100% this one of the big reasons I fell in love with go. Single executable, no runtime stuff to install and crazy portable. I can look at anyone's go code and very quickly get up to speed. I don't worry about how they format it. Patterns are pretty universal which makes it easier. Does it have its warts? Oh, you better believe it but I know that any code base I go through will pretty much have the same warts the same way. Does go fit every need? Nope on that front too but man its pretty good and what it was designed to do.

oldpersonintx• 1 year ago

Go and Python are both firmly rooted in anti-cleverness

Cleverness makes for macho code golfing and aha moments in small codebases

Cleverness makes you quit your job when the codebases pass 10k lines

KronisLV4• 1 year ago

Not sure why this was flagged.

Cleverness makes you quit your job when the codebases pass 10k lines

I've very much felt that in codebases that are hundreds of thousands of lines of code.

Essentially it becomes: "Is it easier to track down this bug and fix it over a week or two (hopefully the solution isn't needed by tomorrow night), or is it easier to quit my job?"

Sometimes the answer unironically is the second option.

theshrike792• 1 year ago

I always say that you can write clever code on your free time.

When on the clock, make stuff that's readable and easy to manage.

guappa10• 1 year ago

make stuff that's readable and easy to manage.

So, not go.

guappa10• 1 year ago

Go is rooted in: "let's make a language with managed memory that still manages to crash with memory errors".

They should have hired someone that knew what he was doing.

desumeku2• 1 year ago

If you think that Go's creators "didn't know what they were doing" then I sure hope you exclusively run Windows, and not Unix, UTF-8, nor use anything else they had a hand in, like the JVM or the C programming language. In fact, you might as well just stop using computers considering how important Go's creators are in this industry. Clearly if they can't be trusted, nothing can.

pjmlp8• 1 year ago

That is funny, Python gets as clever as C++ and Common Lisp, those unaware of it aren't really reading Python docs.

saghm• 1 year ago

If you see a function call in Go you know there is one definition you need to check.

...unless it's a method on an interface type. I get the point being made about overloading, but the above statement of it is a bit too strong.

egeozcan• 1 year ago

I like Go, I like TypeScript, and I like C.

All of them have significant design flaws and quirks, many of which people here write pages of complaints about. But in most cases, it's easy to learn how to avoid them (granted, that's more of a stretch for C, but plenty of people manage, and that's enough).

I'm not against pointing out issues, especially for actively developed languages like Go. However, it's important not to turn criticism into bashing the language or the people using it. That just comes off as snobbish and isn't constructive.

Each of these languages is well-designed for specific needs, and not so much for others. And that's okay.

I think people mostly try to scare others away from using these technologies to push something they believe is better. But instead of that, you could perhaps write a competing article praising and comparing your favorite stack and that would be much more useful, in my opinion.

grey-area• 1 year ago

I wish more people thought this way. Why does the language you choose have to be your religion and lifestyle, when it’s just a tool? They all have flaws and areas they are useful in.

newdee• 1 year ago

People do this with all sorts of things, but ultimately want validation that they made the “right” choice. At least that’s the most charitable assumption I can make.

pjmlp8• 1 year ago

For many folks, because it means which kind of job they are able to land, with which people they hang around at least 8h a day, what they talk about, to which conferences they go if any, and so on.

kerkeslager8• 1 year ago

It's one thing to say these are decent tools, but to say something is well designed is a much more specific claim.

I have some fondness for C, but I would not say it is well designed compared to modern alternatives. The reason I use it is largely portability which is more a function of its age and ubiquity than its design. You can of course make the argument that it was well-designed compared to the languages of the time when it was designed, and I don't really know enough to disagree with you there.

TypeScript, I will say, I think is actually very well-designed. It has it's problems but it's a massive step forward from anything that existed before it.

I think people mostly try to scare others away from using these technologies to push something they believe is better. But instead of that, you could perhaps write a competing article praising and comparing your favorite stack and that would be much more useful, in my opinion.

Strong disagree. Polyanna programming where we pretend all the tools in the world are so great results in horrible codebases, and then the programmer who thinks every tool is awesome becomes frustrated, doesn't know why, and moves on blissfully to a new project/company where they begin to plant the seeds of chaos anew. But someone has to deal with that crap codebase they left behind, and at this point in my career that person is often me. Work on codebases for more than a few years and the only way to stay sane is to recognize problems in code so that they can be fixed before they become bigger problems, and doing that requires you to be critical.

Working on a team, the biggest uphill battle is often preventing people from inserting every random tool they get excited about. Usually it's libraries, not languages, that are the problem, but I've seen both.

jillesvangurp• 1 year ago

I encounter a lot of different software stacks when helping clients as a consultant. Consultancy is something I do next to my main job which is being a CTO of a small, bootstrapped startup. That sounds like a posh job but what it really means is that I do most of the technical work together with one other person.

I've always been opinionated about tools and languages. And we probably all have our biases and preferences. What I've realized doing consultancy is that it's rarely advisable for me to tell my clients to change whatever the hell they are doing. It's actively harmful to do so. And I encounter pretty much everything you can name. Including Go.

At the same time, it's taught me to steer clear of certain tech stacks for my own things. I know I don't like them by virtue of having seen others do things with them. Go, is one of those things that's arguably alright and widely used. But I wouldn't prefer it based on what I've seen.

The reasons are mostly non technical:

1) it's a transition language for people. They might start with something like Javascript or python and they might crave something a bit more rigorous. Go is an easy choice. It's there, it's widely used. It has great libraries, and so on. But I've seen people progress to other languages as well. It's a phase people go through as they develop themselves. And there's a definite "if you have hammer, every problem looks like a nail" thing going on with it. For me Go would be a step backwards, not forwards. I have some languages I'm interested in learning. Go is not one of them.

2) it's a Google language and Google has this big "not invented here" syndrome that often translates into them reinventing wheels. In this case C++. They embarked on their journey around the same time several other languages kicked off. Rust, Swift, Kotlin, etc. all emerged roughly around the same time (15-20 years ago). Swift is Apple's language and it suffers from the same issue. So, even though Google's take on this is interesting. It's not the only one or necessarily the best one (subjective of course). Rust and Kotlin are a bit less tied to one company. And both are widely used across most/all big tech companies and less entrenched in just one of them. Full disclosure, I prefer Kotlin out of these languages and actually use it for a lot of things people might think Go is good at.

3) It's a conservative language community. Despite being relatively new, the community seems to resist change a lot. Endless debates about exception handling, package management, generics, etc. and other aspects of the language seem to progress at a snails pace with people bickering endlessly about whether that's good or bad design. That stuff just bores me. Just fix it already. I don't want to read/hear endless reasons why something cannot/must not/should not be a thing because reasons that boil down "we don't like change".

So, no Go for me. But some of my clients use it and it's of course fine for them. I consult them on what they should build, not how to build it. A lot of that stuff works just about the same regardless of the language. Use what works for you, what you are familiar with, etc. Not what others tell you to use.

KronisLV4• 1 year ago

I think Go is a pretty good choice for getting something out the door quickly, without getting in the way too much.

The other week, I was working on two APIs: one for a team that uses Java primarily and another where I was free to pick the technology as needed and was looking in the direction of making it easy to deploy, even without containers, where I picked Go.

With Go's standard library (and a few packages here or there), I had something up and running within a few days and it mostly just worked. Things that I wanted to do were just an additional method away, which, while not as sophisticated as the various convention over configuration options out there, kept everything very discoverable and observable.

With Java, I had to setup a Spring Boot project and its security configuration mechanism (SecurityFilterChain, WebSecurityFilterConfig and lots of Filter implementations) and ran into issues where calculating file checksums for uploaded files broke because Files.exists() returned that files exist for ones with UTF-8 symbols in the name, whereas internally FileUtils.checksumCRC32() used file.isFile() which returned false. Then, I also needed -Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8 and for another mechanism had to look into JCE briefly, as well as configuring Maven to push packages to Nexus, as well as how to disable Spring Boot trying to connect to PostgreSQL and RabbitMQ while bringing up the app context for tests, or to connect to a special instance for tests (and hopefully eventually figure out how to automate a separate schema per CI run). Oh also deciding between OkHttp and Apache HttpComponents. Oh and also adding Apache Tika to the project, yet realizing that I can't add tika-parsers-standard due to some related dependencies.

Now, this isn't a completely fair comparison because the APIs didn't need to do 1:1 the same things and I could have chosen not to go with Spring Boot, but it's so entrenched that it's most likely the majority of projects that you'll see out there (I also like Dropwizard, but I haven't seen many people use it at all). That might sour some people's perception of using that language professionally: https://earthly.dev/blog/brown-green-language/

There are things about Go that are annoying, but it not having all of those levels of abstraction that you need to think about was comparably nicer. Plus, not needing to think about JDK versions and instead just getting a single file that you can ship. Oh, and on a related note, projects like Wails are also really nice (I tried Tauri, the builds were too long and the Electron bundles are a bit too big for my needs in some other projects): https://wails.io/

I like many of the languages out there (even Java and ones like .NET) but the projects and ecosystems around them can make them harder to use sometimes.

oftenwrong3• 1 year ago

You were certainly bitten by the Java ecosystem, but I would agree that you hold some responsibility. Adopting Spring Boot so casually is really quite questionable. It's essentially opting to build your application within a giant, bonkers codebase. In the golang community there is a held value of using the standard library and tools, which is helped those being very good. I would suggest that Java is a better experience if you follow that same approach. If you want to serve HTTP, use the jdk.httpserver module. If you want to make HTTP requests, use java.net.http. If you want to interact with the filesystem, use java.nio.file. To build, use the included tools in the JDK. When it comes to cases where a third party dependency is warranted, such as use cases for Tika, you will have to deal with some questionable design decisions, but it's much easier when you have just a few libraries that you use by hand, and no insane framework trying to stitch everything together for you. For getting those dependencies, you are going to be acquiring them from public maven repositories, but I would suggest using Coursier or Maven Resolver instead of actually using Maven.

KronisLV4• 1 year ago

Adopting Spring Boot so casually is really quite questionable.

The thing is, you don't always get that choice, at least in a way that wouldn't generate much opposition. If Spring Boot is what people use in most of the projects, opting for something else would generate lots of questions about that "inconsistency", especially as a part of the same team/project where services already exist that are written with it.

Same as not opting for ASP.NET with .NET, Laravel with PHP, Django with Python, Ruby on Rails, Express.js with Node.js and so on. Same as for picking .NET in a "Java shop" or Java in a ".NET shop" or even wanting to use Vue when most other projects are made with React etc. I'm not saying that Spring Boot is always the right choice (god no, honestly everything from Dropwizard to the likes of Javalin and Quarkus etc. have their use cases), just that you'd have to be able to make that choice yourself in the first place, which isn't always the case.

Same for Tika and other dependencies, which are often necessary evils: if you need to handle files and get their MIME types, will you just estimate what a file could be by looking at its extension, or do you actually want to look at the contents? And if you look at the contents, will you attempt the lazier approach ("Huh, this is an MS Office container type, no idea what's inside of it") or will you actually look for something more accurate ("Oh hey, this is an MS Office container type, with a Word document inside of it")? Then it becomes, do you want to spend the time reinventing that yourself or just have it done by the end of the day with an external dependency?

Not that Go is immune from that, you'd still probably want to just use https://github.com/gabriel-vasile/mimetype instead of building your own.

Aside from that, it's nice that Go isn't so "enterprise" oriented (yet?) and that the standard library is so strong (whereas Java only got a built in server around JDK 21 IIRC).

Edit: oh, also on my silly little list of jagged edges of Java, there's also the whole JUL, Log4j, Apache Commons Logging, Logback and SLF4J situation, whereas Go just has https://pkg.go.dev/log and it's nice. Not a horrible indictment or anything, I still use Java more or less daily, alongside other languages.

pjmlp8• 1 year ago

To me it looks like more lack of familiarity with Java.

Having used Java and .NET ecosystem since their early days to this day, I fail to see why the team wasn't able to deliver in the same timeframe, also Spring Boot isn't the answer for everything.

KronisLV4• 1 year ago

Things got delivered anyways, it's just that Java had more bumps in the road than Go. Not necessarily something that reflects on the language itself as much as it does on the ecosystem around it (and its age), as well as how it's often used. Give it a decade, one day Go developers will also know the joys of https://balusc.omnifaces.org/2015/10/the-empty-string-madnes... and the likes.

AlgebraFox• 1 year ago

No matter how many blog posts try to justify Go, it is a lost ship. Yes it is used by many companies (I still don't understand why), but that does not make it a well designed language.

But secondly designing errors as explicit values has been a trend-(re)setter. Go, Rust and Zig have all chosen to use this approach.

Just because Go treats errors as values, you can't compare Go's error handling with Rust's. Rust provides clean abstractions with Algebraic Data Types, ? operator over Result type to reduce polluting code with if-else nonsense in every single function. I bet atleast 30% of Go code in a project is error handling for the sake of handling.

Further Go's syntax inconsistency irritates me more. I still don't understand if I should put a comma or semicolon or nothing between members in a struct definition. Also

a := 10

...

a := 20 // error. a is defined.

a, b := 20, 30 // accepted. why ??

api• 1 year ago

Go’s unreasonable success is due to Google but also its main feature: low up front cognitive load.

A lot of that is from lack of async, or rather that async is hidden behind go routines.

catlifeonmars2• 1 year ago

A lot of that is from lack of async, or rather that async is hidden behind go routines.

That’s an interesting take, but one that I’ve seen in multiple places in this thread. I find that introducing goroutines into a program immediately increases the cognitive load as now you need to think about joining, data races, and need to think about error handling differently (golang.org/x/sync/errgroup is an excellent library by the way).

Oh and did I mention deadlocks?

fullstackchris4• 1 year ago

So are you saying you would take on the initial cognitive load of Rust vs. Go for _every_ project?

theThree2• 1 year ago

a, b := 20, 30 // accepted. why ??

I guess it is a dept of error handling. Otherwise you have to write "foo,err1 := Foo();bar,err2 := Bar(),.."

guappa10• 1 year ago

My company has 2 teams that use go for different reasons:

* Easy to crossbuild and you distribute a single executable (although of course someone managed to pull some dependency that was dynamically loaded and made our CLI depending on a running Gnome session)

* C developers who can't write C code that doesn't segfault every 3 minutes (because they never understood how threads work) can still have their ego but also produce somewhat useful code.

ninetyninenine17• 1 year ago

I hate go. Specifically I hate go packages. It was poorly designed. Any time you create a package in go you can’t have circular dependencies. Which makes sense right? When you make a package in rust or node or python those packages can’t have circular dependencies.

If you have two files in go or any other language, circular dependencies are usually permitted which also makes sense. It’s only packages that don’t permit this.

But guess what? You create a package in go simply by putting everything in a folder. So people when writing a go project they often make dozens of packages just by the is ocd need of organizing things into folders.

But when you organize things into folders the files in those folders aren’t project files anymore. They are different packages and you can’t have circular dependencies.

And that’s a big problem as this design conflicts with programmer instincts on how to organize things.

We organize things by meaning and name and subject matter. But simply using folders in go we are forced to organize things via dependencies and this causes a clash and makes organizing things 10 times harder than it should be in go.

Imagine I have a chicken and an egg. Chicken goes in the animal package and egg goes in the food package. It is now fundamentally impossible to make a chicken lay an egg and an egg hatch a chicken at the same time. Our tendencies to organize things via meaning has clashed with this requirement of organizing things via dependencies.

Does it make any sense at all? We probably don’t want packages to be interdependent in this way. But the stupid thing is just be creating a freaking folder we create this problem in go and it doesn’t make sense because if the files are outside of a folder you don’t hit this problem.

I would say go is actually poorly designed. I can’t think of any popular language that has this strange inconsistent problem.

It actually causes huge headaches in organizing things in go but idiot developers when they hit this circular dependency problem they literally believe the documentation when it tells them that they aren’t organizing things correctly and they need to think harder about design. So in a lot of go shops they spend an inordinate amount of time naming folders and organizing shit just to get their ocd need of organizing things by name to jive with gos requirement to organize things by dependency.

In the real world things can be in different categories and also interdependent at the same time. Go’s universe doesn’t allow this.

I’m here to tell you that It does make sense to put eggs in the food folder and chickens in the animal folder. Go is just stupid in this area, not you. Don’t believe the idiot who wrote that in the docs.

9rx13• 1 year ago

Imagine I have a chicken and an egg. Chicken goes in the animal package and egg goes in the food package. It is now fundamentally impossible to make a chicken lay an egg and an egg hatch a chicken at the same time.

I am familiar with people eating unfertilized eggs. I am even familiar with balut. But I am not familiar with the delicacy of eating an egg as it hatches. If you eat an egg as it hatches, wouldn't that actually be eating a chick (the chicken) rather than an egg?

I suspect the real problem here is that your domain model is ill-conceived. In fact, while Go has no lack of faults, I suspect the vast majority of the complaints directed towards it come down to the limited feature set not enabling papering over bad design decisions.

fullstackchris4• 1 year ago

I've been writing Go for about 5 years now and can confirm cicular dependency issues were typically handled buy a small refactor or considering where the borders of the domain should _really_ be

ninetyninenine17• 1 year ago

Your joking. I have a hundred food items and a hundred animal items. Cows produce milk. Chickens produce eggs. Eggs produce chickens.

It makes 100 percent sense to make two folders. Food and animals.

‘I suspect your “domain model” is ill conceived’??? You buy into that? Don’t follow what those idiots tell you.

You realize that we use these actual separations between food and animals in the real world? And now because of some design philosophy the domain model is ill conceived? The result is a more convoluted domain model to make things flow.

Actually I think this is an easier way to explain it to you. The “domain model” or aka categorization of food and animals works in reality and every other language because it’s not a bad design decision. The reason why it doesn’t work in go is because go is the bad design decision.

jrockway2• 1 year ago

This bothers me from time to time. When I first started using Go, I think I complained to the Go team about it. They told me to think more carefully about where package boundaries are. Having the smallest package possible doesn't necessarily mean the design is good.

I inherited an app from a coworker, and he just put every file in the main package. This was actually fine and caused no problems.

These days, I still have an addiction to making tiny packages, which the Go team would likely not approve. But I'm a big girl and I do what I want! The workarounds I use are:

1) A `types` package. type Chicken struct { Children []Egg }; type Egg struct { Mom, Dad Chicken }.

2) A `utils` package. Let me explain. I would never name a package `utils`. That's illegal and I'm told that the compiler will explode into a thousand pieces if you try. All the king's horses and all the king's men wouldn't be able to put it back together again. So don't test it. Just trust me. But, you can definitely have something like `package hatchery` with a functions related to collecting eggs from chickens. Or you can have `package eggutil` for packing eggs, frying eggs, and shipping eggs.

I would say that I typically have a `types` package (called `types` if I'm hand-writing the code, or myapppb if it's protobufs like at Google), and then structure the rest of my app as model/view/controller. The model puts these types into the database. (Call it `eggdb`.) The controller does whatever business logic you care about (getting chickens together to fertilize eggs, call it `husbandry`). The view calls into the controller to implement your API / gRPC endpoint / beautiful Gtk+ GUI / whatever.

And then you don't really have problems with circular dependencies.

Having said all that if someone puts it all in main.go I'd probably approve the PR. The Go team let my coworker do it in 2014 and nobody died.

ninetyninenine17• 1 year ago

You’re not seeing the problem. You spend an inordinate amount of time trying to organize it and you come up with an elegant way so the catharsis of that solution makes you think you found the path to nirvana. Really you’ve been duped.

This restriction makes sense for packages. But not for folders. The problem arises in go because folders and packages are the same thing and that’s stupid because people don’t typically use folders as if they were packages. Folders are typically used just to categorize things of similar meaning or naming or whatever you want.

No other popular language has this issue. I can choose to organize things how I want in any other language. I have the freedom. I can make a folder A and B and C and D and just organize things in ABC order. But can’t with go. If I dont want to do this in any other language I have the option to create a package.

Creating a package and creating a folder are completely orthogonal tools and concepts and the genius who invented go just made a horrible design decision here.

roncesvalles7• 1 year ago

This is solved simply by having a chicken.go and an egg.go in the same package.

Go appears to encourage large source files, since it allows you to define multiple "classes" (types with methods) within the same file. This is probably intentional to combat the complexity of having otherwise cohesive logic littered across several small files in OOP-first languages.

But I like your example and get your point. What if chicken.go and egg.go diverged a few levels earlier in the dir path. All the Go repos that I've seen in production have very flat folder structures, so I guess this is just how Go is written.

ninetyninenine17• 1 year ago

I joined a company who wanted really clean code in their code base. That meant really good categorical organization of things into folders based off of semantic meaning about what those primitives did. You can imagine the nightmare that caused.

People simply just didn't understand what I was saying that there was no inherent meaning in trying to make our naming conventions with folders work with go's dependency rules. They thought the work of untangling all the dependencies, folders and the naming was some quest towards a perfect design.

You can also see in this thread, that a lot of people debating the issue with me believe the same thing. They think this arbitrary rule is speaking to a fundamental design axiom and they use big words to call it "domain modelling"

pjmlp8• 1 year ago

For me it starts with allowing only source code packages, followed by direct URLs to source code repos directly on the source files, instead of an indirect mechanism.

To be fair, Go modules provide such indirect mechanism, by rewriting source files, with redirection information, really? Yet another hack.

lordofgibbons2• 1 year ago

I used to love Go and its simplicity. It's still my least disliked backend language. But after more than a decade of using it nearly full time (but not exclusively), I've fallen out of love with it.

I want sum types. I want non-nullable types. I want enums (preferably, based on sum types).

I'm okay with the explicit error handling, but would be fine with Rust style error handling too.

Having these features would change the language so much that you'd probably want to re-implement the stdlib, so it probably won't happen.

Surprisingly though, while I absolutely love Go's concurrency model, being able to kick off new goroutines with a dedicated "go" keyword and special channel operators have not been a big deal at all. It's usually abstracted away by some library, or you set it up once in your application and never touch it again.

tankenmate2• 1 year ago

In my opinion your comments on Go concurrency misses a point, the fact that you do it once "and never touch it again" is a very very strong selling point, it probably means it was very well designed; not a weakness but a strength.

lordofgibbons2• 1 year ago

I didn't mean it's a weakness. I mean it's not as amazing of a selling point as it was made out to be when the language first came out.

If you're using something only rarely and not touching it again, there isn't much of a difference between go.New(func(){}) from some "go" package, and go func(){}.

To reiterate, I'm not against the "go" keyword. It's whatever ¯\_(ツ)_/¯

praptak• 1 year ago

But after more than a decade of using it nearly full time (but not exclusively), I've fallen out of love with it.

I believe this is true for anyone and any language. Spend a few years in a language on stuff that you have to do (which is the main differentiator between work and hobby projects) and two things happen: the benefits are taken for granted while the warts are magnified fivefold.

The corollary to this is the quote "I won't use something until you tell me why it sucks" (can't find source). If you use something long enough you know the ways it sucks. This makes your criticism more valuable than enthusiastic praise from a hobbyist.

lifthrasiir4• 1 year ago

Agree that the language has to be analyzed under the original design goals to be fair. Disagree that Go is definitely well-designed in that circumstance, however. A major weakness of this essay is that all perceived issues with Go have to be irrelevant to the original design goals, quite absurd if you think about that.

I would instead say that Go had big things right, while smaller things might be not as right---but not exactly "incorrect". For example explicit error handling is the big idea that Go got right, but both Rust and Zig did a lot to refine error handling experiences; comparing them with Go is just a non-starter.

kerkeslager8• 1 year ago

Agree that the language has to be analyzed under the original design goals to be fair.

I mean if you're analyzing languages in a void, I guess, but we're not. We're looking at languages as tools to solve programming programs. And almost nobody has the problems that Go was designed around, so the original design goals are kind of irrelevant.

I mean, how many of you have worked on a million line codebase? If you haven't, why would you care that compiling millions of lines quickly was a design goal for Go? Yes, smaller codebases are also faster to compile, but partial compilation works just fine for that in other languages.

lifthrasiir4• 1 year ago

I should note that I do see merits of "unfair" analyses, in fact they are probably as important as fair analyses. It's just that such analyses would inevitably cover what designers originally didn't even think of, so such analyses should ideally be considered sort of bonuses instead of main criticisms.

UltraSane2• 1 year ago

I enjoy writing Java and C# so much more than Go.

relistan• 1 year ago

Seems many people mistake “well-designed” to mean “perfect”. Read the article: he doesn’t claim that. No language is perfect, they are all trade offs.

Furthermore, it’s fine to not like the design. It might not be to your taste or your requirements. But that doesn’t mean it wasn’t well designed. I can point to lots of things that I don’t like the design of that work great for others.

Go is super productive, has a great ecosystem, has great concurrency, produces good machine code, compiles as fast as anything out there, has great tools, and is growing in popularity. Flaws? Of course. Perfect? No.

But, it’s well designed.

kerkeslager8• 1 year ago

No language is perfect, they are all trade offs.

Uh, no they're actually not. A tradeoff means you accept some downside and get some upside in return.

Initially go was designed without generics. The tradeoff here was you got a single pass compiler which was faster. Well, actually, you could have a single-pass compiler with backpatching, but I get it, that's hard. It's a crap tradeoff, but okay, I can accept it's a tradeoff. And everybody at the time said, "Go doesn't need generics, they complicate the language." So we casted our nested types in and out of object and lost all type safety in that code, but hey, tradeoffs.

Except everyone kinda realized it was a crap tradeoff and so `go generate` was proposed as a solution. In a 1984-esque revision of the past, suddenly, having a second pass is okay! Never mind how important it was that go is a single-pass compiler. Nevermind that this is basically macros with all their pitfalls. But now we can generate 3 different versions of the parameterized type, one for each nested type, so we get type safety. 2 passes, macros, downsides, type safety, upside, and a pretty big upside at that.

But, here's the problem: now you have two different systems that are used for doing a lot of the same things that don't interoperate with each other very well. And that's not a tradeoff, because there's no upside. It's not "I don't like this but it works great for others" because it doesn't work great for anyone. It's not a tradeoff, it's a side effect of having chosen wrong the first time.

And... now Go has generics. And yeah, generics aren't really a tradeoff, they're just obviously pretty good. But, now we've got 3 different systems for doing a lot of the same things, which again, don't interoperate all that well with each other.

And here's the thing: from a language design perspective, this was extremely obvious that Go was going to need generics. Generics are pretty much the clearest win from the ML-family languages which had already made it into C# and Java by the time Go was conceived. It's absurd that this feature wasn't included in Go from the beginning.

guappa10• 1 year ago

has a great ecosystem

A great ecosystem is one where there is good 1 library to do a thing and you just pick that one.

A bad ecosystem is one where there are 25 libraries to do some things and 0 to do some other things, and none of the 25 libraries are very good.

physicsguy5• 1 year ago

I feel like Go falls much into the latter category.

I needed to write some code recently that did DSP. There is not any equivalent for this like SciPy in Go that bundles together lots of the common DSP operations you need. There are lots of partial implementations in different libraries of for e.g. filters, all of which use different interfaces.

A lot of this I think is because of the lack of SIMD, you can't get brilliant performance out of the box with a Go implementation because the standard compiler doesn't support it.

stouset4• 1 year ago

“Well-designed” involves making good tradeoffs where the upsides are useful and the downsides have manageable workarounds.

Go certainly has its fair share of these.

Go also has countless own-goals where a serious concession was made with zero or almost-zero upside. I won’t repeat them here.

You can like go and you can feel that go is a productive language. But given the sheer number of outright mistakes which should have been avoided in the early days of the language’s design and which are now frozen for all eternity, you can’t in good faith call it well-designed.

zxvkhkxvdvbdxz• 1 year ago

If you want to add two days you can't just call Add(0 /years/, 0 /months/, 2 /days/), you need to use AddDate.

Sorry for nit-picking, but 2 days is a duration of time, and you can add one using Add, like this:

    t.Add(time.Hour * 24 * 2)

I agree about FFI being a weak point in go when you need to interact with other languages, but it can hopefully be mitigated by using tinygo, which is still being developed.

ben0x539• 1 year ago

Does this do what you want across/during DST switchover?

theshrike792• 1 year ago

What do you want to happen during a DST switchover in this case?

pjmlp8• 1 year ago

It looks like the arguments on Apple ecosystem when arguing for design faults as virtues, us are unable to understand without enlightenment, like we are holding it wrong, tablets don't need pens, don't understand keyboard design, ...

benatkin• 1 year ago

But don't say it wasn't (well) designed.

I’ll say that it isn’t well designed. I draw a line at treating an unused import as an error.

The creators of Go had opinions, and so do I. That’s how it works.

cdent• 1 year ago

From what I've seen, the people who complain about go's design are people who are more concerned about the ways in which it is not correct (by some definition) and less concerned about just getting stuff done.

I don't "like" go (or any other programming language), but I'm able to get more done in it in a shorter amount of time than any other language, the created thing consumes tiny amounts of resources, and most importantly when I _or anyone else_ goes back to change something weeks, months, years later it's easy to re-establish or gain contextual understanding.

taberiand• 1 year ago

I like go, and I use it to get stuff done. I'd be able to get stuff even more done with sum types and pattern matching and better generics and iterator tools and it's a shame Go doesn't have these things.

alkonaut2• 1 year ago

These were the first lines of Go I ever wrote 15 minutes ago, as a response to the claim that Go had working enums. This is the kind of thing that makes me itch. https://go.dev/play/p/MMPMh7_U81-

I think "being simple" doesn't necessarily mean "must have subtle sharp edges and papercuts everywhere". Just like javascript I think it falls into a pit of being superficially "low complexity" or "simple", but all the subtle gotchas and unhelpful tooling (The fact a compiler can't help me realize I had added an entry to the enum, but forgotten to update a name list just means the whole feature is no better than just plain ints that we had in C since before I was born).

guappa10• 1 year ago

I'm able to get more done in it in a shorter amount of time

That's because you know it better than other languages. It's certainly not a universal experience.

kerkeslager8• 1 year ago

I mean everything you just said about Go applies to Python except the "consumes tiny amounts of resources"--it's certainly my most productive language, and the code looks a lot like the pseudocode people write when they're trying to descrbe an algorithm so it's pretty dang easy to read. But you don't hear me going around claiming it's well-designed. Taking async design cues from f-ing JavaScript, leaning harder into the GIL, was a horrific mistake, for example.

oftenwrong3• 1 year ago

The error handling is explicit only in a limited way. As the author points out, you have to explicitly propagate an error condition, but you don't have to explicitly not-propagate it. Exceptions are reversed in this way: propagation is implicit, and not-propagating is explicit. I would prefer that handling is fully explicit in all cases, and not depend on supplemental linting or sheer discipline. It's a bit incongruous that golang compiler is so fussy about unused imports, but has nothing to say about silently ignored errors.

I also find that stack traces are generally more useful than plain wrapped errors. I want to know the code path in most cases where I am looking at an error.

More generally, it's disappointing that golang has so many idiosyncrasies given its philosophy of straightforwardness. I struggle to think of any useful, general purpose language that has fared better, though.

sirwhinesalot2• 1 year ago

Go is not well-designed because it is simple. It is poorly designed because it fails to be so. All the weird interactions with nil for example.

tankenmate2• 1 year ago

There is a whole raft of ways to deal with nil, 0, NULL, NaN, etc. And of course different languages do it differently, primarily because of different requirements and/or aesthetics. Just because you don't you don't agree with the choices doesn't mean it isn't well designed, if it achieves the goals set forth then it is well designed. Disagreeing with the goals is a different (although related) issue.

sirwhinesalot2• 1 year ago

It has nothing to do with aesthetics why you can add to a nil array but not to a nil map. That's pure jank.

pjdkoch• 1 year ago

ITT: apologists and haters.

Go is a bunch of preferences and aesthetics. It clearly appeals to a bunch of folks, others have a hard time putting up with it.

Everyone is free to both love and/or hate go. The language's spirit is not going to change. I'd much rather see more realism, honesty, and acceptance. Instead, this class of discussions always seems to become incessant "no u" ping-ponging.

Certainly not what I'd consider curiosity and critical thinking.

colonial• 1 year ago

I wanted to like Go, but I could never shake the feeling that it was "just" a marginally better C. The runtime and tooling is excellent, yes, but the fact that it eschews obvious advancements since the 1970s (e.g. enums with actual type system backing, iterators until recently...) does, in fact, scream "poor design" to me.

Go Is a Well-Designed Language

Related Stories