6 ms·

Why is iota a massive kneecap to the language? It is semantically identical to enum in C and Typescript. The trouble is that Rust is older than Go and it was a

by 9rx 4mo ago

Why is iota a massive kneecap to the language? It is semantically identical to enum in C and Typescript. The trouble is that Rust is older than Go and it was already confusing people into thinking enums and sum types are the same thing, so by using slightly different syntax, iota, Go avoided the whole confusion of users thinking that enums would behave like sum types instead of actual enums. Is your attempt at making a point that not having sum types is the massive flaw? Sum types are a useful construct, to be sure, but there are plenty of good languages without them. That's more on the design quirk end, realistically.

jolux 4mo ago
Rust is technically older than Go, but who was actually using it when Go 1.0 came out in 2012? Rust 1.0 wasn’t until 2015.
- 9rx 4mo ago
  The social landscape doesn't depend on anyone actually using it. However, 1.0 isn't a significant milestone like you suggest either. For a current example, Zig is relatively popular today despite not yet reaching 1.0.
  - stouset 4mo ago
    Do you just forget the things you write in earlier comments? > Rust is older than Go and it was already confusing people into thinking enums and sum types are the same thing Of course the social landscape depends on people actually using it. None of the people who weren’t using Rust at the time were magically confused about enums and sum types by the mere existence of some new and experimental language. Rust barely existed at the time Go was first being developed. And given the history of Go and the notoriety of its core team for flatly ignoring prior work in programming languages, it’s extremely unlikely that Pike et al gave more than a cursory glance to what nascent Rust was doing at the time. But even if they had, to suggest that they intentionally replicated a dumb thing from C but gave it a different name to avoid users being confused by a different thing from a language that roughly nobody knew about at the time is bananas.
    - 9rx 4mo ago
      > Of course the social landscape depends on people actually using it. That's nonsense. Brainfuck has shaped the social landscape despite effectively nobody using it, and absolutely nobody using it for any real work. The social landscape is not at all dependent on use. > And given the history of Go and the notoriety of its core team for flatly ignoring prior work in programming languages Huh? Go comes straight out of prior work. It is nearly indistinguishable from Alef. What the Go language flatly ignored was being innovative. Reasonably so, of course. It wasn't trying to innovate in programming languages so that we'd have another to throw on the heap of languages nobody uses. It was trying to solve a specific business problem using well-established methods.
    - ratrace 4mo ago
      [dead]
maccard 4mo ago
> Why is iota a massive kneecap to the language? It is semantically identical to enum in C and Typescript. iota is a massive kneecap _because_ it's semantically identical to enum in C and Typescript. > Is your argument actually that not having sum types is the massive flaw? Sum types are a useful construct, to be sure, but there are plenty of good languages without them. That's more on the design quirk end, realistically. In a dream world sure we'd have full blown sum types (and that would give a result type which would also solve a lot of the nil-interface-combined-with-error-handling issues that I've ran into when working with go), but I can forgive that. The problem is this - https://www.zarl.dev/posts/enums https://www.zarl.dev/posts/enums
- 9rx 4mo ago
  > The problem is this - https://www.zarl.dev/posts/enums https://www.zarl.dev/posts/enums The only case I see made in there is that it doesn't like how Go implicitly converts consts. While that may be a reasonable criticism, it doesn't have anything to do with iota. It is related to the type system and applies in general. Consider the same problem exhibited here: type Email string func Send(email Email) func() { Send("invalid") } // Converted string const does not satisfy Email type expectations Perhaps you accidentally offered the wrong link? It was made abundantly clear when Go was released that it was intended to "feel like a dynamically-typed language". Being able to pass arbitrary values is perfectly in line with a dynamically-typed language. Realistically, the type system in Go is there to give the compiler optimization hints, not to offer type safety. Go was targeted at those wanting to use Python, without the programs being painfully slow to run. How much of a kneecap is implicit type conversion, really, when it is already in line with what the target audience is accustomed to? It is a quirk at best.
  - maccard 4mo ago
    > It was made abundantly clear when Go was released that it was intended to "feel like a dynamically-typed language". If I google this quote a comment from you comes up here on this exact topic, where you seem to have completely missed the point there too. If I link to the docs [0], the full quote is "It's a fast, statically typed, compiled language that feels like a dynamically typed, interpreted language. " So it is a statically typed language first and foremost. If you want to rehash the discussion and tell people that a flawed type system that people have been asking for a solution to for close to a decade [1] you can just re-read the last time the arugments were made as I don't think I'm going to make any headway there. [0] https://go.dev/doc/ https://go.dev/doc/ [1] https://github.com/golang/go/issues/19814 https://github.com/golang/go/issues/19814
stouset 4mo ago
> Why is iota a massive kneecap to the language? It is semantically identical to enum in C and Typescript. So is nil. Care to make the same argument?
- 9rx 4mo ago
  Typescript has something resembling nil as inherited from Javascript, so presumably that's what you are referring to. C and Javascript are the most widely used languages in existence. Clearly they weren't kneecapped. It mightn't be to your preference, but "I don't like it" would be an atypical use for the word "kneecap". There is a stronger case to be made for the other two. Calling GOPATH a design mistake is a stretch as it was perfectly suited to use within Google, but it didn't fit the typical solo developer's environment. Lack of generics made writing certain types of code difficult. You could be convincing in suggesting that Go did end up being used less than it otherwise would have because of those choices. iota? It's just a construct that generates numbers (an enum). How does that kneecap anything? If it really bothers you, you can manually number the values by hand instead. Why would anyone reject a language because it allows you to optionally choose to have the compiler assign numbers automatically instead of forcing you to do it manually? The answer is nobody. In fact, most popular languages have something equivalent to iota.
  - stouset 4mo ago
    Nil exists in C and is widely considered to be a massive mistake in the language. An understandable one at the time, but a mistake nonetheless. Thus “go borrowed it from C, therefore it can’t have been a mistake” is a pretty lame take. The whole point of a new language is to make improvements on what’s out there already. Go missed an opportunity to fix one of C’s most notorious mistakes. So yes, they kneecapped themselves by forcing all of the users of Go to continue dealing with this well-known footgun. Does it mean Go isn’t popular? Of course not. C was popular. PHP was popular. JavaScript is popular. Go is popular. This is always in spite of their faults. But Go could have been better.
    - 9rx 4mo ago

by 9rx 4mo ago

jolux 4mo ago

Rust is technically older than Go, but who was actually using it when Go 1.0 came out in 2012? Rust 1.0 wasn’t until 2015.

9rx 4mo ago
The social landscape doesn't depend on anyone actually using it. However, 1.0 isn't a significant milestone like you suggest either. For a current example, Zig is relatively popular today despite not yet reaching 1.0.
- stouset 4mo ago
  Do you just forget the things you write in earlier comments? > Rust is older than Go and it was already confusing people into thinking enums and sum types are the same thing Of course the social landscape depends on people actually using it. None of the people who weren’t using Rust at the time were magically confused about enums and sum types by the mere existence of some new and experimental language. Rust barely existed at the time Go was first being developed. And given the history of Go and the notoriety of its core team for flatly ignoring prior work in programming languages, it’s extremely unlikely that Pike et al gave more than a cursory glance to what nascent Rust was doing at the time. But even if they had, to suggest that they intentionally replicated a dumb thing from C but gave it a different name to avoid users being confused by a different thing from a language that roughly nobody knew about at the time is bananas.
  - 9rx 4mo ago
    > Of course the social landscape depends on people actually using it. That's nonsense. Brainfuck has shaped the social landscape despite effectively nobody using it, and absolutely nobody using it for any real work. The social landscape is not at all dependent on use. > And given the history of Go and the notoriety of its core team for flatly ignoring prior work in programming languages Huh? Go comes straight out of prior work. It is nearly indistinguishable from Alef. What the Go language flatly ignored was being innovative. Reasonably so, of course. It wasn't trying to innovate in programming languages so that we'd have another to throw on the heap of languages nobody uses. It was trying to solve a specific business problem using well-established methods.
  - ratrace 4mo ago
    [dead]

maccard 4mo ago

> Why is iota a massive kneecap to the language? It is semantically identical to enum in C and Typescript. iota is a massive kneecap _because_ it's semantically identical to enum in C and Typescript. > Is your argument actually that not having sum types is the massive flaw? Sum types are a useful construct, to be sure, but there are plenty of good languages without them. That's more on the design quirk end, realistically. In a dream world sure we'd have full blown sum types (and that would give a result type which would also solve a lot of the nil-interface-combined-with-error-handling issues that I've ran into when working with go), but I can forgive that. The problem is this - https://www.zarl.dev/posts/enums https://www.zarl.dev/posts/enums

9rx 4mo ago
> The problem is this - https://www.zarl.dev/posts/enums https://www.zarl.dev/posts/enums The only case I see made in there is that it doesn't like how Go implicitly converts consts. While that may be a reasonable criticism, it doesn't have anything to do with iota. It is related to the type system and applies in general. Consider the same problem exhibited here: type Email string func Send(email Email) func() { Send("invalid") } // Converted string const does not satisfy Email type expectations Perhaps you accidentally offered the wrong link? It was made abundantly clear when Go was released that it was intended to "feel like a dynamically-typed language". Being able to pass arbitrary values is perfectly in line with a dynamically-typed language. Realistically, the type system in Go is there to give the compiler optimization hints, not to offer type safety. Go was targeted at those wanting to use Python, without the programs being painfully slow to run. How much of a kneecap is implicit type conversion, really, when it is already in line with what the target audience is accustomed to? It is a quirk at best.
- maccard 4mo ago
  > It was made abundantly clear when Go was released that it was intended to "feel like a dynamically-typed language". If I google this quote a comment from you comes up here on this exact topic, where you seem to have completely missed the point there too. If I link to the docs [0], the full quote is "It's a fast, statically typed, compiled language that feels like a dynamically typed, interpreted language. " So it is a statically typed language first and foremost. If you want to rehash the discussion and tell people that a flawed type system that people have been asking for a solution to for close to a decade [1] you can just re-read the last time the arugments were made as I don't think I'm going to make any headway there. [0] https://go.dev/doc/ https://go.dev/doc/ [1] https://github.com/golang/go/issues/19814 https://github.com/golang/go/issues/19814

stouset 4mo ago

> Why is iota a massive kneecap to the language? It is semantically identical to enum in C and Typescript. So is nil. Care to make the same argument?

9rx 4mo ago
Typescript has something resembling nil as inherited from Javascript, so presumably that's what you are referring to. C and Javascript are the most widely used languages in existence. Clearly they weren't kneecapped. It mightn't be to your preference, but "I don't like it" would be an atypical use for the word "kneecap". There is a stronger case to be made for the other two. Calling GOPATH a design mistake is a stretch as it was perfectly suited to use within Google, but it didn't fit the typical solo developer's environment. Lack of generics made writing certain types of code difficult. You could be convincing in suggesting that Go did end up being used less than it otherwise would have because of those choices. iota? It's just a construct that generates numbers (an enum). How does that kneecap anything? If it really bothers you, you can manually number the values by hand instead. Why would anyone reject a language because it allows you to optionally choose to have the compiler assign numbers automatically instead of forcing you to do it manually? The answer is nobody. In fact, most popular languages have something equivalent to iota.
- stouset 4mo ago
  Nil exists in C and is widely considered to be a massive mistake in the language. An understandable one at the time, but a mistake nonetheless. Thus “go borrowed it from C, therefore it can’t have been a mistake” is a pretty lame take. The whole point of a new language is to make improvements on what’s out there already. Go missed an opportunity to fix one of C’s most notorious mistakes. So yes, they kneecapped themselves by forcing all of the users of Go to continue dealing with this well-known footgun. Does it mean Go isn’t popular? Of course not. C was popular. PHP was popular. JavaScript is popular. Go is popular. This is always in spite of their faults. But Go could have been better.
  - 9rx 4mo ago