11–20 of 88 posts
Earlier quoted context omitted.
Most modern languages have solved the problem. There are a variety of ways to do it.
Can you list the variety of ways?
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
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.
I use Rust for a lot of personal projects mainly because of the type system, not because it doesn't have GC. I think GC's totally livable for a great many things, and it would help iteration speed a lot to not have to deal with the borrow-checker, but I just can't stand working in a language with a shaky type system these days. So Go-with-good-types sounds fantastic to me.
Earlier quoted context omitted.
Most modern languages have solved the problem. There are a variety of ways to do it.
Can you list the variety of ways?
If you don't need to manipulate pointers then nil really just represents a degenerate or optional value. For optional values these can be encoded any number of ways depending on the type system. One common pattern is an optional type. Another is to annotate the type to indicate that it might be null.
The idea is that if a programmer doesn't check that an nullable or optional type is missing then the program should fail at compile time instead of crashing at runtime. Golang chose to crash programs at runtime.
So for whatever reason, Go has decided that null pointer dereferences are not a big deal. But God help you if you try to comment out a variable use without assigning it to "_". Then the program fails to compile.
Go has some nice tooling which is quite easy to use w.r.t. static analysis. I started writing a nil pointer analysis tool which was going to take advantage of and provide some more advanced information*. I "unfortunately" had a lot more fun stuff to do during my vacation, but it was very easy to get started with! So kudos to the Go team for making this kind of stuff possible for a 1-man team. * Just a forward-style a…
> I started writing a nil pointer It still boggles my mind that Go decided to force programmers to worry about nil pointers.
Earlier quoted context omitted.
You know what's fun? Getting a nil where you are supposed to have an Optional.
Somebody has used Scala
In "pure" Scala (not in the FP sense, but just without mixing with Java) something like that is almost impossible.
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.
as opposed to?
Earlier quoted context omitted.
Optionals would have been a way to solve this problem
You know what's fun? Getting a nil where you are supposed to have an Optional.
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