4 ms·

Sure they are. Sum types usually mean a pattern matching syntax, destructuring, and a different declaration syntax. Rust’s match keyword, for example, is a powe

by sa46 6y ago

Sure they are. Sum types usually mean a pattern matching syntax, destructuring, and a different declaration syntax. Rust’s match keyword, for example, is a powerful construct covering guards, destructuring, and different types of binding. Non-nullability requires generics for a result type which is a huge source of complexity. Generics impact parsing, code gen and runtime efficiency.

entha_saava 6y ago
1) Non nullability can be implemented in language without generics, and for all types instead of just pointer types. That can be used to enforce null checking with pattern like: if let var_name = nullable_var { // use var_name as non nullable } else { // nullable_var in null, handle null case } And any tagged union can be reduced to nullable of member type without pattern matching, with some specific syntax. It is not hard with an imperative language. 2) Without generics, you are probably reinventing the same code, or using reflection which is not even type safe, or worse, using code generation. For instance D has generics AND good compile times. I guess Nim compiles fairly well too. Or you can choose partially type erasure based generics with a different tradeoff. There is no point in not having useful generic functions on generic data structures in a language that came in 2000s. Once write Python or ruby or something and come back to Go. People without knowledge of other languages with generics tend to think you are writing for loop in while loop in if - else break monstrosity because native compilation and performance come with a cost in expressiveness, while it need not be.
- jfkebwjsbx 6y ago
  There is nothing wrong with code generation, what do you mean by "or worse"?
  - deleted 6y ago
    [deleted]
  - centril 6y ago
    Off the top of my head: Poor error messages, any type checking is run on the generated code so harder to enforce properties, and if code generation is not in-language, then the base logic can diverge for different types, which is bad when you find bugs.
qtplatypus 6y ago
However go’s switch statement already acts like pattern matching and destructiving in order to support interfaces.
HideousKojima 6y ago
>Non-nullability requires generics for a result type which is a huge source of complexity. Generics impact parsing, code gen and runtime efficiency. The C# 8.0 approach to non-nullability doesn't require generics at all (though C# already has a robust generic system). They just made reference types work the same as value types, add a ? if you want it nullable, otherwise it isn't. I think Rust's way of doing it with Option is probably a better way, but C#'s way of doing it is definitely more accessible to the average programmer.
Ericson2314 6y ago
You could have a very simple `match` with no nested patterns or guards, like Haskell's core language. > Non-nullability requires generics for a result type which is a huge source of complexity. Option could be another built-in generic like Map in Go. Or one could simply have to write a new Option type ever time. Sucks, but aren't go programmers used to this sort of thing? > Generics impacts runtime efficiency. False

by sa46 6y ago

entha_saava 6y ago

1) Non nullability can be implemented in language without generics, and for all types instead of just pointer types. That can be used to enforce null checking with pattern like: if let var_name = nullable_var { // use var_name as non nullable } else { // nullable_var in null, handle null case } And any tagged union can be reduced to nullable of member type without pattern matching, with some specific syntax. It is not hard with an imperative language. 2) Without generics, you are probably reinventing the same code, or using reflection which is not even type safe, or worse, using code generation. For instance D has generics AND good compile times. I guess Nim compiles fairly well too. Or you can choose partially type erasure based generics with a different tradeoff. There is no point in not having useful generic functions on generic data structures in a language that came in 2000s. Once write Python or ruby or something and come back to Go. People without knowledge of other languages with generics tend to think you are writing for loop in while loop in if - else break monstrosity because native compilation and performance come with a cost in expressiveness, while it need not be.

jfkebwjsbx 6y ago
There is nothing wrong with code generation, what do you mean by "or worse"?
- deleted 6y ago
  [deleted]
- centril 6y ago
  Off the top of my head: Poor error messages, any type checking is run on the generated code so harder to enforce properties, and if code generation is not in-language, then the base logic can diverge for different types, which is bad when you find bugs.

qtplatypus 6y ago

However go’s switch statement already acts like pattern matching and destructiving in order to support interfaces.

HideousKojima 6y ago

>Non-nullability requires generics for a result type which is a huge source of complexity. Generics impact parsing, code gen and runtime efficiency. The C# 8.0 approach to non-nullability doesn't require generics at all (though C# already has a robust generic system). They just made reference types work the same as value types, add a ? if you want it nullable, otherwise it isn't. I think Rust's way of doing it with Option is probably a better way, but C#'s way of doing it is definitely more accessible to the average programmer.

Ericson2314 6y ago

You could have a very simple `match` with no nested patterns or guards, like Haskell's core language. > Non-nullability requires generics for a result type which is a huge source of complexity. Option could be another built-in generic like Map in Go. Or one could simply have to write a new Option type ever time. Sucks, but aren't go programmers used to this sort of thing? > Generics impacts runtime efficiency. False