5 ms·

Step by step, Go is now learning the hard lessons every other language has learned over the last 20 years. The fact that despite their best efforts, their propo

Step by step, Go is now learning the hard lessons every other language has learned over the last 20 years. The fact that despite their best efforts, their propositions look like everone else is a surprisingly refreshing affirmation of status quo.

somekyle2 3mo ago
I respect "we're going to try not to add features until we have to and have a plan that we like" as an approach to a practical language, vs "we're going to plan to support everything normal modern languages have". It isn't the best approach to language design in theory, but they did try to build a language that isn't impossible to change, and to be fair the mix of language features they chose didn't have any good more successful examples to borrow from, so waiting for enough practical experience to make the relevant trade-offs on practical grounds isn't the bare naivety that some people seem to take it as.
- vlovich123 3mo ago
  The problem is that when you don’t have a cohesive picture of how things fit from the outside, it becomes really hard to evolve the language in a way that makes sense and doesn’t break existing code. Data storage and languages share this unique property that the past impacts your decisions and what makes is possible in the future in a way pure logic doesn’t struggle with.
  - Sleaker 3mo ago
    And this is -exactly- one of the reasons they didn't accept or continue with a sane proposal for more ergonomic error handling. I like go, but this was the one thing that I kept feeling like I was wasting so much time dealing with.
    - win311fwg 3mo ago
      Presumably you are referring to https://github.com/golang/go/discussions/71460 https://github.com/golang/go/discussions/71460? While the proposed slightly reduced the token count, saving the average typist approximately 1 second of time if they don't have an autocomplete editor that types it for them, it doesn't change anything about the mental model where the real time is actually spent, so is it really sane? Worse, it is dependent on the error type, but errors are not always of the error type. Not even Go's own standard library consistently returns errors using the error type, never mind all the other crazy things you find in the wild. That doesn't sound sane at all. It is true that Go not having any real kind of superpositions or side channels makes stealing popular ideas from other languages impossible (it already has both well-known error handling methods that do not depend on those properties). But a sane proposal would be designed with that in mind.
      - ndriscoll 3mo ago
        Reducing syntactic noise is about legibility, not writing ease. The error boilerplate as it exists interrupts the actual logic and makes most of your code read as sad paths that might never execute. Of course if you want something less specific to errors, we already have do-notation as an excellent example to look at. And you can't say that's more complex for users than what they did with iterators.
        sethammons 3mo ago
        > The error boilerplate as it exists interrupts the actual logic and makes most of your code read as sad paths that might never execute. Yes! You have to think through and account for edge cases. "Might not" is the same as "might." Those branches might execute. I have been on many projects over 25 years of software development. Projects that take error handling seriously tend to be better all around. Happy-path coding is naive.
        ndriscoll 3mo ago
        In the overwhelming majority of cases, you want to trivially send the error up the stack to be handled, so you don't want to incur the noise in the middle of your business logic (and indeed doing so obscures the times when error handling is non-trivial!). e.g. Scala handles all error cases with compile time checking (in fact it tends to take error handling much more seriously), but you don't have to write (or read) the trivial case.
- DarkNova6 3mo ago
  I totally get that. Java is my favorite language for exactly that reason. They are a deliberate "late mover language" and adopt what other languages have proven right. But looking at how adamant Go used to be on the whole "No Generics" stance and the path and the troubles they are having... it all seemes so preventable?
  - farfatched 3mo ago
    I think it was. Go without generics was ok. I say that as a fan of generics in other languages. There is room for languages with simpler feature sets. It takes a strong leader (and the good and bad that comes with that) to continue to deny features. Go had that. Does it still? (I genuinely don't know.) I'm not sure what Go's value proposition is now. Developers can't pick it up in a week, as it used to be. Maybe that's okay too, since Go already has critical mass.
    - ako 3mo ago
      Go value proposition for me, when developing with Claude code: 1) fast compilation times, faster iterations, 2) user friendly to install, one single binary per platform, 3) feels safer than JavaScript/typescript, which have too many npm vulnerabilities. Go comes with more functionality included, less need to use 3rd party libraries.
      - farfatched 3mo ago
        That's fair. In addition, I'd add the great compatibility guarantees, and a community that makes easy-to-learn libraries.
    - LVB 3mo ago
      I don’t feel like the learning curve has shifted dramatically for mainstream development. Besides generics—which tend to not show up that often in app code even now—I can’t think of any substantial language change since I Iearned it in 2014. (Well, modules, but that’s more tooling.) Where I do see the shock is jumping to def of a std lib function and landing in indecipherable type soup.
- flanked-evergl 3mo ago
  What makes these features unnecessary in 2024 but necessary in 2026?
deleted 3mo ago
[deleted]
gritzko 3mo ago
Java started as a language to write apps on the Internet (applets). Then, it evolved into an elephantine corporate-focused language, because that's where the money is. I remember those Java applets that took minutes to load. The Web was taken over by JavaScript instead, which was famously coded in ten days. Go used very particular shortcuts to make its GC'd runtime lightweight enough and the language simple enough. But, due to Conway's law or something else, it was destined to become a corporate-focused elephantine language, gradually. I remember 10 years ago I believed that Go lacked something like STL. Later I changed my opinion cause I started to realize how much overhead red-black trees and suchlikes introduce. Especially in GC'd systems. This abstraction Jenga may indeed look shockingly absurd when you see all the moves in the system, not just your layer. In performance-critical cases, I personally use ABC, a C dialect with solid containers. Those are basically chunks of RAM with fixed-bit-layout records in them. Vectors, hash maps and hash sets, heaps and queues are all just arrays. If we only needed that, we might have stayed with C. Solid containers require no malloc() and no GC. Can mmap them and you have a database. Can send them over the network as-is. That is the ultimate 80/20 thing here. LMDB is another example. But if you keep adding features, 80/20 is no more and your Go becomes an uglier Java or Rust.
bheadmaster 3mo ago
Language is more than just its syntax and features. The most important "features" of Go are fast compilation, orthogonality of features, and easy development. Their propositions may "look like everyone else" if you're only looking at surface syntax, but there's a reason why it took 10 years to design an acceptable generics proposal, and the result is that compiling generic-heavy code is almost as fast as compiling plain Go. Go being strict about features it accepts is not an ideological thing, but a practical one. If Go could have all the features in the world while still being easy to use, fast to compile, and internally coherent, it would. But it can't (see: C++, C#, Python).
hwc 3mo ago
On the other hand, I've found that for every real-world application I've written in Go, I have not found myself missing any of the containers C++ has had since 2003. I didn't really ever need generics either. I only use them to make it to make it clear which functions don't rely on specific properties of the type they operate on. Yes, there are occasionally really good reasons to use an ordered map or a priority queue, but I haven't needed either in years.
- JamesSwift 3mo ago
  Most generics code is for library authors. Having generics allows you to write ergonomic algorithms for eg channels instead of forcing every single app developer to reinvent the wheel and run into the same footguns
elktown 3mo ago
Or it’s just people with different opinions that took charge. I find it funny reading sometimes how my country learned to conform on something that was previously a bit unique and people are like ”yeah, even they figured out it doesn’t work!”. No, you dingus, the people that wanted to conform were just elected. It worked perfectly fine otherwise.

somekyle2 3mo ago

I respect "we're going to try not to add features until we have to and have a plan that we like" as an approach to a practical language, vs "we're going to plan to support everything normal modern languages have". It isn't the best approach to language design in theory, but they did try to build a language that isn't impossible to change, and to be fair the mix of language features they chose didn't have any good more successful examples to borrow from, so waiting for enough practical experience to make the relevant trade-offs on practical grounds isn't the bare naivety that some people seem to take it as.

vlovich123 3mo ago
The problem is that when you don’t have a cohesive picture of how things fit from the outside, it becomes really hard to evolve the language in a way that makes sense and doesn’t break existing code. Data storage and languages share this unique property that the past impacts your decisions and what makes is possible in the future in a way pure logic doesn’t struggle with.
- Sleaker 3mo ago
  And this is -exactly- one of the reasons they didn't accept or continue with a sane proposal for more ergonomic error handling. I like go, but this was the one thing that I kept feeling like I was wasting so much time dealing with.
  - win311fwg 3mo ago
    Presumably you are referring to https://github.com/golang/go/discussions/71460 https://github.com/golang/go/discussions/71460? While the proposed slightly reduced the token count, saving the average typist approximately 1 second of time if they don't have an autocomplete editor that types it for them, it doesn't change anything about the mental model where the real time is actually spent, so is it really sane? Worse, it is dependent on the error type, but errors are not always of the error type. Not even Go's own standard library consistently returns errors using the error type, never mind all the other crazy things you find in the wild. That doesn't sound sane at all. It is true that Go not having any real kind of superpositions or side channels makes stealing popular ideas from other languages impossible (it already has both well-known error handling methods that do not depend on those properties). But a sane proposal would be designed with that in mind.
    - ndriscoll 3mo ago
      Reducing syntactic noise is about legibility, not writing ease. The error boilerplate as it exists interrupts the actual logic and makes most of your code read as sad paths that might never execute. Of course if you want something less specific to errors, we already have do-notation as an excellent example to look at. And you can't say that's more complex for users than what they did with iterators.
      - sethammons 3mo ago
        > The error boilerplate as it exists interrupts the actual logic and makes most of your code read as sad paths that might never execute. Yes! You have to think through and account for edge cases. "Might not" is the same as "might." Those branches might execute. I have been on many projects over 25 years of software development. Projects that take error handling seriously tend to be better all around. Happy-path coding is naive.
        ndriscoll 3mo ago
        In the overwhelming majority of cases, you want to trivially send the error up the stack to be handled, so you don't want to incur the noise in the middle of your business logic (and indeed doing so obscures the times when error handling is non-trivial!). e.g. Scala handles all error cases with compile time checking (in fact it tends to take error handling much more seriously), but you don't have to write (or read) the trivial case.
DarkNova6 3mo ago
I totally get that. Java is my favorite language for exactly that reason. They are a deliberate "late mover language" and adopt what other languages have proven right. But looking at how adamant Go used to be on the whole "No Generics" stance and the path and the troubles they are having... it all seemes so preventable?
- farfatched 3mo ago
  I think it was. Go without generics was ok. I say that as a fan of generics in other languages. There is room for languages with simpler feature sets. It takes a strong leader (and the good and bad that comes with that) to continue to deny features. Go had that. Does it still? (I genuinely don't know.) I'm not sure what Go's value proposition is now. Developers can't pick it up in a week, as it used to be. Maybe that's okay too, since Go already has critical mass.
  - ako 3mo ago
    Go value proposition for me, when developing with Claude code: 1) fast compilation times, faster iterations, 2) user friendly to install, one single binary per platform, 3) feels safer than JavaScript/typescript, which have too many npm vulnerabilities. Go comes with more functionality included, less need to use 3rd party libraries.
    - farfatched 3mo ago
      That's fair. In addition, I'd add the great compatibility guarantees, and a community that makes easy-to-learn libraries.
  - LVB 3mo ago
    I don’t feel like the learning curve has shifted dramatically for mainstream development. Besides generics—which tend to not show up that often in app code even now—I can’t think of any substantial language change since I Iearned it in 2014. (Well, modules, but that’s more tooling.) Where I do see the shock is jumping to def of a std lib function and landing in indecipherable type soup.
flanked-evergl 3mo ago
What makes these features unnecessary in 2024 but necessary in 2026?

deleted 3mo ago

[deleted]

gritzko 3mo ago

Java started as a language to write apps on the Internet (applets). Then, it evolved into an elephantine corporate-focused language, because that's where the money is. I remember those Java applets that took minutes to load. The Web was taken over by JavaScript instead, which was famously coded in ten days. Go used very particular shortcuts to make its GC'd runtime lightweight enough and the language simple enough. But, due to Conway's law or something else, it was destined to become a corporate-focused elephantine language, gradually. I remember 10 years ago I believed that Go lacked something like STL. Later I changed my opinion cause I started to realize how much overhead red-black trees and suchlikes introduce. Especially in GC'd systems. This abstraction Jenga may indeed look shockingly absurd when you see all the moves in the system, not just your layer. In performance-critical cases, I personally use ABC, a C dialect with solid containers. Those are basically chunks of RAM with fixed-bit-layout records in them. Vectors, hash maps and hash sets, heaps and queues are all just arrays. If we only needed that, we might have stayed with C. Solid containers require no malloc() and no GC. Can mmap them and you have a database. Can send them over the network as-is. That is the ultimate 80/20 thing here. LMDB is another example. But if you keep adding features, 80/20 is no more and your Go becomes an uglier Java or Rust.

bheadmaster 3mo ago

Language is more than just its syntax and features. The most important "features" of Go are fast compilation, orthogonality of features, and easy development. Their propositions may "look like everyone else" if you're only looking at surface syntax, but there's a reason why it took 10 years to design an acceptable generics proposal, and the result is that compiling generic-heavy code is almost as fast as compiling plain Go. Go being strict about features it accepts is not an ideological thing, but a practical one. If Go could have all the features in the world while still being easy to use, fast to compile, and internally coherent, it would. But it can't (see: C++, C#, Python).

hwc 3mo ago

On the other hand, I've found that for every real-world application I've written in Go, I have not found myself missing any of the containers C++ has had since 2003. I didn't really ever need generics either. I only use them to make it to make it clear which functions don't rely on specific properties of the type they operate on. Yes, there are occasionally really good reasons to use an ordered map or a priority queue, but I haven't needed either in years.

JamesSwift 3mo ago
Most generics code is for library authors. Having generics allows you to write ergonomic algorithms for eg channels instead of forcing every single app developer to reinvent the wheel and run into the same footguns

elktown 3mo ago

Or it’s just people with different opinions that took charge. I find it funny reading sometimes how my country learned to conform on something that was previously a bit unique and people are like ”yeah, even they figured out it doesn’t work!”. No, you dingus, the people that wanted to conform were just elected. It worked perfectly fine otherwise.