5 ms·

What do you mean by "strict semantics"? As a PL researcher, I associate "strict" with eager (as opposed to lazy) evaluation, but Go is eager, so you can't mean

by rntz 11y ago

What do you mean by "strict semantics"? As a PL researcher, I associate "strict" with eager (as opposed to lazy) evaluation, but Go is eager, so you can't mean that.

scythe 11y ago
A lot of people say this to mean that object types can't be set to nil. The classic fix is to implement parametrized types (which Go has resisted), although since Go is rabid about simplicity and puts a low priority on generality (generic maps but no other containers, automatic JSON but no other serializations, actor model keywords but no other concurrency primitives, type switch but no real pattern matching), it might better fit the Go philosophy to define only one kind of fallible type, like maybe[T], which is always either T or an error.
- aikah 11y ago
  > generic maps but no other containers Yet it feels like magics. Why just maps? why not sets, with useful set methods ? (union...) . It doesn't feel consistant in a statically typed language. It also feel like a mistrust of the developer. Go doesn't trust me enough so I can implement my own typesafe containers ? or does Go asks me to do the compiler's job by writing code generation tools ? And there is no maybe[T] or we wouldn't need multiple return values when dealing with errors. If there was a maybe[T], we could chain functions and only deal with errors in the last return statement.
  - cpalone 11y ago
    > Why just maps? why not sets, with useful set methods ? Having programmed in Go for production a while now, in my experience it's rarely necessary. Sometimes a set is needed, but it's very simple to just use a map[T]struct{}. And if something like union or intersect is needed it's usually less than 20 lines to implement all those operations. Usually that operation is only needed in one instance, and it's very quick to write. Would it be faster to have a builtin generic set? Absolutely, but it's such a small inconvenience I honestly don't care.
- lenish 11y ago
  > automatic JSON but no other serializations Maybe I'm missing something, but? https://golang.org/src/encoding/xml/example_test.go https://golang.org/src/encoding/xml/example_test.go https://github.com/golang/protobuf https://github.com/golang/protobuf uses this as well.
cgag 11y ago
I do mean eager, I meant as opposed to Haskell, sorry.
- tome 11y ago
  Then are you looking for OCaml?

by rntz 11y ago

What do you mean by "strict semantics"? As a PL researcher, I associate "strict" with eager (as opposed to lazy) evaluation, but Go is eager, so you can't mean that.

scythe 11y ago

A lot of people say this to mean that object types can't be set to nil. The classic fix is to implement parametrized types (which Go has resisted), although since Go is rabid about simplicity and puts a low priority on generality (generic maps but no other containers, automatic JSON but no other serializations, actor model keywords but no other concurrency primitives, type switch but no real pattern matching), it might better fit the Go philosophy to define only one kind of fallible type, like maybe[T], which is always either T or an error.

aikah 11y ago
> generic maps but no other containers Yet it feels like magics. Why just maps? why not sets, with useful set methods ? (union...) . It doesn't feel consistant in a statically typed language. It also feel like a mistrust of the developer. Go doesn't trust me enough so I can implement my own typesafe containers ? or does Go asks me to do the compiler's job by writing code generation tools ? And there is no maybe[T] or we wouldn't need multiple return values when dealing with errors. If there was a maybe[T], we could chain functions and only deal with errors in the last return statement.
- cpalone 11y ago
  > Why just maps? why not sets, with useful set methods ? Having programmed in Go for production a while now, in my experience it's rarely necessary. Sometimes a set is needed, but it's very simple to just use a map[T]struct{}. And if something like union or intersect is needed it's usually less than 20 lines to implement all those operations. Usually that operation is only needed in one instance, and it's very quick to write. Would it be faster to have a builtin generic set? Absolutely, but it's such a small inconvenience I honestly don't care.
lenish 11y ago
> automatic JSON but no other serializations Maybe I'm missing something, but? https://golang.org/src/encoding/xml/example_test.go https://golang.org/src/encoding/xml/example_test.go https://github.com/golang/protobuf https://github.com/golang/protobuf uses this as well.

cgag 11y ago

I do mean eager, I meant as opposed to Haskell, sorry.

tome 11y ago
Then are you looking for OCaml?