41–50 of 288 posts
Earlier quoted context omitted.
There’s a fine line between being willing to change your mind and getting the basics wrong. Go has repeatedly gotten the basics wrong.
Declaring a highly successful language as having the basics wrong means that you are not correct about the basics that were needed.
Earlier quoted context omitted.
Declaring a highly successful language as having the basics wrong means that you are not correct about the basics that were needed.
By that logic Windows would be the best operating system ever and perfect in every way, and anyone who disagrees must be wrong about how an OS should be.
Earlier quoted context omitted.
Something can be highly succesful in spite of having glaring design flaws. Nobody is claiming go isn't wildly succesful, but it's _in spite_ of these issues. It was clear over a decade ago that iota, gopath, and lack of generics were massive kneecaps to the language; go changing it's mind on those things isn't progress it's just getting the fundamentals wrong. A good example of where they're kind of stuck is date for…
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…
Earlier quoted context omitted.
Something can be highly succesful in spite of having glaring design flaws. Nobody is claiming go isn't wildly succesful, but it's _in spite_ of these issues. It was clear over a decade ago that iota, gopath, and lack of generics were massive kneecaps to the language; go changing it's mind on those things isn't progress it's just getting the fundamentals wrong. A good example of where they're kind of stuck is date for…
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…
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
Earlier quoted context omitted.
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…
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.
Earlier quoted context omitted.
In day-to-day usage, the (fast) compilation speed matters much more than the (slow) implementation of new features.
I totally agree, but I'd go further and argue that slow implementation of new features is itself a desirable trait. It's one of the reasons why why I like both Go and Clojure.
The ease of grokking Go (both reading and writing) are big advantages, and facilitated by the "small" feature set of Go.
Earlier quoted context omitted.
So which language had it right from the start? is there a language that has a very low rewrite status?
That’s whataboutism - no language is perfect, but given when go released it’s fair to hold them to a higher standard than languages what were designed 25 years earlier. As an aside - D, Zig, Rust, even typescript got most of the lessons learned from C right
Zig has the (in)famous "Writergate": https://github.com/ziglang/zig/pull/24329
And besides Rust's high count of RFCs, there are things like async (I'm not complaining about it, but its an obvious large-scale "change"), module system changes, etc.
(To be clear, I like both languages a lot. But I wouldn't call them slow moving or right from the start.)
Lack of generic methods was really surprising to me when I was first trying to use generics in Go. Nice to see it being actually implemented
Still, in this case, half the feature is better than none at all, IMO.