171–180 of 262 posts
Is there any movement in the language spec to address this in the future with Nil types or something?
What answer do you expect?
Earlier quoted context omitted.
It is a type safe language, not exactly sure what you're hinting at here.
This entire post is a big workaround go's insufficient type system because nil is not modelled in it. That's not safe.
Earlier quoted context omitted.
Not at all. Otherwise brainfuck would be the simplest language to learn. How do you currently represent a type that is A or B in Go? You have to use an interface. That’s much more complex than using a sum type would be.
Well, Brainfuck is simple to learn. The entire specification fits comfortably on a single page. Simple to learn doesn't automatically imply simple to use for any given purpose. The same is true for Go. > You have to use an interface. That’s much more complex than using a sum type would be. More complex how and by what metric?
But to understand the specification and how it can be used to do a programming, you need to have at least a cursory understanding of turing machines and related theory, which isn't necessary to learn Java or python.
Under your definition, the conceptually simplest language is something like SUBLEQ, (the specification is only a single line!) but in this case, being able to implement the language, and learning the language aren't the same thing. Learning the language generally means, like, useful for given purposes.
Earlier quoted context omitted.
This is the core of the problem. Of course you can learn the language in a weekend, but you're bound to make the same mistakes developers have been doing for decades. This may be ok, as you say, if you allow errors here and there because you are fine dealing with those problems. But at the other end, it may be a user that is affected by the error. Which may be ok as well, but why should it be? We lament the quality o…
Go is just making a certain set of tradeoffs. If you try to fix all the "mistakes developers have been doing for decades", you get Rust. And considering that Rust is already Rust, there is not much point in trying to make Go another Rust. The line has to be drawn somewhere. I think everyone has certain things they'd put on the other side of that line, and strict nils are probably at the top of the list for many, but…
It was designed, specifically, as per Rob Pike, for _bad_ developers. Developers who couldn't be productive at Google because they weren't properly taught at unis [0].
Then it caught momentum and then here we are, discussing a bad language designed for bad developers as if there is nothing better we can do with our lives.
Earlier quoted context omitted.
If you squint really hard, the work on generics is a step toward the future. If you don't squint, then I don't think so.
With generics, can you not make a NonNil struct in Go, where the contents of the struct are only a *T that has been checked at construction time to not be nil, and doesn't expose its inner pointer mutably to the public? I would think that would get the job done, but I also haven't really done much Go since prior to generics being introduced Otherwise, since pointers are frequently used to represent optional parameter…
Earlier quoted context omitted.
I never said otherwise. My point is that Go is far harder to learn than they're implying. It certainly can't be learned over the weekend — well, maybe it can be, but the code you end up writing will Inevitably be full of resources leaks, panics, nil pointer issues, improperly handled errors, etc. You may be able to put together some basic logic, but you are far from understanding the language. I don't think it's hone…
I agree that it's very unlikely for someone to learn Go in a week and start writing flawless code. But Go's real strength is in its readability, not writability. I think it's very much possible to learn Go in a week, then read clean Go code like the standard library and understand exactly what's going on. At least that's my interpretation of what it means for a new grad to be productive in Go in less than a week. Nob…
Earlier quoted context omitted.
> Default Gender = Male is... not great enum Gender { Unspecified, Male, Female, Other, } impl Default for Gender { default() -> Self { Self::Unspecified } } or: enum Gender { Male, Female, Other, } and use Option instead of Gender directly, with Option::None here meaning the same that we would mean by Gender::Unspecified
I think they are talking about the cons of Go allowing zero value. Rust doesn’t have that problem.
type Gender int
const (
Unspecified Gender = iota
Male
Female
Other
)
Earlier quoted context omitted.
With generics, can you not make a NonNil struct in Go, where the contents of the struct are only a *T that has been checked at construction time to not be nil, and doesn't expose its inner pointer mutably to the public? I would think that would get the job done, but I also haven't really done much Go since prior to generics being introduced Otherwise, since pointers are frequently used to represent optional parameter…
Every type in Go has a zero value. The zero value for pointers is nil. So you can't do it with regular pointers, because users can always create an instance of the zero value.
Earlier quoted context omitted.
I think they are talking about the cons of Go allowing zero value. Rust doesn’t have that problem.
type Gender int const ( Unspecified Gender = iota Male Female Other ) Works the same way. Declaring an empty variable of the type Gender (var x Gender) results in unspecified.
It’s nil pointers all over again, but for your non-pointer types too! Default zero values are yet another own goal that ought to have been thrown away at the design stage.
Earlier quoted context omitted.
This is one of those things which feels like just a small trade off against convenience for the language design, but then in practice it's a big headache you're stuck with in real systems. It's basically mandating Rust's Default trait or the C++ default (no argument) constructor. In some places you can live with a Default but you wish there wasn't one. Default Gender = Male is... not great, but we can live with it, s…
Default gender male not how this works in practice. Instead, you define an extra “invalid” value for almost every scalar type, so invalid would be 0, male 1 and female 2. Effectively this makes (almost) every scalar type nullable. It is surprisingly useful, though, and I definitely appreciate this tradeoff most of the time. (Sometimes your domain type really does have a suitable natural default value, and you just ma…