51–60 of 88 posts
I've wondered what it would be like to write a thin language that compiles to Go and mainly serves to introduce a reasonable type system on top, while benefitting from its performance and garbage-collection. Could prevent null dereferencing, among other things
Like a TypeScript for Go? We could call it Tolang.
Earlier quoted context omitted.
It is super weird to me that no big compile-to-Go languages have emerged. It doesn't seem like anyone is even trying! Why not?
> Why not? Why? What would be the point except as a personal challenge?
Earlier quoted context omitted.
Then it boggles your mind that Go functions the way most popular languages work. You don't see so much dunking on Python, Java, Clojure, Ruby, &c, over this, even though these languages dominate the leaderboards. Which is fine, except that this is probably the second-most boring critique of Go, one virtually everyone has heard before, and it has little if anything to do with the story we're actually commenting on, de…
- MyPy doesn't have pervasive nullability, but distinguishes nullable and non-nullable types in the type system. A function declared to return int but randomly returns None has a bug in its type hints. - I dunk on Java for pervasive nullability too (though there are tools that add @Nullable xor @NonNull annotations used for analysis, possibly sound). But Go has over a decade more hindsight and should've known better.…
Go distinguishes between the two too. You cannot pass nil as a value to int. In fact in Go you'd get a compiler warning[0] so you don't even need to rely on type hints and a properly set up CI/CD pipeline to catch said faults:
The problem with Go is that pointers can be nullable[1] as well as interfaces[2] (interfaces, crudely speaking, being Go's solution to generics and inheritance. Crudely speaking. So interfaces get used a lot).
There is some logic to them being nullable if you think about the code from a hardware perspective but given how opinionated the compiler and language is, I feel they could have done more to catch accidental nils to save the developer from having to consciously consider them each time.
[0] https://play.golang.org/p/BADNnw08hoo
Earlier quoted context omitted.
>You don't see so much dunking on Python, Java, Clojure, Ruby, &c, One of the common arguments now for why C# is superior to Java is that it supports non-nullable references. As does C++, which for large latency-sensitive projects is generally picked over C.
I'd say it has been a better designed language for sure, which wasn't that hard since they just needed to take a look where Java messed up. So many things are obvious in hindsight so it's not a fair comparison. Regarding platform and reach, Java still wins i guess. Disclaimer: Using neither.
The thing is, the Java ecosystem is insane. What else comes close to it in breadth and quality? Python, Go, Ruby etc certainly don't. C++?
Earlier quoted context omitted.
> I started writing a nil pointer It still boggles my mind that Go decided to force programmers to worry about nil pointers.
Then it boggles your mind that Go functions the way most popular languages work. You don't see so much dunking on Python, Java, Clojure, Ruby, &c, over this, even though these languages dominate the leaderboards. Which is fine, except that this is probably the second-most boring critique of Go, one virtually everyone has heard before, and it has little if anything to do with the story we're actually commenting on, de…
I'm sorry you're bored and also annoyed in the possible universe where GoKart is your project. But it seems like this is a thing people want to talk about in a post about Go static analysis tooling.
I don't see why you're trying to police HN conversations.
Earlier quoted context omitted.
So you get an Optional which haven't been set instead of a nil pointer. What's better about that?
The type system knows about it and you're forced to check it
Is there really that much of a difference between those cases?
I agree though that in an interface, Optional conveys a more explicit meaning than something pointer-like, which is always a good thing.
Earlier quoted context omitted.
Then it boggles your mind that Go functions the way most popular languages work. You don't see so much dunking on Python, Java, Clojure, Ruby, &c, over this, even though these languages dominate the leaderboards. Which is fine, except that this is probably the second-most boring critique of Go, one virtually everyone has heard before, and it has little if anything to do with the story we're actually commenting on, de…
Golang wasn't designed in the 1990s. I'm sorry you're bored and also annoyed in the possible universe where GoKart is your project. But it seems like this is a thing people want to talk about in a post about Go static analysis tooling. I don't see why you're trying to police HN conversations.
