5 ms·

This is a pretty good vignette of how Go is designed. "Users don't need this feature (immutability, polymorphism, etc.), let's not include it. Ah crap, turns ou

by wyager 4y ago

This is a pretty good vignette of how Go is designed. "Users don't need this feature (immutability, polymorphism, etc.), let's not include it. Ah crap, turns out we actually need it for a core language feature. Is there a lesson we can take away here? Nah, just make an ad-hoc implementation of the functionality in this one place."

Groxx 4y ago
"X for me but not for thee" is very much the vibe Go gives me, yeah. I mean, I have completely replaced my adhoc Python use with it and I'm much happier. But it's terrifying to use to build large systems.
- ikiris 4y ago
  Part of it is that "large systems" are almost all combinations of small systems with proto boundaries, so it's not much of an actual risk unless you're making giant monolith code.
  - andrewflnr 4y ago
    "Proto" meaning protobuffers?
    - konart 4y ago
      I think it rather "communication via some protocol" in general. In other words if we are not talking about giant monolith - we have N small systems to begin with.
      - ikiris 4y ago
        I meant specifically protobuffers in that case, but sure, that works.
avgcorrection 4y ago
For what it’s worth it sounds no worse than Java: you have immutable strings but you have no way to enforce that you can’t modify something that you have recieved, which is why the underlying char array for a string has to be defensively copied if the user asks for `asArray()` or whatever it is. Strings being immutable doesn’t seem like a special case, though. The underlying mutable array is just encapsulated, which is something that you can implement yourself. (But reflection… maybe you can break the rules with reflection.)
- Groxx 4y ago
  No worse, possibly better, yeah. In a fair number of ways I prefer it over Java, e.g. reflection being so limited makes code dramatically easier to understand with confidence, because a large number of common reflection shenanigans in Java simply can't exist at all in Go. The clean slate and lack of inheritance also means the incredible towers of inheritance insanity simply don't exist - it's wonderful. But I work on a pretty big system. The near-inability to both efficiently and safely abstract things is a big problem, and it'll be years before mature uses of generics truly start to address that... when it even can. Then I miss Java quite a lot. Or maybe more accurately Kotlin. Or sophisticated code generation and bytecode modification. Or MAT. Or...
- Alphaeus 4y ago
  I don't think you can reflect onto the standard library anymore, with the recent "strong encapsulation".
- saagarjha 4y ago
  Java gets a pass because it was early. Go had time to learn from its mistakes and…just refused to do so.
klodolph 4y ago
Const is a hard language feature to design well. There are a lot of pitfalls in the way const is used in C++ and TypeScript (I’m including “readonly” in the discussion). Rust gets it right, but Rust is relatively complicated. The languages which are most similar to Go are Java and C#, both of which also lack const types, or have a very limited version of constness.
- TwentyPosts 4y ago
  What are some of these pitfalls in C++'s const design? I assume the issue is that it's difficult to guarantee const correctness as long as you have the ability to fiddle with pointers? Function signatures showing when a parameter gets modified and when not (such as in Rust, or even in properly const-speckled C++) would benefit Go, but I'm not sure how difficult it'd be to implement that. I could see it being difficult considering that one of Go's core features (slices) results in opaque and overlapping memory ownership.
cdogl 4y ago
I don’t think you can fairly call go’s generics an “ad-hoc” implementation. They added syntax for it.
- jeffparsons 4y ago
  I think in this context "ad hoc" refers to the context in which that syntax was added. IIRC the original creators were against generics ever being added to Golang, so they wouldn't have thought about their eventual introduction when choosing Go's initial syntax. The result is that the generics that eventually were added feel awkward and "bolted on" to many people. (I don't have any strong opinions on it personally, because I'm not invested in that particular ecosystem. I'm merely attempting to distil what I've heard from other people.)
  - preseinger 4y ago
    go's authors were never against generics, they just didn't consider them a table stakes feature go's generics are pretty good, i've never heard anyone disparage them as "bolted on" or hard to use
  - kjksf 4y ago
    Maybe you shouldn't play game of telephone like that. Go generics are exceptionally well designed. The reason it took so long for Go to get generics is because Go designers took their time to arrive at a design that fits with the rest of Go. It's not rushed, it's not "bolted on". They did several designs that they rejected before they accepted the design that got implemented.
    - wyager 4y ago
      This is a truly unreal level of blub paradox and/or brown nosing. It's almost a complete inversion of reality. Go's maintainers had to be beaten into bolting on a poorly-done implementation of polymorphism over like a decade. I can't imagine anyone who's used any language with polymorphism baked in to the design describing Go's implementation as "exceptionally well designed". If this is a Poe's law thing and you're just joking, then you got me.
Thaxll 4y ago
Which modern languages do const properly?
- wyager 4y ago
  Rust and Haskell come to mind.
- pjmlp 4y ago
  Any ML derived language.
throwaway894345 4y ago
I mean, what language got everything exactly right from day 0? Yes, Go started from a minimalist position, but that’s been a wildly successful decision—Go lacks a lot of the cruft of other languages. Go is an easily understandable language, it compiles super quickly, it has top notch tooling (e.g., compiling almost any Go project on any system with ‘go build’ and even cross compile by changing a couple of env vars), it compiles to relatively small[^1] static binaries by default, and it does all of this with pretty good performance. [^1]: Someone is going to come in with some rant about how big a “hello world” binary is compared to C, as if this is emblematic of some real-world use case.
- TwentyPosts 4y ago
  A cynical view is that 80% of Go's success is a result of the excellent tooling, and the fact that it's associated for and pushed by Google, while the underlying language is "mediocre" at best. In theory I agree with Go's minimalist perspective, it just also feels inconsistent, and like they made a whole lot of bad decisions along the way. Favoring C-style enums over proper sum-types is one of the biggest one, and ties into Go's error handling, which continues to be a major talking point.
  - morelisp 4y ago
    Is the excellent tooling not also a property of a minimal language? Lisp has the "least" syntax/semantics and the best tooling, because it's so easy to write tools. Go has more complex syntax/semantics, but still much easier to wrangle e.g. control flow out of an AST, compared to other Algol derivatives.
  - throwaway894345 4y ago
    I fully agree with the enums thing—that’s by far my biggest gripe with the language. But even still, I can be a lot more productive in Go than I can in any other mainstream language, including languages that have sum types (Rust, OCaml, etc) which isn’t to say sum types make me less productive but rather that those languages have other productivity issues that outweigh the benefits afforded by sum types. Basically, Go gets a whole lot of little things right that most languages miss, but everyone fixates on “generics” and “sum types” which are, overall, quite small things IMHO.
pjmlp 4y ago
Ironically that is exactly the same approach they had with C, so at least they are consistent. "Although we entertained occasional thoughts about implementing one of the major languages of the time like Fortran, PL/I, or Algol 68, such a project seemed hopelessly large for our resources: much simpler and smaller tools were called for. All these languages influenced our work, but it was more fun to do things on our own." -- https://www.bell-labs.com/usr/dmr/www/chist.html https://www.bell-labs.com/usr/dmr/www/chist.html

by wyager 4y ago

Groxx 4y ago

"X for me but not for thee" is very much the vibe Go gives me, yeah. I mean, I have completely replaced my adhoc Python use with it and I'm much happier. But it's terrifying to use to build large systems.

ikiris 4y ago
Part of it is that "large systems" are almost all combinations of small systems with proto boundaries, so it's not much of an actual risk unless you're making giant monolith code.
- andrewflnr 4y ago
  "Proto" meaning protobuffers?
  - konart 4y ago
    I think it rather "communication via some protocol" in general. In other words if we are not talking about giant monolith - we have N small systems to begin with.
    - ikiris 4y ago
      I meant specifically protobuffers in that case, but sure, that works.

avgcorrection 4y ago

For what it’s worth it sounds no worse than Java: you have immutable strings but you have no way to enforce that you can’t modify something that you have recieved, which is why the underlying char array for a string has to be defensively copied if the user asks for `asArray()` or whatever it is. Strings being immutable doesn’t seem like a special case, though. The underlying mutable array is just encapsulated, which is something that you can implement yourself. (But reflection… maybe you can break the rules with reflection.)

Groxx 4y ago
No worse, possibly better, yeah. In a fair number of ways I prefer it over Java, e.g. reflection being so limited makes code dramatically easier to understand with confidence, because a large number of common reflection shenanigans in Java simply can't exist at all in Go. The clean slate and lack of inheritance also means the incredible towers of inheritance insanity simply don't exist - it's wonderful. But I work on a pretty big system. The near-inability to both efficiently and safely abstract things is a big problem, and it'll be years before mature uses of generics truly start to address that... when it even can. Then I miss Java quite a lot. Or maybe more accurately Kotlin. Or sophisticated code generation and bytecode modification. Or MAT. Or...
Alphaeus 4y ago
I don't think you can reflect onto the standard library anymore, with the recent "strong encapsulation".
saagarjha 4y ago
Java gets a pass because it was early. Go had time to learn from its mistakes and…just refused to do so.

klodolph 4y ago

Const is a hard language feature to design well. There are a lot of pitfalls in the way const is used in C++ and TypeScript (I’m including “readonly” in the discussion). Rust gets it right, but Rust is relatively complicated. The languages which are most similar to Go are Java and C#, both of which also lack const types, or have a very limited version of constness.

TwentyPosts 4y ago
What are some of these pitfalls in C++'s const design? I assume the issue is that it's difficult to guarantee const correctness as long as you have the ability to fiddle with pointers? Function signatures showing when a parameter gets modified and when not (such as in Rust, or even in properly const-speckled C++) would benefit Go, but I'm not sure how difficult it'd be to implement that. I could see it being difficult considering that one of Go's core features (slices) results in opaque and overlapping memory ownership.

cdogl 4y ago

I don’t think you can fairly call go’s generics an “ad-hoc” implementation. They added syntax for it.

jeffparsons 4y ago
I think in this context "ad hoc" refers to the context in which that syntax was added. IIRC the original creators were against generics ever being added to Golang, so they wouldn't have thought about their eventual introduction when choosing Go's initial syntax. The result is that the generics that eventually were added feel awkward and "bolted on" to many people. (I don't have any strong opinions on it personally, because I'm not invested in that particular ecosystem. I'm merely attempting to distil what I've heard from other people.)
- preseinger 4y ago
  go's authors were never against generics, they just didn't consider them a table stakes feature go's generics are pretty good, i've never heard anyone disparage them as "bolted on" or hard to use
- kjksf 4y ago
  Maybe you shouldn't play game of telephone like that. Go generics are exceptionally well designed. The reason it took so long for Go to get generics is because Go designers took their time to arrive at a design that fits with the rest of Go. It's not rushed, it's not "bolted on". They did several designs that they rejected before they accepted the design that got implemented.
  - wyager 4y ago
    This is a truly unreal level of blub paradox and/or brown nosing. It's almost a complete inversion of reality. Go's maintainers had to be beaten into bolting on a poorly-done implementation of polymorphism over like a decade. I can't imagine anyone who's used any language with polymorphism baked in to the design describing Go's implementation as "exceptionally well designed". If this is a Poe's law thing and you're just joking, then you got me.

Thaxll 4y ago

Which modern languages do const properly?

wyager 4y ago
Rust and Haskell come to mind.
pjmlp 4y ago
Any ML derived language.

throwaway894345 4y ago

I mean, what language got everything exactly right from day 0? Yes, Go started from a minimalist position, but that’s been a wildly successful decision—Go lacks a lot of the cruft of other languages. Go is an easily understandable language, it compiles super quickly, it has top notch tooling (e.g., compiling almost any Go project on any system with ‘go build’ and even cross compile by changing a couple of env vars), it compiles to relatively small[^1] static binaries by default, and it does all of this with pretty good performance. [^1]: Someone is going to come in with some rant about how big a “hello world” binary is compared to C, as if this is emblematic of some real-world use case.

TwentyPosts 4y ago
A cynical view is that 80% of Go's success is a result of the excellent tooling, and the fact that it's associated for and pushed by Google, while the underlying language is "mediocre" at best. In theory I agree with Go's minimalist perspective, it just also feels inconsistent, and like they made a whole lot of bad decisions along the way. Favoring C-style enums over proper sum-types is one of the biggest one, and ties into Go's error handling, which continues to be a major talking point.
- morelisp 4y ago
  Is the excellent tooling not also a property of a minimal language? Lisp has the "least" syntax/semantics and the best tooling, because it's so easy to write tools. Go has more complex syntax/semantics, but still much easier to wrangle e.g. control flow out of an AST, compared to other Algol derivatives.
- throwaway894345 4y ago
  I fully agree with the enums thing—that’s by far my biggest gripe with the language. But even still, I can be a lot more productive in Go than I can in any other mainstream language, including languages that have sum types (Rust, OCaml, etc) which isn’t to say sum types make me less productive but rather that those languages have other productivity issues that outweigh the benefits afforded by sum types. Basically, Go gets a whole lot of little things right that most languages miss, but everyone fixates on “generics” and “sum types” which are, overall, quite small things IMHO.

pjmlp 4y ago

Ironically that is exactly the same approach they had with C, so at least they are consistent. "Although we entertained occasional thoughts about implementing one of the major languages of the time like Fortran, PL/I, or Algol 68, such a project seemed hopelessly large for our resources: much simpler and smaller tools were called for. All these languages influenced our work, but it was more fun to do things on our own." -- https://www.bell-labs.com/usr/dmr/www/chist.html https://www.bell-labs.com/usr/dmr/www/chist.html