41–50 of 162 posts
Earlier quoted context omitted.
I thought the criticisms and praise, and the article's Good/Neutral/Bad structure, were fair and thoughtful on balance. It didn't read as arrogant to me.
It did to me. He slams go for not doing stuff the Haskell-way (e.g. pure code vs effectful code). This is not how you approach new things
Apparently, the author of this blog post had a change of heart: https://memo.barrucadu.co.uk/blub-crisis.html > I have realised in recent conversations about programming languages, and in reflection of my very negative and kind of arrogant blog post about Go, that I have become trapped by the Blub Paradox. I have become dismissive of non-Haskell languages. I think in Haskell. Languages less powerful than Haskell are…
Definitely! I couldn't get my head around why people like untyped languages, but I keep an open mind on it. I won't close off that they could be better, if the right patterns/practices are used (whatever they are!)
What do you mean exactly with "liking" untyped languages?
I personally program mainly in both a ("cognitively demanding") typed and an untyped languages, and they have different use cases.
For relatively small programs, untyped languages are much faster to develop. A program I wrote yesterday in a few hours would have taken 2 to 4 times as much in a typed language.
On large libraries (I consider gaming engines as so), common wisdom suggests that typed languages make the project easier to manage (modify and so on).
There's obviously a wide range of use cases in between.
Earlier quoted context omitted.
> other than that it is a very tedious language And that, is precisely why it is a good language for teams.
Yeah it's hard to write weirdly complicated code in Go. Stick Java or C# in the hands of a team and before you know it you've got typed factory service factories and every abstraction known to man.
That line of thinking promotes workarounds over long-term solutions. If your team has people who are abusing tools (like types, abstractions etc), the solution is to teach them how to not do that. The solution is NOT to remove the tool itself! That is like saying that a drilling machine is easier to misuse so "only the hammer is a tool for teams". Ugh.
Go is awesome because of things it _can_ do (it has the speed of C and enough libraries to write full-blown webservices with it). Please don't encourage the whole marketing agenda of touting its shortcomings as advantages. It doesn't work. All it does is it turns people away from the language.
Earlier quoted context omitted.
I thought the criticisms and praise, and the article's Good/Neutral/Bad structure, were fair and thoughtful on balance. It didn't read as arrogant to me.
It did to me. He slams go for not doing stuff the Haskell-way (e.g. pure code vs effectful code). This is not how you approach new things
I agree with everything the author said after having spend some time with Go.
Earlier quoted context omitted.
Go impedes its own readability by encourage or even requiring such huge volumes of code. (And Go ain't very good at concurrency. At least they should have let you mark values as immutable, or communicated entirely via copying like Erlang.) Yes, tuples are a really weird thing with Go. If they had completely left them, that would be bad but sort of defendable. But instead they give you a half-baked implementation of s…
Go is incredibly readable I find. Yes, you tend to find yourself writing a lot of code because of the lack of generics, but that is being fixed as we speak. Generics has a draft and it looks nice from a Go developers perspective. And Go let's you communicate by copying. That's what a Channel is. Pass a struct and that is copied. Pass a pointer and the pointer is copied. The thing it points to isn't copied for glaring…
I'm the opposite, I don't find it readable at all.
I find Go too verbose to be readable.
Earlier quoted context omitted.
Definitely! I couldn't get my head around why people like untyped languages, but I keep an open mind on it. I won't close off that they could be better, if the right patterns/practices are used (whatever they are!)
Well, if your alternative was 90s style Java or C++ static typing, Python-style dynamic typing looks comparatively less insane. As soon as you have algebraic data types and parametric polymorphism, static typing is less onerous, so dynamic typing is less appealing.
Earlier quoted context omitted.
Go impedes its own readability by encourage or even requiring such huge volumes of code. (And Go ain't very good at concurrency. At least they should have let you mark values as immutable, or communicated entirely via copying like Erlang.) Yes, tuples are a really weird thing with Go. If they had completely left them, that would be bad but sort of defendable. But instead they give you a half-baked implementation of s…
Go is incredibly readable I find. Yes, you tend to find yourself writing a lot of code because of the lack of generics, but that is being fixed as we speak. Generics has a draft and it looks nice from a Go developers perspective. And Go let's you communicate by copying. That's what a Channel is. Pass a struct and that is copied. Pass a pointer and the pointer is copied. The thing it points to isn't copied for glaring…
When people disagree on readability its often bc they mean two different things. We would benefit from different terms for readable-in-the-small and readable-in-the-large.
Earlier quoted context omitted.
Definitely! I couldn't get my head around why people like untyped languages, but I keep an open mind on it. I won't close off that they could be better, if the right patterns/practices are used (whatever they are!)
> I couldn't get my head around why people like untyped languages What do you mean exactly with "liking" untyped languages? I personally program mainly in both a ("cognitively demanding") typed and an untyped languages, and they have different use cases. For relatively small programs, untyped languages are much faster to develop. A program I wrote yesterday in a few hours would have taken 2 to 4 times as much in a ty…
I've been using generics with go2go and am looking forward to replacing generated code when they are officially released.
Earlier quoted context omitted.
Definitely! I couldn't get my head around why people like untyped languages, but I keep an open mind on it. I won't close off that they could be better, if the right patterns/practices are used (whatever they are!)
Well, if your alternative was 90s style Java or C++ static typing, Python-style dynamic typing looks comparatively less insane. As soon as you have algebraic data types and parametric polymorphism, static typing is less onerous, so dynamic typing is less appealing.