Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Go Is Not Good

yager.io

Post reply on HN
Print view View original

51–60 of 367 posts

Re: Why Go Is Not Good

#51

Post by cgag »

mholt wrote: post #22
s_kilk wrote: post #3

This was a good read. Can anyone comment on whether they find the problems outlined in the article to really be painful in day-to-day go development? From my initial dabblings with the language, it feels like its constraints may not actually be a big deal in practice, and may even be more of a help than a hindrance in large projects. It would be nice to get some commentary from more experienced go users.

In practice, Go has caused me less frustration than any other language I've used. I feel like the author's complaints here aren't really grounded in much experience, or maybe he's trying to use the wrong tool for the job. The author's conclusion: · Go doesn't really do anything new. · Go isn't well-designed from the ground up. · Go is a regression from other modern programming languages. is hardly sustainable. Go was…

Ok, I'll point out again that it emphasizes both concurrency and mutability which is a match made in hell and has a type system that's constantly subverted by null pointers and casts to interface which drastically reduce safety. It has a static type system released in the 2010s that doesn't have generics and deploying static binaries is not a new technology.

Re: Why Go Is Not Good

#52

Post by wyager »

autodidakto wrote: post #42

Possible error: >If you want to modify a data structure, you have to create an entirely new data structure with the correct changes. This is still pretty fast because Haskell uses lazy evaluation. I believe the issue is persistent data structures -- the new data structure "remembers" the old one (instead of recreating it) and records changes. (Clojure works like this as well) -- and not lazy evaluation.

I meant that, despite the fact that adding an element to a tree in Haskell naively constitutes "making a new tree", Haskell usually doesn't end up actually make a whole new tree (because of lazy evaluation), so trees are still really fast.

Re: Why Go Is Not Good

#54

Post by wyager »

mustpax wrote: post #50

There's something very seductive about languages like Rust or Scala or Haskell or even C++. These languages whisper in our ears "you are brilliant and here's a blank canvas where you can design the most perfect abstraction the world has ever seen." But, for systems programming, abstractions suck. They always, always have a cost. When abstractions break, you not only have to deal with a broken system but the broken ab…

>But, for systems programming, abstractions suck.

Could you clarify what you mean by "systems programming"? To me, that means working with embedded systems, which Go is certainly not appropriate for.

Re: Why Go Is Not Good

#55

Post by AndreasFrom »

andrejewski wrote: post #15

I am completely in support of Haskell and functional languages in general. There are some gaps in Go and definitely some glaring problems. But this comparison also only lists the bad. Go is good for what it was intended for which is concurrent programming and server/web application. Just a note: I don't think it is fair to say Go has absolutely no immutability as it was defined, it does have "const". See http://golan…

`const` is for compile-time constants where something like `let` in Rust can be used for values generated on the fly. The latter is immensely more powerful and actually provides the described benefits like guaranteeing that data is not changing under your feet.

Edit: While `const PI = 3.1415…` is threadsafe, it's not very useful in comparison to runtime-immutability :)

Re: Why Go Is Not Good

#56

Post by pcwalton »

mustpax wrote: post #50

There's something very seductive about languages like Rust or Scala or Haskell or even C++. These languages whisper in our ears "you are brilliant and here's a blank canvas where you can design the most perfect abstraction the world has ever seen." But, for systems programming, abstractions suck. They always, always have a cost. When abstractions break, you not only have to deal with a broken system but the broken ab…

> When abstractions break, you not only have to deal with a broken system but the broken abstraction itself too. (Anyone who has ever seen a gcc compiler error for C++ knows how this feels.)

Using C++ template error messages to attack generics in Rust and Haskell is pretty weak, because typeclasses were explicitly designed to avoid the problems of "ad-hoc" templates in languages like C++. Error messages are in fact what typeclasses are really good at.

Re: Why Go Is Not Good

#57

Post by mholt »

autodidakto wrote: post #47
mholt wrote: post #41

The author is using a sharp blade as his implication for good : features that make a language more complex. If the added complexity is "good" to you, then fine. In modern systems, simplicity is a powerful debugger. Adding all those features that the author talks about -- "Constraint-based Generics and Parametric Polymorphism", "Algebraic Types and Type-safe Failure Modes", and "Pattern Matching and Compound Expressio…

People use the word "complex" in different ways. Do you mean number of features? Do you mean the size of the compiler? By some measures, operator overloading adds complexity; By another measure, it add simplicity.

I use complexity here the same way the Go community does: it is whatever its authors and users consider it to be. So chances are, if it slows down compilation, it's complexity. If it adds significantly to the grammar or syntax or keyword list, it's complexity. If it does things that can already be done, just differently, it's complexity. If it makes code less clear, it's probably complexity. (You get the idea.)

Re: Why Go Is Not Good

#58

Post by dualogy »

mustpax wrote: post #50

There's something very seductive about languages like Rust or Scala or Haskell or even C++. These languages whisper in our ears "you are brilliant and here's a blank canvas where you can design the most perfect abstraction the world has ever seen." But, for systems programming, abstractions suck. They always, always have a cost. When abstractions break, you not only have to deal with a broken system but the broken ab…

> Generics?

Built-in slice and map types cover most real-world needs quite neatly anyway.

Re: Why Go Is Not Good

#59

Post by tjholowaychuk »

I also don't get why the for-loop uses a "range" keyword at all, isn't that what typing is for, can't it just figure out that the type is enumerable?

I like most of Go so far, but interface{} is possibly the ugliest artifact of a programming language that I've seen, next to pretty much all of c++

Rust and Go should have a baby

Re: Why Go Is Not Good

#60

Post by axaxs »

s_kilk wrote: post #3

This was a good read. Can anyone comment on whether they find the problems outlined in the article to really be painful in day-to-day go development? From my initial dabblings with the language, it feels like its constraints may not actually be a big deal in practice, and may even be more of a help than a hindrance in large projects. It would be nice to get some commentary from more experienced go users.

Been writing Go at least weekly for a while now - no, none of these things are painful in daily usage - they seem like items that are painful in theory but not so much in everyday use, especially in the realm it is intended for.
Post reply on HN