undefined | Better HN

0 pointsdontlaugh3y ago0 comments

Sum types let you have default values without pervasive nil. That’s not new either, it’s been done since at least ML.

Separate address spaces are trivial when you have a runtime, just look at Erlang.

Go could’ve also copied Erlang’s supervision trees to ensure safe and bounded goroutine lifetime.

For all their impressive achievements, Go’s creators suffer from extreme NIH syndrome. Just look at Plan 9.

0 comments

Thaxll3y ago

When you see the performace of Erlang, you understand why Go did not want to go this way.

dontlaughOP3y ago

There are many other reasons for Erlang having worse overall performance.

Go even shipped with segmented stacks! Also separating goroutine heaps would've been cheap by comparison. It would've also made it easier to achieve good garbage collector throughput, which Go still struggles with to this day.

Go could've also had the `go` keyword work differently, by requiring/returning some kind of handle that must be waited to potentially panic, or explicitly ignored. It would've made it impossible to incorrectly use WaitGroups, without any additional runtime overhead.

Don't get me wrong, Go is still a useful language. It's just frustrating that it failed to be great language for no good reason.

bheadmaster3y ago

Sum types are optional. And if you make them obligatory, they become just syntax sugar for nil. What would be the default value of a non-sum reference type, without nil?

Erlang's "address space isolation" is not real address space isolation, only semantic. Erlang "processes" are all still in the same address space, but the language semantics doesn't allow them to interfere with one another.

You can implement bounded goroutine lifetime by using sync.WaitGroup and other constructs for coordinating goroutines. Go just doesn't force you to.

> Go’s creators suffer from extreme NIH syndrome. Just look at Plan 9.

This is just bad faith arguing. Plan 9 was revolutionary in many ways, and brushing it off as just NIH makes me think you don't understand or recognize its achievements.

dontlaughOP3y ago

An Optional defaulting to None when created can still fail to compile if you don't check whether it's None when you use it. Same with a Result defaulting to an Error.

The problem with nil for any pointer or interface is that you can compile code dereferencing it without first checking if it's nil.

bheadmaster3y ago

> The problem with nil for any pointer or interface is that you can compile code dereferencing it without first checking if it's nil.

Yes, Go doesn't stop you from making mistakes. I think we've already rehashed that a couple of times...

dontlaughOP3y ago

It does stop me from trying to treat a float as an int. It could have trivially also stopped me from many other mistakes.

j / k navigate · click thread line to collapse

0 comments

Thaxll3y ago

When you see the performace of Erlang, you understand why Go did not want to go this way.

dontlaughOP3y ago

There are many other reasons for Erlang having worse overall performance.

Don't get me wrong, Go is still a useful language. It's just frustrating that it failed to be great language for no good reason.

bheadmaster3y ago

Sum types are optional. And if you make them obligatory, they become just syntax sugar for nil. What would be the default value of a non-sum reference type, without nil?

You can implement bounded goroutine lifetime by using sync.WaitGroup and other constructs for coordinating goroutines. Go just doesn't force you to.

> Go’s creators suffer from extreme NIH syndrome. Just look at Plan 9.

This is just bad faith arguing. Plan 9 was revolutionary in many ways, and brushing it off as just NIH makes me think you don't understand or recognize its achievements.

dontlaughOP3y ago

An Optional defaulting to None when created can still fail to compile if you don't check whether it's None when you use it. Same with a Result defaulting to an Error.

The problem with nil for any pointer or interface is that you can compile code dereferencing it without first checking if it's nil.

bheadmaster3y ago

> The problem with nil for any pointer or interface is that you can compile code dereferencing it without first checking if it's nil.

Yes, Go doesn't stop you from making mistakes. I think we've already rehashed that a couple of times...

dontlaughOP3y ago

It does stop me from trying to treat a float as an int. It could have trivially also stopped me from many other mistakes.

j / k navigate · click thread line to collapse