71–80 of 176 posts
This was to be expected. But I'm glad for Go. In some years a language that interops with Go comes out, where all the Go types have a ?-suffix indicating they are nullable. The language will be mostly null-safe. Also it will sport sumtypes and pattern matching/ destructuring in switch statements. It will be called: Gotlin.
Earlier quoted context omitted.
Of course I'm joking, but I think implicit nullability is the worst part of Go. A language designed in a era when this was widely known as the billion dollar mistake (prolly even more expensive). But this is not easily reversed. Not as easy as tagging generics onto the language. And the parallels with Java's maturing are just lovely. Also, we have seen what Kotlin is now doing for Java: a new language was needed to t…
Golang needed sum types (for options) and match statements (python got it after all...) way before it needed generics. CHANGE MY VIEW.
Earlier quoted context omitted.
Golang needed sum types (for options) and match statements (python got it after all...) way before it needed generics. CHANGE MY VIEW.
Sum and intersection types + pattern matching feels so natural in languages like F#, OCaml, Reason, and Elixir. I know they add a significant amount of complexity to the language, but the more I use them, the more I feel that the tradeoff lands in the goldilocks "just right" zone. I find myself missing them often.
Yes. They are as important as records/structs a.k.a. product types.
> F#, OCaml, Reason, and Elixir
Haskell, Elm, PureScript, Kotlin, Idris, ...
> I know they add a significant amount of complexity to the language
Really? I dont think it can be so much more than generics :)
Elm has 'm and the whole language is 5k lines of code.
Earlier quoted context omitted.
Golang needed sum types (for options) and match statements (python got it after all...) way before it needed generics. CHANGE MY VIEW.
Yes. But null-safety is absolute on the top (as it is soooo hard, maybe even impossible, to add later). Generics... Well, I just come from a Elm gig (knowing Haskell/C++/Java/Kotlin/Ruby) and I must say I was not too bothered with the lack of generics there.
[deleted]
This was to be expected. But I'm glad for Go. In some years a language that interops with Go comes out, where all the Go types have a ?-suffix indicating they are nullable. The language will be mostly null-safe. Also it will sport sumtypes and pattern matching/ destructuring in switch statements. It will be called: Gotlin.
Of course I'm joking, but I think implicit nullability is the worst part of Go. A language designed in a era when this was widely known as the billion dollar mistake (prolly even more expensive). But this is not easily reversed. Not as easy as tagging generics onto the language. And the parallels with Java's maturing are just lovely. Also, we have seen what Kotlin is now doing for Java: a new language was needed to t…
That being said, implicit nullability leads to mostly human type of errors and comes from our limitation to fit all the parts of a complex system in our brains. I'm curious if there are example where machines write code and use plenty of implicit nullability without that causing any NPE issues ever.
Just a thought.
Earlier quoted context omitted.
A more apt comparison is TypeScript to JavaScript, perhaps. Kotlin and Java interop at the bytecode level, but Golang doesn't have that. Gotlin would have to compile to Golang with the same shimming hairiness as TS downleveling to JS.
Well spotted. Though typescript does not fix some of the biggest horrors of JS. Interop is really good as one would expect.
A few weeks ago: https://news.ycombinator.com/item?id=25750582
IMO the biggest factors for the success of Go are 1) super-fast compile times, 2) easy to interpret compiler errors, and 3) dead simple shipment of high performance, native static binaries. I think Go has succeeded, despite, not because of the language itself. One very big limitation being the lack of generics or any sort of ability to leverage higher-order types. Sometimes making a small modification to a large code…
"Even"? I actually miss the macro-like power of templates when I'm using generics in Java and C#, but generating the longest possible error message using templates is practically an Olympic sport. I presume that SFINAE is partially to blame, because a lot of the output enumerates all the candidates that didn't match.
I wonder if over time, Golang will pick up more type features like Java and other languages have. The general consensus seems to be that powerful type systems are very effective. Personally, the low footprint runtime and concurrency primitives are enough for me and I wouldn't mind the language becoming "less simple" if it helps the ecosystem. Once generics are implemented, I can imagine people requesting for the next…
> I wonder if over time, Golang will pick up more type features like Java and other languages have. I hope it doesn't pick them up like Java did. When Java was considering generics, there were two major proposals out there. Sun decided on easily the worst one: type erasure. Now we're stuck with it. When Java was considering closures, there were two major proposals out there that I recall [one being to get rid of Java…
(Perhaps I should clarify that I don't have a strong opinion on type erasure.)
[0] https://homepages.inf.ed.ac.uk/wadler/gj/Documents/gj-oopsla... [1] https://arxiv.org/abs/2005.11710