[TheDong]

Can you give examples of specific language features of go that prevent you from making questionable design choices, that require you to "get the design right up front"?

When I hear that, the first things that come to mind are things like haskell's IO monad, which forces you to model IO better than go or most other languages, or haskell's other state monads which similarly force you to model state more explicitly.

I think of rust's lifetime and ownership system, which forces you to correctly model the ownership of types and prevents quite a few bad design patterns (which I see constantly in go btw; the number of times I've seen races due to multiple goroutines writing to a struct is large, the number of times I've seen incorrect synchronization that rust would have prevented is large).

I can't think of anything in go that pushes you towards designing your code well in go, especially when compared to languages with more complete type-systems.

[randomdata]

> Can you give examples of specific language features of go that prevent you from making questionable design choices, that require you to "get the design right up front"?

No, obviously. I said that Go doesn't give you an escape hatch if you screw up. It does nothing to protect you from screwing up. I specifically said that the challenge was in learning how to not screw up as the language doesn't help you deal with or avoid design mistakes.

[TheDong]

Aaah, I read "Go requires that you get the design right up front" totally wrong, as in "go prevents you from getting the design wrong", not "go lets you get the design wrong, and then doesn't help you".

I still don't get your contrast to other languages though. Are there specific language features other languages have that let you paper over crappy designs?