Ten years of “Go: The good, the bad, and the meh” (opens in new tab)

Go really is great. There was a big argument around a new project we were starting whether to do Go or Clojure.

What we did to settle the debate was to ask an entry level dev that was just starting if he was interesting in writing two sample applications in each language, having known nothing of either. Nothing complicated but touched enough points (HTTP endpoints, database interaction)

A full day later was still trying to get the Clojure app working correctly.

He finished up the Go one in like an hour.

Since then we've brought new devs on with zero Go experience and they are up writing good code in a day. I can't imagine where we would be if we had gone down the Clojure route.

> And Go has succeeded despite these condescending diatribes on how a language needs to have a Hindley-Milner type system with ADTs and type classes to be useful

Fine. But it's beside your parent comment's point. The article claims that everyone thought Go's type system was an advance on the state of the art. This isn't even close to true.

golang mainly ended up competing with and replacing the likes of python and ruby, where it was intended to compete with C and C++, where it didn't really change anything.

It makes sense in retrospect of course, python and ruby are slow, dynamically typed languages, and any improvement in performance and typing is welcome. It doesn't mean that golang is inherently better somehow to other offerings. I still maintain that Java and C# are superior languages and ecosystems.

> and why they are so absolutely lost when it comes to creating successful languages

They aren't lost—they're just more interested in actually good ideas than in popularity. Popular languages must appeal to all kinds of programmers with varying backgrounds, so they are heavily constrained. Your argument is basically that mathematicians don't know what they're doing because their most advanced theories aren't used by mechanical engineers.

> And Go has succeeded despite these condescending diatribes on how a language needs to have a Hindley-Milner type system with ADTs and type classes to be useful.

And nothing says that go wouldn't have been more successful had they added those features. In the final analysis, the relationship between the success of a language and any intrinsic qualities is very hard to qualify. But IMO, the success is not a good measure of wether or not the criticism of go were/are valid.

> Go made me truly realize how insufferable the PLT community is

Agree PLT folks can be a passionate bunch, i am not sure they are any worst to any other online community.

> and why they are so absolutely lost when it comes to creating successful languages.

Depends on who you include in the PLT group :

- C# and typescript were design by Anders Hejlsberg , arguably the most successful language designer - Scala is also pretty successful and really tied to the PLT community - Kotlin by JetBrain, Dart started with Gilan Bracha

Not to mentioned the wide range of features seen in most recent language (async-await, reactive programming for msft research) etc... etc...

The fight between pragmatic and simple language vs complex and expressive language is not happening outside the PLT, we have proponent of both ways of thinking inside the community. Not everyone in the PLT is pushing for overly complex theoretical approaches.

But more importantly, let's not forget the 1000's of engineer quietly implementing the compiler, libraries etc... that make go, or any other language possible.

Back to go, my personal gripe with go wasn't the decisions they made, but the rational given for those decisions.

Take the most famous example of not including generics. Designing a good generic type system is a very complicated task, and if the team had come out and say they didn't want generics because they didn't have the bandwidth or the know-how to do so, i wouldn't have care. But the rational given, describing generics as border line useless, or somehow too hard for the average programmer to grasp not only fly against basically 25 years of programming language history, but were just plain rediculous.

What do you mean by "Go has succeeded"? It has found its niche, yes, but so have those HM languages (maybe the Go niche is a bit bigger), and a bunch of other languages that people also like to hate.

Meanwhile, most code is still written in languages like Java, C and PHP.

That's no value judgement or anything, I don't think Java is an amazing language (neither do I think it's a terrible one), but it's not like Go has revolutionised anything. It's just become a new option among many.

I'd phrase it as: ruby, python, and javascript created a generation of programmers that didn't know how to use a type system. When they needed something more light weight and performant, they migrated to the language with the most primitive type system.

Typescript and swift have shown a better type system can appeal to the masses.

> you can learn in a day and keep in your head.

I'm not sure that this successpoint is really that valuable. It sounds more valuable for those who want butts in seats than it does for long term satisfaction and survivability of your code base.

Go has succeeded because it's not horrible and supported and used by one of the biggest companies out there. That means you end up with a long list of decent libraries, which to me feels like the main factor of success for a language.

Part of that success may have to do with "Wow, Google invented this...let's use it."

Kubernetes adoption seems to be going up but does it really add value for most that adopt it? I would say, no.

Now you’ve got me curious. I’d like to type inference in go. Can you tell me what languages do it better?

Nah mate, sorry. Go is a language already past its prime, which is laughable given how young it is, and how it was modeled on better, long-lived languages. Take a look at Google trends if you disbelieve me. There was a slight bump in interest when generics finally got pushed out, but that's died off, and Go is entering the same decline as other has-beens like Ruby. Good riddance to a language designed for people that aren't good at programming (you'll have to look up the quote yourself, I'm too lazy).

As proven by Oberon-2 and Limbo ancestors, it helps to have a good godfather.

> PLT community

What is that?

Go has "swept up entire markets" because they have an unlimited marketing budget. It has nothing to do with the merits of the language itself.

C is also a very low-level and close to the machine language.

Just because you can build a microchip doesn't mean you can build a spaceship and vice versa.

So I'm not surprised about that they e.g. left out generics and said they did so because they didn't know a good or right way to add them to the language. They were honest at least which I value a lot.

As to the success of Go that you mention. Well, let's be honest: it targets junior developers, or at least that was originally a major goal. It is backed by Google and is marketed.

There are just currently way more junior developers due to the demand and the developement of the field.

However, you can already see that a lot of junior developers that started with Go are not so junior anymore and now that they got more experienced, they demand language features that make them more productive - like generics. And they will be added and in the end Go will be a language that is not simple anymore, it will be the new python.

Go is a very practical and pragmatic language, no doubt. It's one if its strengths. But it is not by any means an advanced high-level language in any sense that I would know of.

> Few of the critics who "knew about programming languages" have created any language that ever made it into the top 10 programming languages in the world.

I often encounter some people in programming which I think lack humility. It's fine to question dogmas and the "big heads", but one has to look at the caliber of people you're up against and maybe give them the benefit of the doubt, if only a little bit.

I certainly wouldn't read a few PLT books and lambda-the-ultimate.org and then point to Ken Thompson and Rob Pike and say "your language has no <Type System thing>, you don't know what you're doing". These are not amateurs.

It's also doubtful they liked everything they put in, or disliked something they left out. Even Rust's creator didn't like some of the direction his language took.

If we were to ask other famous language designers they probably have a fonder feeling towards Go than people in this thread, knowing all of the hard design decisions one has to make to create an impactful language with an identity.

Right? So many complaints about "well but it's hard to make N-leaf tries in golang so we need generics!" It's like people believe the success of a programming language is correlated to its ability to express obscure computer science concepts unrelated to most peoples' jobs.

Golang works extremely well in practice, which is what I really care about.

> The Go team was populated by people who had created one of the most influential languages of all time, C

Which is absolutely terrible from a programming language point of view, there were already better languages at its inception. Ken Thompson has a huge legacy in the CS world, but he is frankly not a good language designer at all.

Also, appeal to authority. If go were so good, it should able to be praised on its own accord.

Those wouldn't have been as successful if AT&T had been allowed to sell UNIX at the same prices as VAX/VMS, instead of having source tapes available for a symbolic price.

It isn't as if C would have been a commercial success, had it come with a price tag.

Plan 9 and Inferno commercial successes, and Limbo adoption, are a clear example of how it would have gone instead.

One of the designers said that they had to dumb it down to the lowest common denominator Google engineer.

Go comes out, some Go cheerleader describes its decidedly not-state-of-the-art type inference engine as "state-of-the-art", I point out that it was hardly state-of-the-art, the Go cheerleaders come along and say "why do you even care if it's state-of-the-art?". Am I getting this right?

> The fact that it was even a point of concern shows how misguided the PL community is. Advancing the state of the art is not the goal, producing a tight, clean design is.

Why should there be only one goal of "the PL community" (whatever that is)? Maybe you need people who advance the state of the art and others who make things ready for production.

> Theory's only as useful as its implementation. If there's no sensible implementation of type inference out there, but then a new language comes out with it, is that not a significant improvement to the status quo, even if the theory behind it may be decades old?

That would be a fine argument if Go had been the first major language with type inference, but even if you're willing to ignore ML languages (because you think they're too niche and/or weird), Scala is almost 10 years older than Go.

> The fact that it was even a point of concern shows how misguided the PL community is. Advancing the state of the art is not the goal, producing a tight, clean design is.

I don't see how having better type inference interferes with the "tight clean design"? If anything I'd argue that not having it is a hinderance. Why do i need to `x :=make([]foo)` or `var x []foo` when I could just `x := []` and let the type system infer that its `[]foo` by the fact that I keep `append`ing `foo`s to it?

> Advancing the state of the art is not the goal, producing a tight, clean design is.

Sure, but they failed to deliver that.

Pretty much every golang project I've ever touched builds with `go build`. Most that have makefiles just call `go build`, and the makefile is more for building docker containers, or doing infra-related things. If a project is in go, 98% of the time `git clone XXX && cd XXX && go build` will work.

That is absolutely not the case with C, C++, Java, python.

> So gradle's issue, not Java's. See above.

The issue exists with maven too, but _not_ with go build, which is OP's point.

> I've worked on large golang code bases that had to build on bazel, and I had the same experience fighting it. It has nothing to do with the language.

So you deliberately added complexity instead of using Go's own build system and it didn't work out well and that's somehow a proof that Go's cross-compilation story isn't as great as people say?

The way you use the language has everything to do with the language. It is the language.

A language is a product, and the programmers writing in it are its users. The same way any other product works.

Would you be okay with buying a Tesla without the capability to charge at supercharger stations? You can only charge at home. The supercharger network is not literally part of the car after all!

My personal gripes are around the generated code not being idiomatic Go. It feels like code written by someone who doesn't really enjoy Go.

In particular, oneofs are *so* awful to work with that I'm often tempted to use an Any instead. For example:

    message Image {
      oneof kind {
        Bitmap bitmap = 1;
        Vector vector = 2;
      }
    }

Should, in my opinion, lead to code like this:

    img := &Image{Kind: &Bitmap{}}

But the reality looks more like this:

    img := &Image{Kind: &Image_Bitmap{Bitmap: &Bitmap{}}}

My other main gripe is that the generated structs embed a mutex, and so can't be copied, compared [ergonomically], or passed by value.

Sadly, both of these issues are explained away as on the issue tracker.

(My use-case is primarily to share data structures across languages, so perhaps it's not totally aligned with what protobufs is trying to do. I just wish there was a better alternative.)

Been a few years since I’ve used Go protobuf library, but it left a sour taste. First memory allocations are awful and slow. At the time there was no way to reuse slices for serializer when serializing and deserializing. The library would often panic instead of returning an error (this basically why we switched to an alternative library).

> I still don't know what people mean by "obvious" code.

This is one of those subjective "you know it when you see it" qualities that are going to be a function of the code itself and how well it conforms to practices you are used to. I also think that we have a tendency to not notice as much when we read code and understand what it does without having to think about it too much.

And you can get lost in Go too. You don't need a lot of language features help you complicate things.

For instance, I recently looked at some code that I had originally written, then someone else had "improved it". In my original version there was some minor duplication across half a dozen files - a deliberate tradeoff that enabled someone to read the code and understand what it did by looking in _one_ place. (This was code that runs only at startup and is executed once. It just needs to be clear and not clever).

The "improvement" involved defining a handful of new types which were then located in 3-4 different files across two new packages placed in a seemingly unrelated part of the source tree. A further layer of complexity was introduced through the use of init() functions to initialize things, which adds to the burden of figuring out which order things are going to happen in since init() functions sometimes have unfortunate pitfalls.

Yes, the code was now theoretically easier to maintain since it didn't repeat itself, but in practice: not really. Rather than look in one place to figure out what happens, you now had to visit a minimum of 3 files and 5 files in one case.

And remember those init() functions? Turns out that the new version was sensitive to which order they would get executed in. Which lead to a hard-to-find bug. Now you could say that this is unrelated to complicating things by decomposing a lot of stuff into more types, but this isn't unusual when people get a bit obsessive about being clever.

> But that said, I suspect many people, when they say, "obvious code", > they mean "I can easily understand what every line does". Which is > a fine goal, but how does that help me with a project that has 100ks > of lines of code?

These are related but different problems. At the micro-scale (what you can see in a screenful in your editor of choice), consistency in how you express yourself is key. In essence the opposite of the "there is more than one way to do it" mantra in Perl. This mantra is bad advice. You should ideally pick one way to express something and stick to it - unless there are compelling reasons to make an exception. (Don't be too afraid of making exceptions. There is a fine line between consistency and obsessiveness).

If you stick to this your brain can make better use of its pattern-matching machinery. You see a "shape" and you kind of know what is going on without actually reading every line of the code.

Also, how you name things is important. When I was writing a lot of Java you could ask me the name of classes, methods, variables, and I'd get it right 90% of the time without looking. Not because I'd remember, but because I had strict and consistent naming practices so I knew how I'd name something.

(I haven't succeeded in being as consistent when I write Go. Perhaps I can get guess the name correctly 70% of the time. I'm not sure why).

Now let's look at "how does that help me with a project that has 100ks of lines of code".

At larger scales it is really about how you structure things so you can reason about large chunks of your code. Think in terms of layers and the APIs between them when you structure your code. Divide your code into layers and different functional domains. Describe them through clear APIs with doc comments that clearly document semantics, preconditions, postconditions etc. The trick is to try to identify things that can be structured as libraries or common abstractions and then pretend that those bits should be re-usable (without going overboard).

Say for instance you are implementing a server that speaks some protocol. You want to layer transport, protocol, and state management with clear APIs between each layer. Your business logic should deal with the implementation through an API that is a clear as possible. Put effort into refining these APIs. A good opportunity is when you are writing tests. You can often identify bad API design when you write tests. If something is awkward to test it'll be awkward to use.

Also, like you would do when you write a library, give careful thought to public vs private types and functions. Hide as much as possible to avoid layer violations and to present a tighter and narrower API to the world. (Remember APIs are promises you make. You want to make as few promises as possible).

This also has the benefit that it gets easier to extend. APIs between layers are opportunities for composability. Need to add support for new transports? If you have structured things properly you already have usable interface types and unit tests that can operate on those. Need different state handling? Perhaps you can do it in the form of a decorator, or you can write an entirely new implementation.

(Look at how a lot of Go code does this. For instance how a lot of libraries, including the HTTP library in the standard library, allows you to inject your own transport. This enables you to do things the original authors probably didn't think of. I have some really cool examples of this if anyone is interested)

Over time you will probably see a lot of parts of your software that can be structured in similar ways. This allows you to develop habits for how you structure your ideas. The real benefit comes when you can do this at project or team scale. When people have a set of shared practices for how you chop systems into functional domains, layer things and design the APIs that present the functionality to the system.

So in summary: you deal with 100kLOC projects by having an understandable high level structure that makes it easy to navigate and understand how the parts fit together. When you navigate to a specific piece of code, your friends are consistency (express same thing the same way) and well documented (interface) and model types.

Years ago I came across a self-published book that taught me a lot about how important APIs are when building applications. The book was about how to write a web server (in Java). It started with Apache Tomcat (I think) and focused on the interface types.

Using the existing webserver as scaffolding it took the reader through the exercise of writing their own webserver from scratch, re-using the internal structure of an existing webserver. One part at a time.

The result was a webserver that shared none of the code with the original webserver, but had the same internal structure (same interface types). This also meant your new webserver could make use of bits and pieces from Tomcat if you wanted to. I found this approach to teaching brilliant because it taught several things at the same time: how Tomcat works, how to write your own webserver, and finally, the power of layering and having proper APIs between the different parts of your (large) applications.

I still think of the model types and the internal APIs of a given piece of software as the bone structure or a blueprint. You should be able to reimplement most of a well designed system by starting with the "bones" and then putting meat on them.

> I can't read every single line, and even if > I could, I can't keep them all in my head at once.

Keeping 100kLOC in your head isn't useful. Nor is it possible for all but perhaps a handful of people on the planet. But if you are consistent and structured, you will know where you'd put a given piece of code and probably get there (open the right file) on the first attempt 70-80% of the time. I do. And I'm neither clever, nor do I have amazing memory that can hold 100kLOC. But I try to be consistent, and that pays off.

> And all the while, > every one of these lines could be mutating some shared state or > express some logic that I don't understand the reason for.

If you have 100kLOC of code where any line can mutate any state directly, you have two huge problems. One is the code base, the other is whoever designed the code base (you have to contain them so they won't do more damage). If you have gotten to that point and you have 100kLOC or more, you are really, really screwed.

I've turned down six figure gigs that involved working on codebases that were like that. It is that bad.

In Go, mutating shared state is bad practice. This is what you have channels for. Learn how to design using channels or even how to make use of immutability. There are legitimate situations where you need to mutate shared state, but try to avoid doing it if you can.

(I've written a lot of code in Go that would typically have depended on mutexes etc in C, C++ or Java, but which use channels and has no mutexes in Go. There is an example of this at the back of the book "The Go Programming language" by Kernighan et al, though this book is getting a bit long in the tooth)

If you do have to manage access to shared state be aware that this is potentially very hard. Especially if you can't get by with single mutexes or single atomic operations. As soon as you need to do any form of hierarchical locking you have to ask yourself if you really, really want to put in the work to ensure it'll work correctly. The number of people who think they can manage this is a lot larger than the number of people who actually can. I always assume I'm in the former group so I avoid trying to implement complex hierarchical locking.

> Yes, there are people who create a mess with abstraction. This happens in every language, in Java people create FactoryFactories, in Haskell people play type tetris, in Ruby, people abuse metaprogramming and in Go, I assume some people go overboard with code-gen.

It's possible in any language and yet some languages' codebases are consistently worse than others ;)

If you create a culture of cleverness, implicitness and metaprogramming, that's what the programmers using your language will do. It's self-selection to an extent.

"I've suffered long from the Ruby ecosystem's mentality of 'look at what I can do!' of self-serving pointless DSL's and frameworks and solemnly swore to myself to stay away from cute languages that encourage bored devs to get 'creative'." [1]

"I worked at a Scala shop about 10 years ago. Everyone had their own preferred "dialect", kind of like C++, resulting in too much whining and complaining during code reviews. IMHO, the language is too complex." [2]

> And all the while, every one of these lines could be mutating some shared state

That's where the obvious code helps.

Let's circle back.

> I still don't know what people mean by "obvious" code.

The Zen of Python is a nice primer: [3]. A beautiful display of taste right there.

A few concrete examples:

- "Explicit is better than implicit."

Explicitly returning errors means we get to see every single point at which something could error out - explicit, as opposed to exceptions that could implicitly propagate from any line of code, with no way to tell.

Preferring pure functions - a pure function is a black box with a clearly drawn boundary line of input->output. Trivial to reason about in isolation.

No automatic type conversions.

No global state - any part of the code could change it.

No metaprogramming - you've learned Ruby but now some parts of the language have been changed to mean something completely different!

"The syntax has so many ways of doing things that it can be bewildering. As with Macro-based languages, you are always a little uncertain about what your code is really doing underneath." [4]

- "There should be one-- and preferably only one --obvious way to do it."

Uniform code. Iterating through an array always looks the same, so if the code you're looking at does it differently, you'll pay attention.

[1] https://news.ycombinator.com/item?id=13482459

[2] https://news.ycombinator.com/item?id=31219392

[3] https://peps.python.org/pep-0020/

[4] https://alarmingdevelopment.org/?p=562

Problems are generic, such as having a tree collection. For solving generic problems, you can either use language generics, or reflection, or type erasure, or codegen. The latter three are about as far from 'boring and clear' as you can get. Still verbose, though, but I don't expect that's a benefit.

Is writing the same function n times more readable and more maintainable? Is it more maintainable to entirely circumvent the type system with interface{}?

I've heard the drum against clever code for over a decade. This sums it up well:

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan

Maintaining "clever" code is incredibly hard because the only "clever" person is the one that wrote it, everyone else is "dumb" to it. One can take hours debugging clever code. Obvious code won't wow anyone but will be immediately understandable, which is an advantage in a team setting.

Clever doesn't necessarily mean smart.

Back in the day when GCC 2.9.5 was a widely used version of GCC we had a codebase that was full of "clever" hacks to trick the compiler to generate the assembler code we wanted. A few of these hacks were used in tight inner-loops that had a huge impact on performance. I can still remember the day someone removed what seemed to be a no-op in a piece of code, compiled it and pushed it to production - only to have everything grind to a halt and fall over because CPU use per request tripled.

Sure, it was a "clever" way to get the compiler to output what you wanted it to output, and it was common knowledge among some of the programmers on the project what that no-op'ish line would do - but not all.

The smart thing to do would have been to fix the compiler and upstream the fix (from our internal branch of the GCC toolchain). The "clever" solution was to just figure out a bunch of tricks to manipulate the compiler and call it a day.

In the context of this thread, "clever" is mostly taken to mean "not as straight forward and understandable as it can be".

Young me loved cleverness.

Older me knows how frustrating it is when something isn't as straightforward as it could be. Either because I have to figure out how something someone else wrote works or because I have to explain what my code does to people who have gotten confused.

When I write code other people can't understand I see that as a failure on my part. Because it is. Code isn't merely a mechanism to convey meaning to a compiler, it is a way to communicate with other human beings. Most of which aren't that interested in indulging my cleverness.

Yeah, the original GOPATH stuff was atrocious.

Two questions:

1) how do you like the module system we have today? 2) can you expand on what you mean by boring, why it is important to you that a language not be boring, and give an example of a language that is not boring?

> I've never seen anyone argue that allowing unused variables is good for production. It's always been about facilitating the development process and debugging. Yes, I am aware now there are unused variables, but please just let me see what does removing this part of the code do.

Yes, but once you allow that, you'll inevitably end up with unused variables in production code (warnings are useless). That's the core of the issue and why the Go team made the decision.

In my opinion, the real solution is to have two build modes: --devel and --release. This would allow for not bothering devs with anal checks during development while preventing substandard code in production.

Though the real advantage would come from the reduced pressure on compilation speed in --release mode which would make room for more optimization passes, resulting in faster production runtime speed and lower binary size.

I will literally not touch any language that does that. Not too sad about missing out on Go, but Zig unfortunately also shares this braindead thing.

The solution is all so easy also — just add a debug and a production profile. Enable your strong linter in prod, for all I care, but this is a must-have development tool.

Well, for that specific case (it was a well defined block that could be all selected and commented out in order to disable it), your technique would have worked fine, true :)

But of course it can get tiring and not be very practical if the logic to disable is a little bit more spread out (I'd say having to "if false" anything more than 2 paragraphs or blocks of code would already start to feel annoying)

Make debug mode have runtime costs automatically (like race checks, less optimizations for faster compile). That way people are left alone while developing (plus getting cool tools for that as well), while are incentivized to build final prod builds for sane performance, for which they have to clean up after themselves.

Though personally, I dislike this paternalistic approach to handling devs.

If only a language could have a built in feature to propagate an error up the call stack, recording its context as it goes!

It's always surprised me how negative of a reception checked exceptions had, since they provide the forced handling (or explicit propagating) of (value, err) or Result<T, E>, but with an automatic stack trace and homogeneous handling across the ecosystem

I imagine some of the disdain in Java specifically came with how unergonomic they are with lambdas. Either you don't allow them at all, like in most standard library functional interfaces, or you do, but now every caller has to handle a generic Exception. I guess what was really needed was being able to propagate the "check" generically, e.g.

  <T, E> T higherOrder(Supplier<T throws E> fn) throws E {
    return fn.call();
  }

So a call site of higherOrder would only be checked as far as fn is

I'm unsure if that's even possible to do (and if other languages have done it) or if it leads to undecidability. I'm very rusty on PLT

In practice if you look into existing codebases, it is littered. defer is used for RAII-style clean up, so in 95% of the cases it's just return the error and that's it.

Just cos I was curious and Java has a pretty good comprehensive library.

- PNG: https://docs.oracle.com/en/java/javase/14/docs/api/java.desk...

- HMAC - https://docs.oracle.com/en/java/javase/14/docs/api/java.xml....

You need Jetty for HTTP/2.

Is that more or less ironic than Java copying Go's goroutines and still struggling to add value types?

I'd guess the typical situation is you had thought maybe a public API featuring enunciate_spools() was a good idea, but eventually you realised actually nobody actually wants to enunciate spools and few people know how, when you see other people's code that calls enunciate_spools, it's always either a bug (and they shouldn't have) or test code that is inappropriately testing your stuff not their stuff.

So you make it private, in say Rust that's an ABI break, so you need a semver bump, but you aren't changing your code. Internally normal_operation does need to enunciate spools, not to mention the acrobatic use of it in complex_operation and fancy_coroutine but that's because it knows intimately what spools are and why it's enunciating them - it's an internal design element, not an API.

In Go, you have to rename it everywhere. Maybe your tooling helps with that. OK, but, not having to do it also helps with that and for everybody.

DX is Developer Experience.

I'm guessing that DX means "developer experience" here.

  a, err := f()
  if err != nil {
      return
  } 
  a, err = f()

This will compile.

If there is a single result you can also on ignore the return value by calling myfunc()

I would have taken sum types over generics, personally. It kinda sucks because you can't create something like Rust's `?` operator without them or making serious kludgy compromises.

Yes, sum types would solve the problem - you are both identifying the same issue imo

What's the tradeoff? what advantage having null pointers give?

not really, it's not something Golang really cares a lot to say the least, to become 'mainstream', Golang actually has to embrace more use cases.

https://github.com/golang/go/issues/47788

Erlang's been around forever, also a fairly simple language. I'd imagine concurrency's easier than on Go.

Erlang had a better concurrency story than Go, and better error handling. But alas marketing wins.

Dynamic typing via interface{} is also huge Go code smell though, so...

Generics are definitely better for you. But I would say the overall pattern you're employing of bulk inserting different kinds of data structures with one function is the problem. Of course, I don't know your code so I'm sure you have a good reason for choosing what you did, but a BulkInsert of Any certainly made me raise my eyebrow.

I have written a library actually. I found interfaces perfectly sufficient for allowing applications to consume the contracts of the library without needing generics. Of course I understand that they have a use and are useful, but it's not like there weren't excellent solutions for this in Go before generics existed.

Uh, generics are not data structures and generics are neither the only way nor the best way to interact with data structures.

Do you actually have anything of value to add to this discussion? Because this comment is pretty bad.

The power of voodoo

The documentation for DBNull [1] seems to have some idea that DBNull represents something entirely different.

> Do not confuse the notion of null in an object-oriented programming language with a DBNull object. In an object-oriented programming language, null means the absence of a reference to an object. DBNull represents an uninitialized variant or nonexistent database column.

For all the explanation though, I couldn't fathom what its talking about.

[1]: https://learn.microsoft.com/en-us/dotnet/api/system.dbnull?v...

> Yes, there are features you can defer implementing until later, but their absence infects everything until you do. I still see cases where people have to drop down into ADO.Net code for C#, and the fact that you still see DBNull.Value instead of just a simple null value, much less a proper Option type is infuriating.

This DBNull.Value may be a problem for C#, but idiomatic Go has largely been untouched by the introduction of generics.

I’ve noodled around with generating review-ready Go from CL (because macros), but it’s hard to flatten subexpressions (like multiple-value-bind around a call that returns a value and an error) into blocks of statements that assign to new temp vars, and I couldn’t expect arbitrary CL to just work, it’d be more of a CL-flavored DSL for generating loops and error handling.

Anything that made programming easier in the last 30 years.

I miss Hindley Milner type inference, ADTs, default immutability, sane error handling, pattern matching, and functional collection manipulation.

I'm not even mentioning the time it took to add generics to the language, which should've come from the beginning, and we got a bad implementation of it.

Not saying that it HAS to have all of this, but at least 1 or 2 things of that list would already make Go have much better ergonomics.

Go has no excuse since it's a relatively new programming language, and it could've got some of those from the start.