Re:What else is in Go 1.11?
by matthewmacleod on Thursday August 16, 2018 @06:45AM
(#17773513)
Totally agreed. A modern type system should make these errors fundamentally impossible. If you see them in production, it means there is definitely a logic or error handling issue somewhere in your code and I find it weird that there's no support for a known technique for eliminating them.
[ Parent
| on HN ]
Re:What else is in Go 1.11?
by SamReidHughes on Thursday August 16, 2018 @02:54PM
(#17777518)
You can't actually accomplish that without making the language really complicated.
Are Crystal, Kotlin and Swift really complicated? Is Rust's complications due to null protections or something else?
Re:What else is in Go 1.11?
by SamReidHughes on Friday August 17, 2018 @01:18PM
(#17784353)
Are you joking? They're all way more complicated than Go.
Okay, let's pretend that's true.
Are the complications due to null protection being there, or are they due some other things?
Re:What else is in Go 1.11?
by SamReidHughes on Tuesday August 21, 2018 @03:29PM
(#17812893)
Some of the complications are necessary. You either need generics or a whole bunch of primitives to have non-nullable references. Go would also have to replace slices with something different. Return types and the shape of the interfaces would have to be changed. Algebraic datatypes or some complicated way of defining return types would need to be added for it to be usable. Defer statements that can modify the function's return value would need to be handleable by the type system, or dropped.