Comment by sph | Hacker News Reader

Comment by sph | Hacker News Reader

Parent Full thread

tl;dr: We're shipping generics in 1.18, it's a huge release so let's wait a little bit until they stabilise and they're used in production before changing our stdlib.

Good call in my book, and I'm extremely excited to have generics finally. I thought they were going to ship with 2.0, but the sooner the better!

It's cool to hate on Go, it's taken over the system programming space for a reason, like it or not, and after working full time on Elixir it's hard not to think in map/reduce and other generic constructs, which were unreasonably verbose before in Go. Now the haters will have to focus on the "if err != nil" statement to pile on the language — though to be fair I'll expect some ergonomic improvement on that aspect as well, eventually.

With generics, Go will be my new Python, but with a decent dependency and deployment story, and I'll just need Zig for my low-level manual memory management needs. What's Rust?

EDIT: indeed being a bit cheeky with HN's favourite language isn't well received in this place.

> It's cool to hate on Go,

criticism =/= hate

Nobody "hates" on Go for the sake of it. If some people were not critical of that language, generics would have never been added at first place. I'm glad the Go team acknowledged the flaw instead of the gaslighting that has been going on for years in the go community from a few go users.

Calling it "gaslighting" is exactly what a hater would do. It's not very constructive.

Generics were a pain point, but people have been crapping on Go on this forum while people out there are using it to build stuff. It's not a perfect language, but if you read any HN thread about it it's like it's impossible for people to go past the lack of generics or the existence of nil.

It is a good use of the word "gaslighting", which I think can be defined as "an effort to convince someone that they do not know a thing that they do know". In this case, a lot of people know from lots of experience that writing type safe generic code is extremely useful, but the go community spent a long time arguing that people could not have had that experience because writing generic code isn't actually useful. This isn't really my impression of what the go team was saying, which I interpreted as more like "parametric polymorphism is useful but we aren't sure it is a good fit with the simple language design we are seeking to maintain". That's totally reasonable, everything is trade offs, but that's not the prevailing pushback you would get from the go community, you'd instead hear a message more like "if you'd rather write generic code instead of copy pasting constantly, you're a bad programmer who doesn't get it", which is not helpful and yes, I think gaslighting is a reasonable description.

The existence of nil is also a design flaw. But you're right that no language is perfect and neither of these flaws keeps people from building tons of useful stuff with the language.

I think there is definitely gaslighting in the other direction too, which is what you're highlighting: lots of people know from experience that go is a super useful language, but then people come of as saying "your experience does not exist, it is not a useful language because of these big design flaws".

Correct me if I’m wrong, but it sounds like you’re not really claiming people say “your experience does not exist” or “you’re a bad programmer who doesn’t get it.” It sounds like this is a bit of exaggeration for effect?

I suspect you’re talking about something I’ve seen, which is people will say that your experience in other languages isn’t directly applicable to writing code in Go because it’s a different language and ecosystem.

This seems like something newcomers need to hear sometimes, and it’s also somewhat irritating if in your case it doesn’t seem like that kind of issue. When generic advice for beginners gets misdirected then it can seem insulting, but I usually just try to remember that they don’t know me and beginner mistakes are worth checking for. I can choose not to be insulted.

Getting people to actually hear what you’re saying when they’re pattern-matching on common questions can be difficult. I think we should still assume good faith, though, and “gaslighting” implies malice.

Those are summaries of responses I've gotten when discussing this a long time ago (before the language team decided to figure out how to incorporate generics). I'm not sure the exact actual wording, but that's very much how it came off to me, that there's no way to be both smart and experienced and simultaneously convinced that generics are an extremely useful language feature. These debates don't get so heated now, because even the go designers themselves conceded the point long ago.

Your more nuanced version of the argument is also wrong though. Experience from other languages is always applicable. Even for beginners, it is obvious and correct to ask "wouldn't we save a lot of repetition if we could write a generic version of this function instead of tediously rewriting the same thing for a bunch of types?". The correct and very reasonable response is "yes, but the designers of this language chose not to support that functionality in an effort to maintain simplicity". The right answer is not "no, this language is unique such that that technique is not applicable to it". That's gaslighting, and much worse when directed toward beginners who will just conclude that they must be wrong, when they aren't.

I agree with your last paragraph in general, but in this case that's not what was going on. Saying that the language would not actually benefit from polymorphism was not true, it was just a rationalization for leaving out a useful feature. It's the difference between "yeah that would be useful but we don't think the complexity it brings is worth it" vs. "that is not useful in this language for reasons you aren't wise enough to understand".

I started coding in 1986, naturally I used plenty of languages without generics to build stuff, that doesn't mean it still makes sense in the 21st century to design strongly typed programming languages without generics.

Some people crapping on Go in this forum are also people who have been using it to build stuff, though. It's inaccurate to assume these are distinct groups.

> it's taken over the system programming space for a reason

I'm curious what you define as systems programming, because Go certainly isn't a systems programming language by the classic definition.

Go has a complicated runtime and GC. It's really not in the same category as C/C++/Rust, but more like Java/C# , just without a JIT.

The only domain where Go is a go-to language is the Kubernetes ecosystem. It's also decently popular for networking heavy applications / microservices / server applications, because the runtime is well suited for those domains.

Go is basically a systems programming language if you consider """the cloud""" a system, a big part of the ecosystem is built on it. It is basically between C/C++/Rust and Java/C#, which is "good enough".

In that case JavaScript is a systems programming language if you consider the web a system.

Golang having GC and a heavy runtime make it unsuitable for systems programming IMO.

It isn't unsuitable per se, but it definitly lacks the knobs of something better like D, C# or Nim.

https://www.packtpub.com/product/creative-diy-microcontrolle...

https://www.f-secure.com/en/consulting/foundry/usb-armory

Not exactly, the web runs on browsers and web engines that are written in C++, and servers that are mostly C and/or C++. On the other hand, "the could" runs (partially) on k8s and friends, which are written in Go (which runs on servers, written in C and/or C++).

We’ll soon have Java and C# without a JIT once they are done working on their AOT compilers.

The C# one seems to be further along though due to having supported the Mono/Xamarin AOT runtime for a long time and is really easy to setup, it’s just a package reference in your .csproj. It also has the benefit of coming with a modern usable language.

Lack of null safety is still a major shortcoming in my book compared to Rust/Swift/Typescript.

I never had a real issues with null safety in 3 years of using Go regularly. Maybe due to may long experience with Java which might have sharpened my eyes for null safety.

Lack of enums and pattern matching is IMO the bigger issue. I miss that regularly.

null safety: Can you provide us a reference to a working definition of the term?

For example in Typescript, you can specify whether a parameter is allowed to be null in the signature of a function. If you do the compiler will make sure that you don't accidentally pass a null value to that function.

  function foo(x: number) {
    return x + 1;
  }

  let y = null;
  foo(y); // compiler will flag this

In Go

    func foo(x int) { return x + 1 }
    var y *int = nil
    foo(y) // compiler will flag thi

That wasn't the greatest example as Go doesn't really have any way to represent it. If it did it might be something like this.

  type MyStruct struct {
    Name string
  }

  var-not-nil myStruct = &MyStruct{"Hello"} // this is a "not-nil" pointer variable

  myStruct = nil // compiler would catch this

The idea being to allow variables to hold and pass pointers to structs like now but ensure they are never nil.

Now add an error to foo and have x=0 as a valid return value, or even worse, having to deal differently with different errors.

null/nil can only occur in scoped use cases (Option<Foo>, Foo | null, Foo?) and so the compiler can warn you when something could be missing and you don't handle it without being incredibly noisy.

At least now we can write a generic set that supports all the things you want a set to do, instead of using map[T]interface{} and a lot of for loops.

>map[T]interface{}

If the semantics desired are merely those of a simple set, why instantiate storage for the value side of the map? An interface{} consumes 16 bytes. Instantiating a struct{}, i.e. with no fields inside, consumes 0 bytes.

Ah yeah, that's right, it was map[T]struct{} - it's been a bit since I had to do it.

I knew it was something with curly brackets instead of the map[T]bool I started using.

Because when a language doesn’t supply common features out of the box, users implement them for themselves, and inevitably a lot of them do a bad job of it :)

More reasons to have a generic Set type in the standard library. That way you know the implementation is correct every time.

Go has taken over kuberbetes related stuff, that is all.

Although I like it being used for systems programming stuff like TinyGo on embedded or F-Secure TamaGo unikernel, that is hardly taking over the domain where C and C++ still rule, and will keep to do so for decades to come, despite the increasing usage of Rust on the domain.

That's because you can put out there why you like a language and people will upvote you. Dump on other people's choice in a systems language and you will likely suffer some down votes. Cheeky has a price.

Brad Fitzpatrick stated in one of his talks, that a version of Go coming with generics will be called 2.0 eventually. Maybe they do the version jump if there are backward-incompatible changes done to the library in 1.19.

When was that ?

IIRC that was the general feeling then but the impression has changed in the mean time ?

No need to disrespect Rust. I like both. And certainly they both have their proper use cases.

Reply on news.ycombinator.com