afaik the bulk of those are just related to sizing (16 bits, 32 bits, etc). it's not really that complex, and generally quite handy for a language like go.
Go isn't adding sugar to handling numeric types: it's not autoboxing to help you with conversions, and it's not hiding the implementation like a scripting language. I'll admit, it's a real pain when trying to convert from one type to another (e.g., in graphics programming, where I'm changing types from internal representations to what gets drawn to the screen). For most "job" programming, it was a non-issue and I felt secure in knowing what types, sizes, and representations I'm really using.
I ever had many confusions in studying Go, but I never had any confusions on numeric literals. Go nmeric literals are intuitive and consistent with many other popular languages.
I really want to use Go and I already know the language itself but this post[1] makes me scared to the point where a language as big as Scala makes more sense to me than learning a simple language but with a ton of things on the side to know. Is it really accurate compared to this post?
I feel like I will have more to learn with Scala but at least it will be useful things.
This post is too detailed. For many of these problems, no one is going to get "gotcha'd" by a problem which the compiler gives you a detailed error message for. Go is by no means flawless, but you usually face simple problems which might stump you for a moment but usually have easy and readily found solutions.
Scala, on the other hand, is much harder to understand and much easier to write bad code in. I still don't know what the idiomatic way of doing many tasks in Scala is, the type model is nigh impossible to wrap your head around, the docs are scatterbrained and inconsistent, and I've spent way more time than I would like trying to get sbt in line.
I'm so sorry if this article scares you.
This is not the intention of this article.
In fact, Go is a relative simpler language comparing to many other popular static languages.
This article is intended to emphasize that you should NOT learn Go with the attitude by thinking Go is a very simple language.
Go is simple in the sense that there is very little "magic", i.e. very little code that executed that might not be obvious right away: No constructors, no destructors[0], no operator overloading, etc. This makes relatively easy to get a reasonably-accurate mental model of what is going on. Perhaps more importantly, its community has a culture that encourages simplicity of design, avoiding fancy tricks, etc.
Using features like concurrency and interfaces in ways that are considered idiomatic is not exactly trivial, I think. But it's not that hard, either. At work, I have been using C# quite a bit lately, and while I think it is a well-designed language, it is far more complex than Go (cough async cough).
I don't think what you are saying is wrong, but I think the title of the posting is easily misunderstood.
[0] IIRC, one can ask for a "cleanup" function to be called when an object is about to be harvested by the garbage collector, but one has to do so explicity, and from what I have seen, it is not used commonly.
17 comments
[ 2.7 ms ] story [ 47.4 ms ] threadGo isn't adding sugar to handling numeric types: it's not autoboxing to help you with conversions, and it's not hiding the implementation like a scripting language. I'll admit, it's a real pain when trying to convert from one type to another (e.g., in graphics programming, where I'm changing types from internal representations to what gets drawn to the screen). For most "job" programming, it was a non-issue and I felt secure in knowing what types, sizes, and representations I'm really using.
Go is a simple language, one of the simplest.
I feel like I will have more to learn with Scala but at least it will be useful things.
[1] http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in...
Scala, on the other hand, is much harder to understand and much easier to write bad code in. I still don't know what the idiomatic way of doing many tasks in Scala is, the type model is nigh impossible to wrap your head around, the docs are scatterbrained and inconsistent, and I've spent way more time than I would like trying to get sbt in line.
This article is intended to emphasize that you should NOT learn Go with the attitude by thinking Go is a very simple language.
BTW, this is a free online book. And the go101.org website doesn't embed any third-party advertisements and tracking code.
Using features like concurrency and interfaces in ways that are considered idiomatic is not exactly trivial, I think. But it's not that hard, either. At work, I have been using C# quite a bit lately, and while I think it is a well-designed language, it is far more complex than Go (cough async cough).
I don't think what you are saying is wrong, but I think the title of the posting is easily misunderstood.
[0] IIRC, one can ask for a "cleanup" function to be called when an object is about to be harvested by the garbage collector, but one has to do so explicity, and from what I have seen, it is not used commonly.
To me, the main problem with them is that I have no control over when/if they get run. Fortunately, there is defer. ;-)