4 ms·

I think author of this article is strangely biased towards dynamic languages. Go is not about shortest programs in the worlds, yes sometimes code is longer than

by thorn 11y ago

I think author of this article is strangely biased towards dynamic languages. Go is not about shortest programs in the worlds, yes sometimes code is longer than in python. But in Go I can manage code execution and predict memory easier better than in Python or other dynamic languages. Many things in Go were done on purpose. Learn to use Go and it's awesome tools, like gofmt, goimports and others.

fixermark 11y ago
I love Python, up until I remember that I can't make any guarantees of program correctness until I have 100% coverage tests on every line of code because the language is so flexible that it can't tell if a random identifier refers to a variable name that might exist at runtime (but is not determinable to exist at compile time), and therefore most of my variable-name typos that would be compile-time errors in another language are runtime errors in Python. So great for prototyping, not so great for large projects and maintenance (as I've just put the floor of my unit test cost around a factor-of-2 more code).
- TeeWEE 11y ago
  Indeed, with python i can program fastest, but whenever something gets big you had wished i programmed it in golang. However, its still a valid choice to choose python initially. It depends
pcwalton 11y ago
Many of the issues here--for example, the set of built-in slice primitives being inadequate--have ready solutions in other statically typed languages (in this case, generics). These are not problems fundamental to static typing. (For the record, I disagree with some of the criticisms here, for example the slice-of-interfaces type coercion criticism.)
xemdetia 11y ago
I agree strongly with this, it seems like the author has some expectations from his known language pool. Reason #3 about lexical scoping is the big one to me, as you can (and might want to) arbitrarily block variable scopes in many languages. The other components seem to be mostly that Go is still in flux as a language so things that are silly today may be fixed tomorrow, but that's kind of a built in expectation with the ability to transform source files to current. This feels like a lot of the early Java issues that were resolved some time later.

by thorn 11y ago

fixermark 11y ago

I love Python, up until I remember that I can't make any guarantees of program correctness until I have 100% coverage tests on every line of code because the language is so flexible that it can't tell if a random identifier refers to a variable name that might exist at runtime (but is not determinable to exist at compile time), and therefore most of my variable-name typos that would be compile-time errors in another language are runtime errors in Python. So great for prototyping, not so great for large projects and maintenance (as I've just put the floor of my unit test cost around a factor-of-2 more code).

TeeWEE 11y ago
Indeed, with python i can program fastest, but whenever something gets big you had wished i programmed it in golang. However, its still a valid choice to choose python initially. It depends

pcwalton 11y ago

Many of the issues here--for example, the set of built-in slice primitives being inadequate--have ready solutions in other statically typed languages (in this case, generics). These are not problems fundamental to static typing. (For the record, I disagree with some of the criticisms here, for example the slice-of-interfaces type coercion criticism.)

xemdetia 11y ago

I agree strongly with this, it seems like the author has some expectations from his known language pool. Reason #3 about lexical scoping is the big one to me, as you can (and might want to) arbitrarily block variable scopes in many languages. The other components seem to be mostly that Go is still in flux as a language so things that are silly today may be fixed tomorrow, but that's kind of a built in expectation with the ability to transform source files to current. This feels like a lot of the early Java issues that were resolved some time later.