12 ms·

(rant) That's nice, but also rather self-congratulatory. I was expecting some kind of acknowledgment of the deeper issues in the language. But perhaps that's t

(rant) That's nice, but also rather self-congratulatory. I was expecting some kind of acknowledgment of the deeper issues in the language. But perhaps that's the central issue, that the language is perfect in their eyes. I'm the problem. Well, okay then. I can't recommend the language, because of its type system, the error handling, the unsafe concurrency, the simplistic syntax, nil, default zero, and a large number of mainstream packages are abandoned. I now use Rust as my main language. It has a flourishing ecosystem and is visionary in so many ways that Go is not. Put more pointedly, I'm sure Go had its day, when it was competing with PHP as a backend language.

zik 3y ago
I don't think this comment really contributes to the discussion. It comes across as Rust advocacy without having any tangible points to make. First paragraph: "I don't like it". Second paragraph: snide comment. Third paragraph: "I don't like it". Fourth paragraph: "Rust is better". Fifth paragraph: snide comment.
- ncruces 3y ago
  There's one thing in there worth discussing IMO: the focus on zero values (incl. nil). That's the Go mistake, the one that causes most of the issues for the intended audience, the one that can't really be fixed. It's a shame Pike doesn't really discuss this, even if it's hopeless now. The rest is just people projecting and self-selecting outside of the intended audience. Don't like it, don't use it, we don't all need to agree with you.
  - campbel 3y ago
    Zero values are fine, some benefits, some drawbacks. Workarounds exist for when you need to identify the difference between unset and zero.
    - FridgeSeal 3y ago
      No they’re not, they’re a horrible decision, and some of the “solutions” I’ve seen for working around them are band-aid-code at best. The design decisions around zero values infect protobufs too, and they suck to work around. The fact that an empty message can successfully deserialise into any valid protobuf is an insane decision and should have been thrown out long ago.
      - znkr 3y ago
        > The fact that an empty message can successfully deserialise into any valid protobuf is an insane decision and should have been thrown out long ago The reason for this is that the protobuf wire format is designed for very high entropy: It contains only a minimal amount of metadata and consists mostly of data. This means you can deserialize most wire messages as a different message. This is a tradeoff: smaller message size for loss of schema information. This just means that schemas need to be handled at a higher level. This tradeoff makes some sense if you process millions of protos per second. BTW: Dismissing a tradeoff like this as insane is derogatory. You can do better
      - campbel 3y ago
        This is the main drawback I also experience with zero values, knowing whether something was set or its the zero value. Like I said, there are some work arounds, buts its a tradeoff. Perhaps its a tradeoff you don't like.
    - euroderf 3y ago
      > when you need to identify the difference between unset and zero. Use pointer variables ? Works 4 me.
      - campbel 3y ago
        Also what I do. You could theoretically also create your own type that manages deserialization and includes an "is_set" field.
        3y ago
- cangeroo 3y ago
  I was trying to say that: by paragraph: 1) The article should have acknowledged the issues that a wide part of the community are experiencing. 2) I accept that I'm the problem. But then I must leave. 3) The consequence of their attitude is that I cannot recommend the language anymore. I used to be excited about it, and that disappointment makes me angry. 4) If only Go was trying to be better. Rust is just an example of the visionary leadership that I expect from Go. I want go to be visionary! Because they have some things right, like fast compiliation, cross compilation, simple syntax, and a focus on simple concurrency. But it's like those ideas never developed. 5) Rust is a counterexample, that a language can be visionary, without giving up on its fundamentals. 6) Acknowledgment that Go was the best solution at a time. But also that the time seems to have passed.
satvikpendem 3y ago
I agree, I've used Go before I learned Rust and seeing the differences really changed my mind. I used to use OCaml before so I understood the value of Option and Result types over try/catch and `nil`, but I used Go because it was easy. However, that easiness comes at a cost, namely maintenance over time. You want to get it right the first time around and not have to face challenges later on. Not to be flippant, but I've often heard Go described as taking the programming language advances over the last 50 years and throwing them away.
- bb88 3y ago
  > but I've often heard Go described as taking the programming language advances over the last 50 years and throwing them away. That's by design, right? Go is very opinionated. They looked at other languages that they hated, e.g., C++/Java and didn't want to replicate them. But then adding their own mistakes along the way. The brand new mistake that surprised me was that nil does not always equal nil. So just checking for nil is not enough sometimes, one has to "cast" as nil to the type you're expecting. And goland doesn't catch it. C++/Java/Python/C, null always equals null. But not in golang. shrug The primary issue I have is that go doesn't make it very easy to write unit tests. You have to use interfaces everywhere just to inject your mocks. I feel like that's the big mistake they made. Any new language needs to make it super easy to write unit tests without forcing major design decisions that affects development.
  - earthboundkid 3y ago
    I’ve never seen a real bug from the interface nil != concrete nil thing. When does it come up?
    - lenkite 3y ago
      People have raised dozens of issues on the Go tracker because they got stumped by this. You don't really need to look hard on a search engine to see thousands of questions/issues. If you don't believe me, take a project like k8s and starting from its inception, you can see dozens of issues where people have to explain function returns a nil interface and not a nil value. This is explained a stupendous number of times. Now repeat this for thousands of Go projects. Of-course you can claim this is not an issue in the same way that anyone can claim that buffer overflows are not an issue in C/C++ for "real" programmers.
demizer 3y ago
All these plan9 scientists love their own brand. I started using Go in 2012, but after they killed deps.dev I gave it up. Some years later when I wanted to get work done at work I tried to introduce it on my team and another engineer spent a good amount of time looking into the language and listed all the reasons why it sucked, and he was right. The main takeaway was, yeah it's simple, but it does silly things that makes it a pain to use (error handling and unused imports) to name a few. I personally like the error handling but hated the type system.
- cwbriscoe 3y ago
  Just run goimports on save then there would be no issue with unused imports. I would take go's error handling over try/catch any day of the week.
  - cangeroo 3y ago
    You then have to reimport. Every time when you comment out code. I guess the compiler authors don't comment out code? And it's intentionally not optional on the compiler. So you have to modify the source and compile your own compiler to disable it. It's ridiculously sadistic to their users.
    - scns 3y ago
      Is it possible to comment out the imports?
    - cwbriscoe 3y ago
      If you use goimports (which also runs gofmt) after commenting out code, you just have to save your file and it will remove any unused imports. There is no reason to go to the extreme extent of compiling your own modified version of go just for this. The tooling is already there.
      - alainx277 3y ago
        The OP mentions that the reimport is the problem (in response to your tooling suggestion). If you comment out code while testing the imports are auto-removed. When you uncomment you need add the correct imports again.
AnimalMuppet 3y ago
I think you're misreading the article. Pike doesn't say that the language is perfect at all. He says that they did better on the community aspects, but they admit the flaws in the language.
SPBS 3y ago
> First, what's good and bad in a programming language is largely a matter of opinion rather than fact, despite the certainty with which many people argue about even the most trivial features of Go or any other language. > Also, there has already been plenty of discussion about things such as where the newlines go, how nil works, using upper case for export, garbage collection, error handling, and so on. There are certainly things to say there, but little that hasn't already been said.
hardwaregeek 3y ago
I agree with the programming language sentiments, but in its defense, Go is very much a language for and by people who don't care about programming languages. I mean this in the nicest way. Rob Pike doesn't care that the concurrency is unsafe or that nil is the billion dollar mistake. Neither do most users of Go. Does that make Go a good language? No. But that's besides the point. It's a convenient, good enough language combined with a compelling set of tools that make it easy to use. It's the crocs of programming languages.
- bborud 3y ago
  Well, some of us kind of care, but not enough to pay the price of ending up using a languages where people care more about language design than writing programs. Go is very much a language for getting things done rather than winning beauty contests. And it has proven itself as a productive language. I've worked with perhaps half a dozen real "language enthusiasts" in my time. People who spend lots of time obsessing over "perfect" language design and non-mainstream languages. People who never stick to a language for more than a year or three, who insist everyone else accommodate their current fascination with some language, and who leave behind codebases full of code that will be hard to maintain because they are a patchwork of languages. Not caring that the organization then has to take the time both train people in thoselanguages and ensure they have enough people experienced with the language to be able to use a portion of their time to train newbies. On a few occasions I actually researched their job history and found that these people had a tendency to make a lot of noise, but produce very little of consequence. They'd find jobs at the outskirts of projects where it would be easier to indulge in their interests without clashing with the principals. Most of their code would be gone just months after they left the position. My advice is that if you care about building stuff, don't hire language enthusiasts.
  - jtasdlfj234 3y ago
    Okay, circling back here. So your position is that nil safety would reduce the value of Go's "getting things done"? As someone who uses Go in production, I don't agree at all.
qaq 3y ago
I am pretty sure Go is not going anywhere. Pretty much anyone can read Go and understand what is going on which is def. not true for Rust. It's very possible that if Mojo pans out it might be the "mass market" lang. that brings a lot of the Rust goodness to the avg. dev.
- blablak 3y ago
  > Pretty much anyone can read Go and understand what is going on which is def. not true for Rust. Why do you think so? If you don't know what `defer` execution order is LIFO, you cannot read code with multiple `defer`'s. IMO, Rust just have more things like `defer`
jonathanstrange 3y ago
I've learned Rust but Rust's user community makes it impossible for me to like the language. This hasn't changed over the years, if at all it has gotten worse. If I need high integrity and safety, I'll use Ada or even Ada/Spark with formal verification. For anything else, Go leads to much more productivity than Rust. In my opinion, Rust is a prime example of overengineering (just like C++).
- blablak 3y ago
  What is wrong with Rust's user community?
wg0 3y ago
Not a rhetorical question. Genuine question. I don't know so I'm asking question. nil/null is really problematic, true. But how languages handle this otherwise? Is it that program must be statically analyzed to ensure that no nil/null path exists or there are other solutions as well? Would be thankful for any pointers.
- tubthumper8 3y ago
  The core problem with null/nil in Go (and Java) is that it is not modeled in the type system. In Java, any reference (which is most types) can be secretly null which is not tracked by the compiler. Go one-ups this and has the same concept for pointers but also introduces a second kind of nil (so nil doesn't always equal nil [0]). All approaches come down to modeling it in the type system instead of it being invisible. One approach is modeling it as a sum type [1]. A sum type is a type that models when it's one thing OR another thing. Like it's "a OR b". "null OR not null". So a lot of languages have a type called `Maybe<T>` which models it's a "T OR Nothing". Different languages use different names (like `Option` [2]) but it's the same idea. The key is that null is now modeled using normal / non-special / user-defined types so that it's no longer invisible. Another approach is using so-called "nullable types" and flow typing [3]. For example, `Foo` is a normal type and `Foo?` is a nullable version of `Foo`. You're not allowed to pass a `Foo?` to a function that requires a `Foo` (the other way is fine). When doing a null check, the compiler narrows a `Foo?` to a `Foo` inside the non-null branch of the check. This is one capability of a more general compiler/language technique sometimes referred to as "narrowing" [4] or "static flow analysis" [5] [0] https://yourbasic.org/golang/gotcha-why-nil-error-not-equal-nil/ https://yourbasic.org/golang/gotcha-why-nil-error-not-equal-... [1] https://en.m.wikipedia.org/wiki/Tagged_union https://en.m.wikipedia.org/wiki/Tagged_union [2] https://doc.rust-lang.org/std/option/index.html https://doc.rust-lang.org/std/option/index.html [3] https://kotlinlang.org/docs/null-safety.html https://kotlinlang.org/docs/null-safety.html [4] https://www.typescriptlang.org/docs/handbook/2/narrowing.html https://www.typescriptlang.org/docs/handbook/2/narrowing.htm... [5] https://learn.microsoft.com/en-us/dotnet/csharp/nullable-references https://learn.microsoft.com/en-us/dotnet/csharp/nullable-ref...
  - wg0 3y ago

zik 3y ago

I don't think this comment really contributes to the discussion. It comes across as Rust advocacy without having any tangible points to make. First paragraph: "I don't like it". Second paragraph: snide comment. Third paragraph: "I don't like it". Fourth paragraph: "Rust is better". Fifth paragraph: snide comment.

ncruces 3y ago
There's one thing in there worth discussing IMO: the focus on zero values (incl. nil). That's the Go mistake, the one that causes most of the issues for the intended audience, the one that can't really be fixed. It's a shame Pike doesn't really discuss this, even if it's hopeless now. The rest is just people projecting and self-selecting outside of the intended audience. Don't like it, don't use it, we don't all need to agree with you.
- campbel 3y ago
  Zero values are fine, some benefits, some drawbacks. Workarounds exist for when you need to identify the difference between unset and zero.
  - FridgeSeal 3y ago
    No they’re not, they’re a horrible decision, and some of the “solutions” I’ve seen for working around them are band-aid-code at best. The design decisions around zero values infect protobufs too, and they suck to work around. The fact that an empty message can successfully deserialise into any valid protobuf is an insane decision and should have been thrown out long ago.
    - znkr 3y ago
      > The fact that an empty message can successfully deserialise into any valid protobuf is an insane decision and should have been thrown out long ago The reason for this is that the protobuf wire format is designed for very high entropy: It contains only a minimal amount of metadata and consists mostly of data. This means you can deserialize most wire messages as a different message. This is a tradeoff: smaller message size for loss of schema information. This just means that schemas need to be handled at a higher level. This tradeoff makes some sense if you process millions of protos per second. BTW: Dismissing a tradeoff like this as insane is derogatory. You can do better
    - campbel 3y ago
      This is the main drawback I also experience with zero values, knowing whether something was set or its the zero value. Like I said, there are some work arounds, buts its a tradeoff. Perhaps its a tradeoff you don't like.
  - euroderf 3y ago
    > when you need to identify the difference between unset and zero. Use pointer variables ? Works 4 me.
    - campbel 3y ago
      Also what I do. You could theoretically also create your own type that manages deserialization and includes an "is_set" field.
      - 3y ago
cangeroo 3y ago
I was trying to say that: by paragraph: 1) The article should have acknowledged the issues that a wide part of the community are experiencing. 2) I accept that I'm the problem. But then I must leave. 3) The consequence of their attitude is that I cannot recommend the language anymore. I used to be excited about it, and that disappointment makes me angry. 4) If only Go was trying to be better. Rust is just an example of the visionary leadership that I expect from Go. I want go to be visionary! Because they have some things right, like fast compiliation, cross compilation, simple syntax, and a focus on simple concurrency. But it's like those ideas never developed. 5) Rust is a counterexample, that a language can be visionary, without giving up on its fundamentals. 6) Acknowledgment that Go was the best solution at a time. But also that the time seems to have passed.

satvikpendem 3y ago

I agree, I've used Go before I learned Rust and seeing the differences really changed my mind. I used to use OCaml before so I understood the value of Option and Result types over try/catch and `nil`, but I used Go because it was easy. However, that easiness comes at a cost, namely maintenance over time. You want to get it right the first time around and not have to face challenges later on. Not to be flippant, but I've often heard Go described as taking the programming language advances over the last 50 years and throwing them away.

bb88 3y ago
> but I've often heard Go described as taking the programming language advances over the last 50 years and throwing them away. That's by design, right? Go is very opinionated. They looked at other languages that they hated, e.g., C++/Java and didn't want to replicate them. But then adding their own mistakes along the way. The brand new mistake that surprised me was that nil does not always equal nil. So just checking for nil is not enough sometimes, one has to "cast" as nil to the type you're expecting. And goland doesn't catch it. C++/Java/Python/C, null always equals null. But not in golang. shrug The primary issue I have is that go doesn't make it very easy to write unit tests. You have to use interfaces everywhere just to inject your mocks. I feel like that's the big mistake they made. Any new language needs to make it super easy to write unit tests without forcing major design decisions that affects development.
- earthboundkid 3y ago
  I’ve never seen a real bug from the interface nil != concrete nil thing. When does it come up?
  - lenkite 3y ago
    People have raised dozens of issues on the Go tracker because they got stumped by this. You don't really need to look hard on a search engine to see thousands of questions/issues. If you don't believe me, take a project like k8s and starting from its inception, you can see dozens of issues where people have to explain function returns a nil interface and not a nil value. This is explained a stupendous number of times. Now repeat this for thousands of Go projects. Of-course you can claim this is not an issue in the same way that anyone can claim that buffer overflows are not an issue in C/C++ for "real" programmers.

demizer 3y ago

All these plan9 scientists love their own brand. I started using Go in 2012, but after they killed deps.dev I gave it up. Some years later when I wanted to get work done at work I tried to introduce it on my team and another engineer spent a good amount of time looking into the language and listed all the reasons why it sucked, and he was right. The main takeaway was, yeah it's simple, but it does silly things that makes it a pain to use (error handling and unused imports) to name a few. I personally like the error handling but hated the type system.

cwbriscoe 3y ago
Just run goimports on save then there would be no issue with unused imports. I would take go's error handling over try/catch any day of the week.
- cangeroo 3y ago
  You then have to reimport. Every time when you comment out code. I guess the compiler authors don't comment out code? And it's intentionally not optional on the compiler. So you have to modify the source and compile your own compiler to disable it. It's ridiculously sadistic to their users.
  - scns 3y ago
    Is it possible to comment out the imports?
  - cwbriscoe 3y ago
    If you use goimports (which also runs gofmt) after commenting out code, you just have to save your file and it will remove any unused imports. There is no reason to go to the extreme extent of compiling your own modified version of go just for this. The tooling is already there.
    - alainx277 3y ago
      The OP mentions that the reimport is the problem (in response to your tooling suggestion). If you comment out code while testing the imports are auto-removed. When you uncomment you need add the correct imports again.

AnimalMuppet 3y ago

I think you're misreading the article. Pike doesn't say that the language is perfect at all. He says that they did better on the community aspects, but they admit the flaws in the language.

SPBS 3y ago

> First, what's good and bad in a programming language is largely a matter of opinion rather than fact, despite the certainty with which many people argue about even the most trivial features of Go or any other language. > Also, there has already been plenty of discussion about things such as where the newlines go, how nil works, using upper case for export, garbage collection, error handling, and so on. There are certainly things to say there, but little that hasn't already been said.

hardwaregeek 3y ago

I agree with the programming language sentiments, but in its defense, Go is very much a language for and by people who don't care about programming languages. I mean this in the nicest way. Rob Pike doesn't care that the concurrency is unsafe or that nil is the billion dollar mistake. Neither do most users of Go. Does that make Go a good language? No. But that's besides the point. It's a convenient, good enough language combined with a compelling set of tools that make it easy to use. It's the crocs of programming languages.

bborud 3y ago
Well, some of us kind of care, but not enough to pay the price of ending up using a languages where people care more about language design than writing programs. Go is very much a language for getting things done rather than winning beauty contests. And it has proven itself as a productive language. I've worked with perhaps half a dozen real "language enthusiasts" in my time. People who spend lots of time obsessing over "perfect" language design and non-mainstream languages. People who never stick to a language for more than a year or three, who insist everyone else accommodate their current fascination with some language, and who leave behind codebases full of code that will be hard to maintain because they are a patchwork of languages. Not caring that the organization then has to take the time both train people in thoselanguages and ensure they have enough people experienced with the language to be able to use a portion of their time to train newbies. On a few occasions I actually researched their job history and found that these people had a tendency to make a lot of noise, but produce very little of consequence. They'd find jobs at the outskirts of projects where it would be easier to indulge in their interests without clashing with the principals. Most of their code would be gone just months after they left the position. My advice is that if you care about building stuff, don't hire language enthusiasts.
- jtasdlfj234 3y ago
  Okay, circling back here. So your position is that nil safety would reduce the value of Go's "getting things done"? As someone who uses Go in production, I don't agree at all.

qaq 3y ago

I am pretty sure Go is not going anywhere. Pretty much anyone can read Go and understand what is going on which is def. not true for Rust. It's very possible that if Mojo pans out it might be the "mass market" lang. that brings a lot of the Rust goodness to the avg. dev.

blablak 3y ago
> Pretty much anyone can read Go and understand what is going on which is def. not true for Rust. Why do you think so? If you don't know what `defer` execution order is LIFO, you cannot read code with multiple `defer`'s. IMO, Rust just have more things like `defer`

jonathanstrange 3y ago

I've learned Rust but Rust's user community makes it impossible for me to like the language. This hasn't changed over the years, if at all it has gotten worse. If I need high integrity and safety, I'll use Ada or even Ada/Spark with formal verification. For anything else, Go leads to much more productivity than Rust. In my opinion, Rust is a prime example of overengineering (just like C++).

blablak 3y ago
What is wrong with Rust's user community?

wg0 3y ago

Not a rhetorical question. Genuine question. I don't know so I'm asking question. nil/null is really problematic, true. But how languages handle this otherwise? Is it that program must be statically analyzed to ensure that no nil/null path exists or there are other solutions as well? Would be thankful for any pointers.

tubthumper8 3y ago
The core problem with null/nil in Go (and Java) is that it is not modeled in the type system. In Java, any reference (which is most types) can be secretly null which is not tracked by the compiler. Go one-ups this and has the same concept for pointers but also introduces a second kind of nil (so nil doesn't always equal nil [0]). All approaches come down to modeling it in the type system instead of it being invisible. One approach is modeling it as a sum type [1]. A sum type is a type that models when it's one thing OR another thing. Like it's "a OR b". "null OR not null". So a lot of languages have a type called `Maybe<T>` which models it's a "T OR Nothing". Different languages use different names (like `Option` [2]) but it's the same idea. The key is that null is now modeled using normal / non-special / user-defined types so that it's no longer invisible. Another approach is using so-called "nullable types" and flow typing [3]. For example, `Foo` is a normal type and `Foo?` is a nullable version of `Foo`. You're not allowed to pass a `Foo?` to a function that requires a `Foo` (the other way is fine). When doing a null check, the compiler narrows a `Foo?` to a `Foo` inside the non-null branch of the check. This is one capability of a more general compiler/language technique sometimes referred to as "narrowing" [4] or "static flow analysis" [5] [0] https://yourbasic.org/golang/gotcha-why-nil-error-not-equal-nil/ https://yourbasic.org/golang/gotcha-why-nil-error-not-equal-... [1] https://en.m.wikipedia.org/wiki/Tagged_union https://en.m.wikipedia.org/wiki/Tagged_union [2] https://doc.rust-lang.org/std/option/index.html https://doc.rust-lang.org/std/option/index.html [3] https://kotlinlang.org/docs/null-safety.html https://kotlinlang.org/docs/null-safety.html [4] https://www.typescriptlang.org/docs/handbook/2/narrowing.html https://www.typescriptlang.org/docs/handbook/2/narrowing.htm... [5] https://learn.microsoft.com/en-us/dotnet/csharp/nullable-references https://learn.microsoft.com/en-us/dotnet/csharp/nullable-ref...
- wg0 3y ago