3 ms·

This. It is either amusing or depressing to read hand-wringing from Go developers about design issues that have been solved for some 50-ish years (see [1]). It

This. It is either amusing or depressing to read hand-wringing from Go developers about design issues that have been solved for some 50-ish years (see [1]). It was the same with generic types. [1]: https://en.wikipedia.org/wiki/ML_(programming_language) https://en.wikipedia.org/wiki/ML_(programming_language)

aatd86 2y ago
It's amusing and a bit bemusing to read these statements quite often. If it was truly the case, there wouldn't be any PL research anymore. :o)
- IshKebab 2y ago
  There's still PL research because PL researchers are researching novel techniques like dependent types, linear types, formal verification, algebraic effects, advanced reference counting etc. They aren't researching features that ML had literally 50 years ago. Well I hope they aren't anyway. In fairness to the Go developers I don't think they ever said they were against generics; they just put off adding them for ages because they didn't have a design they liked. I imagine the same could happen with type unions - in 20 years when everyone has stopped using Go they'll come up with a reasonable design. :-D
  - fire_lake 2y ago
    As a dev I’m just not prepared to wait that long for features that have been proven to work elsewhere.
  - aatd86 2y ago
    Features such as? Do you know how these features interact with each other? Why are we not using OCaml or standardML or even F# (which I tend to look favorably on) more widely then?
    - IshKebab 2y ago
      Features such as type unions. The topic of this conversation. > Why are we not using OCaml or standardML or even F# (which I tend to look favorably on) more widely then? In my opinion there are a number of factors. I have most experience with OCaml, so on that: 1. Terrible Windows support. 2. Poor documentation. 3. An obsession with linked lists and recursion, which are great from a theoretical point of view, but abysmal from a performance point of view (and also simplicity IMO). 4. Poor syntax. The dearth of brackets and semicolons makes it very hard to visually parse. Something as simple as mismatched brackets can be very frustrating to resolve. The insistence on (a -> b -> c -> d) style function types is unnecessarily confusing. Generally when there has been a choice between academic cleverness and accessibility they've always chosen cleverness. 5. Global type inference is pretty clearly a mistake at this point. IMO part of the reason Rust is so successful is that it has taken a lot of the very good ideas from ML and basically fixed all of the above issues. Standard accessible C style syntax, but expression based and with proper ML style types. Fantastic documentation and Windows support. No linked lists to be seen. It's such a compelling design someone copied it for Go: https://borgo-lang.github.io/ https://borgo-lang.github.io/
      - aatd86 2y ago
        Ok but I guess once again we end up at rust. Rust has its fair share of corners and weird syntax. It also has missing features so to speak. Go evolves at a more cautious pace, and is actually more successful. To the extent that rust also borrowed from Go. The point is not even comparison but I'm still unconvinced about the whole, ignoring everything. Minimalism, caution, and starting from first principles with a clean slate is obviously the right choice.
        IshKebab 2y ago
        > Ok but I guess once again we end up at rust. Yeah I guess because it is really good. > Rust has its fair share of corners and weird syntax. True, but IMO they're in smaller bits of the language, like trait bounds. Not something as basic as blocks, function calls or variable declaration. > Go evolves at a more cautious pace, and is actually more successful. To the extent that rust also borrowed from Go. Go is more successful because it is older. Give it a few years. I actually don't know of a single feature Rust has borrowed from Go. It is not even listed as an influence: https://doc.rust-lang.org/reference/influences.html https://doc.rust-lang.org/reference/influences.html > Minimalism, caution, and starting from first principles with a clean slate is obviously the right choice. Throwing away learnings from other languages is pretty clearly a bad choice IMO. It would be like creating a new language where everything is nullable... oh.
- lmm 2y ago
  > If it was truly the case, there wouldn't be any PL research anymore. :o) What? There is plenty of interesting ongoing PL research (e.g. a "perfect" solution to combining subtyping with type inference was only found quite recently). But some languages are happy to ignore results from 50 years ago.
klodolph 2y ago
These digs at Go are so vacuous. You don’t just drop a union type into a language with some syntax and semantics. There’s an impact on how the runtime works. Every language’s design is somewhat impacted by runtime considerations. For Go, the runtime consideration is the concurrent garbage collector, and the data race that you would have between the garbage collector and the union tag. You have to solve that problem in order to have unions in Go in a way that would make sense in Go. Go unions would not look like unions in ML. You could trivially implement unions in Go by having union values be pointers to structures, and it could be a different structure for each variant. This is basically just sugar around "any" and typecasting. The problem? You’re now allocating for every assignment.
- noelwelsh 2y ago
  I agree that one cannot simply hand wave a language feature into existence. What I don't understand is why you consider a requirement to change the runtime to disqualify a new feature. In this case, if I understand your complaint correctly, what you are saying is there is a race condition between setting the tag of a variant / union / sum type and the GC reading that tag to interpret the memory layout. I agree this is an issue, but it's an issue with any memory write. This is why garbage collectors have a write barrier, and the Go GC is no different (e.g. [1]). So ultimately I don't see the problem as unsurmountable. Yes, it will require some thought and some runtime changes, but the foundation (i.e. type tags, the write barrier) is already in place. [1]: https://ihagopian.com/posts/write-barriers-in-the-go-garbage-collector https://ihagopian.com/posts/write-barriers-in-the-go-garbage...
kitd 2y ago
And yet, with Go, I've never been more productive. edit: to be complete, design decisions, even 50 year old ones, are not absolutes, but trade-offs and subjective. Eg, is a GC more important than a highly-expressive type system? Depends who you are. But a simple language, even one with a minimal type system, can be highly productive.
- School-Cotton 2y ago
  > is a GC more important than a highly-expressive type system? Depends who you are That’s not a great example because there are plenty of languages with expressive type systems and GC. F# for example.
h4ck_th3_pl4n3t 2y ago
I am fine just watching you implement another Rust binding every weekend until you give up. At this point there's probably more GL bindings for Rust out there than active developers. If you haven't figured out by now that every language has tradeoffs and compromises along the way because it has to run on x86/x87/AVX512 CPUs, then I guess you will need a couple years until we can have a rational discussion about it. Rust is good at type safety, we get it. But there is plenty of developers that are also fine without type safety. Therefore type safety is just a scale from duck to dependent types, and in Rust, type safety is usually in the way.

aatd86 2y ago

It's amusing and a bit bemusing to read these statements quite often. If it was truly the case, there wouldn't be any PL research anymore. :o)

IshKebab 2y ago
There's still PL research because PL researchers are researching novel techniques like dependent types, linear types, formal verification, algebraic effects, advanced reference counting etc. They aren't researching features that ML had literally 50 years ago. Well I hope they aren't anyway. In fairness to the Go developers I don't think they ever said they were against generics; they just put off adding them for ages because they didn't have a design they liked. I imagine the same could happen with type unions - in 20 years when everyone has stopped using Go they'll come up with a reasonable design. :-D
- fire_lake 2y ago
  As a dev I’m just not prepared to wait that long for features that have been proven to work elsewhere.
- aatd86 2y ago
  Features such as? Do you know how these features interact with each other? Why are we not using OCaml or standardML or even F# (which I tend to look favorably on) more widely then?
  - IshKebab 2y ago
    Features such as type unions. The topic of this conversation. > Why are we not using OCaml or standardML or even F# (which I tend to look favorably on) more widely then? In my opinion there are a number of factors. I have most experience with OCaml, so on that: 1. Terrible Windows support. 2. Poor documentation. 3. An obsession with linked lists and recursion, which are great from a theoretical point of view, but abysmal from a performance point of view (and also simplicity IMO). 4. Poor syntax. The dearth of brackets and semicolons makes it very hard to visually parse. Something as simple as mismatched brackets can be very frustrating to resolve. The insistence on (a -> b -> c -> d) style function types is unnecessarily confusing. Generally when there has been a choice between academic cleverness and accessibility they've always chosen cleverness. 5. Global type inference is pretty clearly a mistake at this point. IMO part of the reason Rust is so successful is that it has taken a lot of the very good ideas from ML and basically fixed all of the above issues. Standard accessible C style syntax, but expression based and with proper ML style types. Fantastic documentation and Windows support. No linked lists to be seen. It's such a compelling design someone copied it for Go: https://borgo-lang.github.io/ https://borgo-lang.github.io/
    - aatd86 2y ago
      Ok but I guess once again we end up at rust. Rust has its fair share of corners and weird syntax. It also has missing features so to speak. Go evolves at a more cautious pace, and is actually more successful. To the extent that rust also borrowed from Go. The point is not even comparison but I'm still unconvinced about the whole, ignoring everything. Minimalism, caution, and starting from first principles with a clean slate is obviously the right choice.
      - IshKebab 2y ago
        > Ok but I guess once again we end up at rust. Yeah I guess because it is really good. > Rust has its fair share of corners and weird syntax. True, but IMO they're in smaller bits of the language, like trait bounds. Not something as basic as blocks, function calls or variable declaration. > Go evolves at a more cautious pace, and is actually more successful. To the extent that rust also borrowed from Go. Go is more successful because it is older. Give it a few years. I actually don't know of a single feature Rust has borrowed from Go. It is not even listed as an influence: https://doc.rust-lang.org/reference/influences.html https://doc.rust-lang.org/reference/influences.html > Minimalism, caution, and starting from first principles with a clean slate is obviously the right choice. Throwing away learnings from other languages is pretty clearly a bad choice IMO. It would be like creating a new language where everything is nullable... oh.
lmm 2y ago
> If it was truly the case, there wouldn't be any PL research anymore. :o) What? There is plenty of interesting ongoing PL research (e.g. a "perfect" solution to combining subtyping with type inference was only found quite recently). But some languages are happy to ignore results from 50 years ago.

klodolph 2y ago

These digs at Go are so vacuous. You don’t just drop a union type into a language with some syntax and semantics. There’s an impact on how the runtime works. Every language’s design is somewhat impacted by runtime considerations. For Go, the runtime consideration is the concurrent garbage collector, and the data race that you would have between the garbage collector and the union tag. You have to solve that problem in order to have unions in Go in a way that would make sense in Go. Go unions would not look like unions in ML. You could trivially implement unions in Go by having union values be pointers to structures, and it could be a different structure for each variant. This is basically just sugar around "any" and typecasting. The problem? You’re now allocating for every assignment.

noelwelsh 2y ago
I agree that one cannot simply hand wave a language feature into existence. What I don't understand is why you consider a requirement to change the runtime to disqualify a new feature. In this case, if I understand your complaint correctly, what you are saying is there is a race condition between setting the tag of a variant / union / sum type and the GC reading that tag to interpret the memory layout. I agree this is an issue, but it's an issue with any memory write. This is why garbage collectors have a write barrier, and the Go GC is no different (e.g. [1]). So ultimately I don't see the problem as unsurmountable. Yes, it will require some thought and some runtime changes, but the foundation (i.e. type tags, the write barrier) is already in place. [1]: https://ihagopian.com/posts/write-barriers-in-the-go-garbage-collector https://ihagopian.com/posts/write-barriers-in-the-go-garbage...

kitd 2y ago

And yet, with Go, I've never been more productive. edit: to be complete, design decisions, even 50 year old ones, are not absolutes, but trade-offs and subjective. Eg, is a GC more important than a highly-expressive type system? Depends who you are. But a simple language, even one with a minimal type system, can be highly productive.

School-Cotton 2y ago
> is a GC more important than a highly-expressive type system? Depends who you are That’s not a great example because there are plenty of languages with expressive type systems and GC. F# for example.

h4ck_th3_pl4n3t 2y ago

I am fine just watching you implement another Rust binding every weekend until you give up. At this point there's probably more GL bindings for Rust out there than active developers. If you haven't figured out by now that every language has tradeoffs and compromises along the way because it has to run on x86/x87/AVX512 CPUs, then I guess you will need a couple years until we can have a rational discussion about it. Rust is good at type safety, we get it. But there is plenty of developers that are also fine without type safety. Therefore type safety is just a scale from duck to dependent types, and in Rust, type safety is usually in the way.