6 ms·

I see that claim everywhere as well, and I don't understand it. Does it just mean "it has a type system that you won't hate"? There are still plenty of type dec

I see that claim everywhere as well, and I don't understand it. Does it just mean "it has a type system that you won't hate"? There are still plenty of type declarations in that code, whereas if you ported it to OCaml they'd all be inferred.

sirclueless 15y ago
Yes, basically. As far as I can tell Go is entirely about getting rid of unnecessary cruft and boilerplate and making a practical language you won't hate working in. Inasmuch as most interpreted languages are intended to be practical languages you won't hate working in, they are similar to Go. As far as the actual type system, the reason they feel similar is probably because interpreted languages tend to be duck-typed, and so is Go. When you code in an interpreted languages you expect arguments to functions to be of a certain type, where type just means "responds appropriately to methods I call on it". In Go, interfaces are just method specifications and any type that has appropriate methods satisfies the interface. For example, you might have an argument "input" of type "io.Reader"[1] to a function. All this really means is that you expect to be able to call "input.Read()" to populate a byte slice. As a result the implicit type guarantees you expect from an interpreted language and the explicit type guarantees you get from Go are basically the same. [1] http://golang.org/pkg/io/#Reader http://golang.org/pkg/io/#Reader
- masklinn 15y ago
  > As far as the actual type system, the reason they feel similar is probably because interpreted languages tend to be duck-typed, and so is Go. When you code in an interpreted languages you expect arguments to functions to be of a certain type, where type just means "responds appropriately to methods I call on it". The person you respond to talked about OCaml. From this I infer he at least has some basic knowledge of OCaml. You don't seem to have any. Here's a hint: OCaml's object types are structurally typed (and OCaml can actually infer types). Your whole second paragraph is unnecessary (and unwarrantedly condescending), and the first one is basically a lie (Go is chock-full of special syntax and cases, and Go code is full of cruft).
  - 4ad 15y ago
    > Your whole second paragraph is unnecessary (and unwarrantedly condescending) Your whole post is unnecessary and unwarrantedly condescending since all you do is state "truths" like: > Go is chock-full of special syntax and cases, and Go code is full of cruft just like that, out of thin air.
    - masklinn 15y ago
      > just like that, out of thin air. Oh I can expand on that if you want, though I expect you don't and you'll just handwave it away as is usually done of criticisms of Go. * Go uses a special syntax for multiple return values, this is a restriction on the more general concept of tuples. Go could simply provide tuples instead of having MRVs be a syntactic special case. This makes the language smaller and simpler: instead of `,` being a magical syntactic feature of the language, it's just an operator for building tuples. * Go has generic types, but only for blessed types implemented directly in the interpreter (map and channel, for instance). All user-defined types are second-class citizens at best. That's elevating special syntax to new heights. * Go has two different initializers in `new` and `make`, `new` is garbage as it only allocates and can't be used to initialize and `make` only works with (again) a restricted number of types living directly in the runtime, which get to have special treatment for the only reason that new is insufficient. * Talking about things only builtin types get, only builtin types get to be indexed via an operator, this is special syntax dedicated solely to builtin types. * `defer` and `go`. They feature special magical evaluation order (they have to be a complete expression, all inner expressions are evaluated immediately and the outer one and that one only is not evaluated) which leads to weirdness like creating an anonymous function and calling it immediately, and they're not actually needed due to Go having anonymous function in the first place, both could be builtin function taking a callable instead of being special forms and they'd work just as well (better in fact, since their evaluation model would be the same as everywhere else in the language). These special cases are even weirder when you realize that `recover`, which needs to hook deep into the interpreter and do actual strange stuff to stop the stack unwinding in place, is a builtin function rather than a special form. That should be a good start, 4 clear-cut examples of special syntax (either unnecessary or which could/should be general) and one of a special case.
- technomancy 15y ago
  The problem with "it feels like a dynamic language" meaning "you probably won't hate it" is that it's somewhat insulting to existing statically-typed languages that are actually pleasant. It sounds all right if you've only ever been exposed to Java or C, but it's not like Go is the first language to have a good type system. It's especially odd considering Go's inference isn't able to handle all the types in even such a short sample.

sirclueless 15y ago

Yes, basically. As far as I can tell Go is entirely about getting rid of unnecessary cruft and boilerplate and making a practical language you won't hate working in. Inasmuch as most interpreted languages are intended to be practical languages you won't hate working in, they are similar to Go. As far as the actual type system, the reason they feel similar is probably because interpreted languages tend to be duck-typed, and so is Go. When you code in an interpreted languages you expect arguments to functions to be of a certain type, where type just means "responds appropriately to methods I call on it". In Go, interfaces are just method specifications and any type that has appropriate methods satisfies the interface. For example, you might have an argument "input" of type "io.Reader"[1] to a function. All this really means is that you expect to be able to call "input.Read()" to populate a byte slice. As a result the implicit type guarantees you expect from an interpreted language and the explicit type guarantees you get from Go are basically the same. [1] http://golang.org/pkg/io/#Reader http://golang.org/pkg/io/#Reader

masklinn 15y ago
> As far as the actual type system, the reason they feel similar is probably because interpreted languages tend to be duck-typed, and so is Go. When you code in an interpreted languages you expect arguments to functions to be of a certain type, where type just means "responds appropriately to methods I call on it". The person you respond to talked about OCaml. From this I infer he at least has some basic knowledge of OCaml. You don't seem to have any. Here's a hint: OCaml's object types are structurally typed (and OCaml can actually infer types). Your whole second paragraph is unnecessary (and unwarrantedly condescending), and the first one is basically a lie (Go is chock-full of special syntax and cases, and Go code is full of cruft).
- 4ad 15y ago
  > Your whole second paragraph is unnecessary (and unwarrantedly condescending) Your whole post is unnecessary and unwarrantedly condescending since all you do is state "truths" like: > Go is chock-full of special syntax and cases, and Go code is full of cruft just like that, out of thin air.
  - masklinn 15y ago
    > just like that, out of thin air. Oh I can expand on that if you want, though I expect you don't and you'll just handwave it away as is usually done of criticisms of Go. * Go uses a special syntax for multiple return values, this is a restriction on the more general concept of tuples. Go could simply provide tuples instead of having MRVs be a syntactic special case. This makes the language smaller and simpler: instead of `,` being a magical syntactic feature of the language, it's just an operator for building tuples. * Go has generic types, but only for blessed types implemented directly in the interpreter (map and channel, for instance). All user-defined types are second-class citizens at best. That's elevating special syntax to new heights. * Go has two different initializers in `new` and `make`, `new` is garbage as it only allocates and can't be used to initialize and `make` only works with (again) a restricted number of types living directly in the runtime, which get to have special treatment for the only reason that new is insufficient. * Talking about things only builtin types get, only builtin types get to be indexed via an operator, this is special syntax dedicated solely to builtin types. * `defer` and `go`. They feature special magical evaluation order (they have to be a complete expression, all inner expressions are evaluated immediately and the outer one and that one only is not evaluated) which leads to weirdness like creating an anonymous function and calling it immediately, and they're not actually needed due to Go having anonymous function in the first place, both could be builtin function taking a callable instead of being special forms and they'd work just as well (better in fact, since their evaluation model would be the same as everywhere else in the language). These special cases are even weirder when you realize that `recover`, which needs to hook deep into the interpreter and do actual strange stuff to stop the stack unwinding in place, is a builtin function rather than a special form. That should be a good start, 4 clear-cut examples of special syntax (either unnecessary or which could/should be general) and one of a special case.
technomancy 15y ago
The problem with "it feels like a dynamic language" meaning "you probably won't hate it" is that it's somewhat insulting to existing statically-typed languages that are actually pleasant. It sounds all right if you've only ever been exposed to Java or C, but it's not like Go is the first language to have a good type system. It's especially odd considering Go's inference isn't able to handle all the types in even such a short sample.