Thinking Go is simple is considered harmful(go101.org)
go101.org
Thinking Go is simple is considered harmful
https://go101.org/article/101-about.html
17 comments
For the "cleanup", do you mean finalizers? The runtime.SetFanalizer was ever one of my confusions.
https://go101.org/article/unofficial-faq.html#finalizers
Yes, I was thinking of finalizers.
To me, the main problem with them is that I have no control over when/if they get run. Fortunately, there is defer. ;-)
To me, the main problem with them is that I have no control over when/if they get run. Fortunately, there is defer. ;-)
Ugh. This is just a dumb ad for a dumb book.
Go is a simple language, one of the simplest.
Go is a simple language, one of the simplest.
I'm sorry, no offensive. Your feeling of the extent how you master Go is much like mine of the two years ago.
BTW, this is a free online book. And the go101.org website doesn't embed any third-party advertisements and tracking code.
BTW, this is a free online book. And the go101.org website doesn't embed any third-party advertisements and tracking code.
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.
[1] http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in...
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...
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.
This article is intended to emphasize that you should NOT learn Go with the attitude by thinking Go is a very simple language.
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.
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.
Go had, last I manually counted, a whopping seventeen numeric types. That's a lot of complexity just in interpreting numeric literals!
The underlying types are exposed to you, like C.
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.
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.
Give me a break
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.
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.