4 ms·

Well I'm the guy who runs that particular blog, and I can tell you I'm no marketing guru. While Reinaldo and I edited the post together, I'm pretty sure that th

by enneff 15y ago

Well I'm the guy who runs that particular blog, and I can tell you I'm no marketing guru. While Reinaldo and I edited the post together, I'm pretty sure that the line was in his original text. (Just checked: it was.) Maybe people keep saying Go feels like an interpreted language because it feels like an interpreted language? :-)

jbarham 15y ago
I've done a fair bit of Go programming (https://github.com/jbarham https://github.com/jbarham), but have programmed professionally mostly in Python for the past 10 years, and for me Go does feel an interpreted language because it requires so few type declarations compared to mainstream statically typed languages like C++ or Java. Checking the app source code for the article at http://code.google.com/p/go-thanksgiving/source/browse/app/app.go http://code.google.com/p/go-thanksgiving/source/browse/app/a..., the only type declaration I can see in the body of a function is in a type switch where it obviously makes sense. Otherwise the code uses the combined declaration and assignment := operator (http://golang.org/doc/go_spec.html#Short_variable_declarations http://golang.org/doc/go_spec.html#Short_variable_declaratio...) which is type-safe because it infers the types from the value(s) on the right hand side. IMO this is even better than working w/ a dynamically typed language like Python because the required parameter type declarations in the function declaration tell you the types you're dealing with, but unlike C++ or Java you don't have to repeat that information back to the compiler.
- alexchamberlain 15y ago
  C++11 has support for inferring types; http://en.wikipedia.org/wiki/C%2B%2B11#Type_inference http://en.wikipedia.org/wiki/C%2B%2B11#Type_inference.
technomancy 15y ago
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.

by enneff 15y ago

jbarham 15y ago

I've done a fair bit of Go programming (https://github.com/jbarham https://github.com/jbarham), but have programmed professionally mostly in Python for the past 10 years, and for me Go does feel an interpreted language because it requires so few type declarations compared to mainstream statically typed languages like C++ or Java. Checking the app source code for the article at http://code.google.com/p/go-thanksgiving/source/browse/app/app.go http://code.google.com/p/go-thanksgiving/source/browse/app/a..., the only type declaration I can see in the body of a function is in a type switch where it obviously makes sense. Otherwise the code uses the combined declaration and assignment := operator (http://golang.org/doc/go_spec.html#Short_variable_declarations http://golang.org/doc/go_spec.html#Short_variable_declaratio...) which is type-safe because it infers the types from the value(s) on the right hand side. IMO this is even better than working w/ a dynamically typed language like Python because the required parameter type declarations in the function declaration tell you the types you're dealing with, but unlike C++ or Java you don't have to repeat that information back to the compiler.

alexchamberlain 15y ago
C++11 has support for inferring types; http://en.wikipedia.org/wiki/C%2B%2B11#Type_inference http://en.wikipedia.org/wiki/C%2B%2B11#Type_inference.

technomancy 15y ago

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.