Go Replaces Interface{} with 'Any' (opens in new tab)

Sure, but semantic versioning really is the wrong kind of versioning to use for a language. The major version should represent major language changes, not whether its a breaking change or not, semantic versioning isn't somehow magically a "good" way to version. It's useful for libraries / dependencies where you are dealing with many different libraries and just want to know you can upgrade without having to deal with breaking changes. For a language? Silliness. Your version is not really telling you the main things you care about.

It's much much more useful to the users to say, 2.0 introduced generics, it's distinct. If it's like other languages, generics changes the code people generate a lot, libraries start looking significantly different. It's very distinct, and if that is simply in version 1.18.0 or whatever, that is super bad usability from a language perspective.

I feel like this is perhaps a bit of a gap in semver tbh. Sometimes a purely additive change can be quite major, in the sense that it shifts the thing in such a fundamental way that you are unlikely to try to interoperate between before and after, and are likely to run into trouble if you do.

Basically, if 1.18 code is extremely unlikely to work against a 1.17 compiler, because a new (technically additive) feature is pervasively threaded through new code, I feel like it's hard to describe them as part of the same epoch.

I don't write enough go to know if that's true for generics, but it seems like it could become true fairly quickly from my experience with other languages.

Changing the programming approach seriously should be a major version change.

A language is an interface with humans. Switching to generics is a major change in the way to think about the source code. It's not an implementation detail which is not a big deal as long as the compiler can accept earlier source syntax.

0ver is parody, right?

I just tested on the dev branch and you can still use variables named `any`. The compiler is smart enough to tell variable names and types apart. You can even create a variable named any with type any with `var any any`

"any" is a new identifier, not a keyword. The usual shadowing rules apply.

Couldn't unbounded just be [T]? Why the extra typing?

You can like generics without requiring everything to look like Java.

(In fact, generics have been a relatively late and reluctant addition to Java. They had been at home in ML-family languages and others for ages before.)

Hence I’m not happy with anything that doesn’t look like Java.

Go seems amazing otherwise, but I cannot get over the fact that it forces me to capitalize or not capitalize my variables, and has types in the wrong order.

Newer is not always better. So I prefer to stay behind a little, if I can. [I stayed away from JavaScript until ES6 and Typescript. And I think I avoided myself a lot of headaches being that cautious]

> Go often works well for replacing shell scripts, even without generics.

That’s selling the language short. Way too short.

I actually agree with you.

I'm mostly a C# developer that uses a ton of generics and when I tried Go previously I was disappointed that it didn't have generics. But I continued on. And so I found a handful of other things that would irritate me or would be an inconvenience versus doing the same thing in C#. So generics alone is not the main problem here, it is going from a C#/Java mindset to a Go mindset. In some way we would probably get bored with Go because it is so simple/easy and not much to mess up, versus the super complex object empires in C#/Java land.

So the problem is not really a problem, go is just a different tool for a different kind of problem or if your brain works in a specific way - but I wouldn't call it a problem at all. In a way, go is what Buddhism is to other (more fully featured) religions. I think if you get proficient with you can probably have a very peaceful programming experience and not fight against the system (like in Java, half the battle is just battling the tooling).

Thanks for bringing this up, will give Go another look again, its been a while!

This feels like an unusual opinion. Lots of people from different backgrounds are happy with Go. And it's praised particularly for its concurrency model.

That said, generics are still new and won't have the strongest library support for a while, and it takes a bit for idioms to settle. It wouldn't be unreasonable to wait for ~a year.

I don't understand why you're lumping JavaScript in with Java. These are very different languages and are likely to produce very different mindsets.

Yes, but without generics it's hard to do much useful with lambdas in your statically typed language. You can't even write a filter or map function.

And eg Go's old workaround for polymorphic sorting functions was just atrocious: it was rather convoluted, and only really worked at all for in-place sorting.

Go is the most readable language I’ve used in terms of understanding other peoples complex code bases, and I’ve been doing this a long time and have used a lot of languages.

Edit: It’s also one of the most approachable languages.

I agree, and I think this mistake is at the root of most of what are (at least to my biased point of view) the big mistakes made by go. Syntactical niceties and simplicity / obviousness are sometimes a tradeoff, but go 1.0 felt like the designers just folded their arms and refused to consider any niceness. I still don't understand why anyone would use go when there are so many better choices, but at least they're fixing some stuff now :)

That’s a very condescending way of say “I don’t personally like this feature”.

It's not a hack, it's the natural way of expressing it in the chosen type system. The use cases for interface{} are often hacks, because of a lack of parametric polymorphism, but that's different.

The Rust Result type has:

  - map / map_err
  - and_then / or_else
  - unwrap / unwrap_or

And countless of other functions making it very practical to chain computations without having to pattern match anything.

I do the same in Erlang/Elixir.

In Golang, I need to check every function call, and if I want to know where an error come from, I need to wrap it in an errors.New() because no exceptions = no stacktrace

> because eventually you have to do...

Emphasis on eventually instead of at every single function call.

> but eventually you always have to take out the value

No. You can just feed it to the function (from a library / stdlib) that needs it, or call .fold() in the end.

you can map on ok which is an alias for map_ok and then map_err for errors and or_else or_throw etc.

that's similar to what Java does with the Optional type, not great, but not bad either

the alternative is checking for nulls which is worse in any possibile way

I usually implement something like Kotlin Result when I have to code in Java

with a couple of static helpers to build the result: Result.success(T) Result.failure(Throwable t)

https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-result/

also Result in Rust has been an inspiration

https://doc.rust-lang.org/std/result/enum.Result.html

Fun observation of mine: most articles/tutorials I've read about "idiomatic go code" are presenting ideas that you never see in any production code.

Seems to me that the ones who write about "idiomatic go code" aren't the ones who are shipping softwares/libraries.

An exception has a stacktrace. This single piece of information is crucial when you debug and makes handling errors in Golang embarrassing.

I rest my case.

I used to really hate that. After reading this amazing post https://middlemost.com/failure-is-your-domain I created a module that makes this bearable https://github.com/Vanclief/ez

We often have errors handled. In contrast to many Java codes just spitting unhandled exception stacktraces or crashing completely.

Rely more on the map/map_err/or_else/... methods for the Result type. You'll get something like (pseudocode):

  may_fail_who_knows()
    .map(use_value)
    .map_err(some_error_processing)
    .and_then(another_computation_which_can_fail)
    .or_else(with_some_error_handling_that_can_rescue)
    .unwrap_or(a_default_value)

Basically, instead of nested match expressions, you get a "pipeline".

There is a reason very robust software is written in C: no exceptions means you think about normal errors all the time and reason about what the difference bwtween an error openjng the file and an wrror writing the file. Sqlite, linux, cpython, all bullet proof and all C. The lack of exceptions more than makes up for memory unsafety issues.

There's many options, just look at other modern languages. The simplest are exceptions/errors that can be thrown - like you get in Java, python, typescript, etc. For something more like a traditional return value, you have std::result in rust, and error union types in zig, with language support to guarantee you check and handle the result. In C, you have macros and goto that can be used to reduce boilerplate and implement whatever pattern you want.

Basically macros, like in Rust, not like in C. Rust can do stuff like the serde serialization library while Go has to rely on reflection with its obvious performance drawbacks.

That's an extra line of boilerplate. If someone for some reason wants uglier and longer code then can still use interface{}

In C++ there could be 7 or 8 different ways go about implementing similar functionality. This is powerful in that it lets you do exactly what you want because each of those ways is subtly different and sometimes you need each one.

Go's proponents think it's okay to be a bit less powerful so that there is only 1 maybe 2 ways to do something. This makes code at different companies more similar.

It also mean that a new grad can join the team, read the code, copy it, modify it some, and it's pretty much right. A staff SWE and a new grad will right very similar code in Go. In C++ it's anyone's guess how similar their code will be.

the fact that the set of types that can satisfy an interface is open is the source of their power. "closed interfaces" are broadly an antipattern in Go.

I don’t enjoy writing Scala even if the pattern matching syntax is basically the same as Rust. Some of it is the build tool, some of it is the JVM, and some of it is simply distaste for the language.

I don’t hate Scala and I’ve even written a few PRs in Scala, but I have had trouble picking it up for actual projects.

Go is extremely pragmatic and often favors clarity in how code will execute and simplicity in syntax and grammar. It’s basically a GC’d successor to C in many regards. It eschews classes for interface-based polymorphism, it compiles and runs code very fast, and above all, I’ve found it easy and rewarding to pick up.

I don’t want all of the expressiveness of Scala. Just a bit more than Go has today. Not much more.

I think a language that doesn't focus much on backwards compatibility isn't a great comparison to Go :) Having written some Scala, I really like the language. I also like Go's excellent performance, easy concurrency, ability to produce a single binary without having to rely on JVM etc. I think it would be a bad idea to get overly complicated constructs into Go but union types/pattern matching are relatively accessible, not uncommon now and provide a lot of expressiveness without the risk of code becoming unreadable. Those combined with maybe some alternative approaches for error handling will make me want to write Go again (I've written one component in Go that is working perfectly but it was just too much code with bulk of it being err != nil).

Modules don't require any particular directory structure, just a go.mod at the root of your project.

I’ve found out that it’s possible to be too up-to-date for some coding interviews.

I’ve only ever been offered to pick my own language in interviews (so I always pick Python). Is this not your experience?

> Much simpler than Python which (and this is subjective) has made some questionable design choices.

One of the reasons golang is so simple is that they move very carefully on issues like this. It has its benefits and its drawbacks.

Adding operator overloading kind of opens a can of worms here. If they add that, why not arithmetic types? Why not exceptions? Why not x, y, z... Everyone wants just _one_ extra feature that would improve the language. Trouble is everyone disagrees on what that one feature should be.

after above 2 changes sure :)

Typescript is also far slower both in terms of runtime and compilation time, uses much more memory, and is far more complicated which in turn has led to a ton more compiler bugs. It also inherits a ton of questionable features and API decisions from Javascript and has a tiny standard library which means most Typescript developers repeatedly end up turning to the NPM ecosystem which is an unmitigated disaster. Deployment also isn't even remotely as simple and reliable as Go even with Deno compile.

I like Typescript a lot but the reality of Typescript development is not great.

This isn't super clearcut. Typescript has lots of footguns and famously says that soundness is not one of their driving factors. There are lots of ways to devolve to accidental implicit any's (even with the no implicit any strict rule turned on).

Of course, Go makes zero attempt to enforce nullability (nilability?) in its type system... so... win some, lose some I guess.

Any language based on JS can't be safer than Go. The end result of TS is JS which is a dynamic language.

I suppose you could define a type alias "unit". It's not surprising to me that this isn't in the go standard library though.

You can define that yourself as "type token = struct{}" or similar. In my experience struct{} occurs even less than interface{}, and it's also 3 characters shorter already, so it's not worth a builtin. I use "chan struct{}" for synchronizing and sometimes use "map[string]struct{}" for sets.

We use the alias "unit", like lalaithion has said before, in many projects. It's a bit annoying to declare it in every package though. Hopefully, there'll be an official alias in the future.

Not being able to customize built-in containers is a huge win in terms of readability though. Principle of least surprise and all.

If I see a map or slice I know exactly how it behaves, how much memory it consumes, what the runtime behavior is. If you make those generics instead then I have literally no fucking clue what's going on.

Some languages even have real for statements because it makes more clear what the intention is.

In Pascal, you can’t break out of a for statement, the limit and step value are evaluated only at start of the loop, and you can’t change the value of the variable being looped over.

Consequently, the number of iterations through the loop taken is known when the loop gets entered.

It does, but with generics coming down the pipe, I feel that "any" expresses intent somewhat better in certain circumstances. Or at least it ought to improve readability-at-a-glance.

I'd imagine you can continue using interface{} for the foreseeable future.

OTOH there’s no ‘while true’ or do-while or while-do, none of which are particularly fluent.

Only the same if sum == 0 at the start.