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

Why Go Is Not Good (2014)

yager.io

Post reply on HN
Print view View original

401–410 of 466 posts

Re: Why Go Is Not Good (2014)

#401

Post by wyager »

AnimalMuppet wrote: post #393
wyager wrote: post #232

Earlier quoted context omitted.

> read the Preface in Alan Donovan and Brian Kernighan's "The Go Programming Language" I have read it :) I think it's both misguided and misleading. It's misguided because they have the wrong idea about simplicity, and it's misleading because they claim that Go is "radically simple". Go isn't really that simple; it's just inconveniently incapable.

> It's misguided because they have the wrong idea about simplicity... No, it's not your idea of simplicity. It's not wrong, it's different. That's all. You're falling into the "my way is the right way" arrogance that so many here are accusing the Go advocates of.

>No, it's not your idea of simplicity. It's not wrong, it's different.

What is your point? That words have no objective meaning and no one can ever be wrong ever?

I'm operating under the assumption that most people have a definition of simplicity that's similar to mine. Go is not simple under a very broad definition of "not simple". I'm not saying using Go is the wrong way to do things; I'm saying this classification is misleading.

Re: Why Go Is Not Good (2014)

#402

Post by commentzorro »

evmar wrote: post #91

This sort of gratuitous takedown is unfortunately crack for HN -- pages and pages of "here's how this popular thing is not like this other thing I like", without any thought given to why things are they way they are. Go is missing a lot of my pet features too but I know its authors are smart so I don't just immediately jump to assuming they don't know what they're doing. Thought experiment: write a proposal that work…

We don't want Haskell. We don't want Rust. We don't want any of the current top twenty. We want Go-ish. We want the wonderful stuff that Go does have, but we want a few more high level features too.

I suppose once that language comes along we can stop our constant whining ;-)

Re: Why Go Is Not Good (2014)

#403

Post by sanderjd »

loudmax wrote: post #298
pkulak wrote: post #161

Earlier quoted context omitted.

I think everyone who uses Go for anything is pretty clear about why they like it, and one of the major reasons is simplicity. So why are people then surprised when criticisms over lack of features fall on deaf ears? And to be honest, this whole argument about pitchforks seems like a straw man. If anything, it's currently fashionable to dump on Go at every opportunity. Hell, it's fashionable to dump on everything arou…

Agreed. I foresee a great future for Rust, and also a great future for HN posts in the form: "I know I'll get downvoted for this, but Rust is a terrible language because it lacks the following features..."

In the medium to long run, I suspect criticism of Rust will be more along the lines of criticism of C++ – too ambitious, too many features, too hard to do simple things, too easy to do unsafe low level things – rather than along the lines of "lacks these features".

Re: Why Go Is Not Good (2014)

#404

Post by sanderjd »

jshen wrote: post #388
sanderjd wrote: post #373

Earlier quoted context omitted.

I agree with most of your "so what?" point, but I think the lodash / FP thing is interesting because javascript is also not trying to be a functional programming language, and nor are the many other languages that have popular higher-order-function libraries (eg. Java, C#, Ruby, Python). There's a long trend of pulling in the ideas from functional languages that have proven to be generally useful, like lodash / Java…

As was mentioned before, you can absolutely do the same thing in Go that you see in lodash by giving up type-safety which javascript doesn't have anyway!.

I actually saw that post right after I wrote the one you just responded to. While it's definitely true, what makes it more awkward in Go is the necessity to translate back and forth between the "traditionally typed" and "unityped" dialects of the language. I'm not (only) referring to performance here, but ergonomics. Because javascript is unityped everywhere, a unityped implementation of those sorts of functions is natural, but because Go is mostly type-based, it is less natural and more boilerplate-y to pass and return `interface{}` everywhere. Nonetheless, it's a good point.

Re: Why Go Is Not Good (2014)

#405

Post by 4ad »

kyrra wrote: post #241
cmrdporcupine wrote: post #162

Earlier quoted context omitted.

And so, basically, does Go.

Except there is a fairly large difference with interface{}, in that it is typed. interface{} is more like Object in java than void* from C. If you incorrectly cast an interface{} to a type it's not, it will be a runtime error. Details: http://research.swtch.com/interfaces

Go doesn't have casts. It has conversions and type assertions. This is a type assertion.

Re: Why Go Is Not Good (2014)

#406

Post by commentzorro »

Filligree wrote: post #198
TeeWEE wrote: post #75

Earlier quoted context omitted.

Ever wrote a big program in python? Then you know it works at runtime. Not at compile time. Go comes with more typesafety while being a bit more verbose. Its a tradeoff.

And yet Rust has more type safety, while being more concise, more expressive and faster. Which is the article's point.

Rust forces you to care too much about memory and object ownership. These are too low in the weeds for business and web applications. (But wholly appropriate for a systems level language.)

Re: Why Go Is Not Good (2014)

#407

Post by AnimalMuppet »

wyager wrote: post #401
AnimalMuppet wrote: post #393

Earlier quoted context omitted.

> It's misguided because they have the wrong idea about simplicity... No, it's not your idea of simplicity. It's not wrong, it's different. That's all. You're falling into the "my way is the right way" arrogance that so many here are accusing the Go advocates of.

>No, it's not your idea of simplicity. It's not wrong, it's different. What is your point? That words have no objective meaning and no one can ever be wrong ever? I'm operating under the assumption that most people have a definition of simplicity that's similar to mine. Go is not simple under a very broad definition of "not simple". I'm not saying using Go is the wrong way to do things; I'm saying this classification…

> I'm operating under the assumption that most people have a definition of simplicity that's similar to mine.

Perhaps you shouldn't assume that. But whether you're right or wrong in assuming that most people have a definition of simplicity that's similar to yours, it's another step to say that Donovan and Kernighan's definition is wrong. It's that second step that I'm criticizing you for.

Plaugher has been very clear about what he means by "simplicity" in Go. (I suspect the same is true of Donovan and Kernighan, though I haven't read their intro.) So, yes, the word "simple" has a clearly defined meaning for them. It also has a different, perhaps less clearly defined, meaning for you.

Again, it's fine for you to disagree. But to say that their definition is wrong? That sounds both arrogant and childish. More to the point, it seems unlikely that you are right that their definition is [objectively] wrong.

[Edit: Where did Go come from? It came from trying to solve the problems of working on ten-million-line code bases for a decade or two. That experience gave them definite ideas about what "simplicity" means. It's fair to say that most people don't have that definition. But you don't have the right to say their definition is wrong unless you've worked in that environment long enough to know what the problems are.]

Re: Why Go Is Not Good (2014)

#408

Post by antod »

TeeWEE wrote: post #75
mydpy wrote: post #35

When I first learned Python and Scala, they 'hooked' me practically instantly. As my ability with these languages matured, I learned their strengths and weaknesses, and (try) use the tools where their strengths are complimented. Trying Go had practically the opposite emotional response: It didn't take long to get a bad taste in my mouth while using the language (a lot of, where is feature X from my favorite language,…

Ever wrote a big program in python? Then you know it works at runtime. Not at compile time. Go comes with more typesafety while being a bit more verbose. Its a tradeoff.

I can't speak for the other poster, but I reckon someone who liked both Python AND Scala would have a pretty good handle on the pros and cons of different type systems.

Re: Why Go Is Not Good (2014)

#409

Post by spion »

AnimalMuppet wrote: post #356
spion wrote: post #330

Earlier quoted context omitted.

As far as I can tell, conclusions are based on facts about the language as well as other languages. Maps, slices and channels are generics. I'd like to see code in Go written without maps, slices or generics. Go will never implement immutable data structures. Its impossible to write an immutable data structure library without generics. Go will never implement Futures / Tasks / Observables. Its impossible to write Fut…

You're coming from the same bias as the author of the article: Haskell and Rust are what a language should look like; Go doesn't look like that, therefore Go is bad. Take one of your points: > Go will never implement immutable data structures. Its impossible to write an immutable data structure library without generics. Fine; I won't argue whether your statement is correct. But so what? That only turns into something…

Once you get data races in Go, you realize that immutable data structures are indeed the right way. Too bad though. That non-threadsafe, racy map is your only generic data structure.

I think that critics are generally cutting way too much slack to Go. Its a horrible language - with a decent library and excellent tooling and documentation, but still quite horrible.

Re: Why Go Is Not Good (2014)

#410

Post by AnimalMuppet »

spion wrote: post #409
AnimalMuppet wrote: post #356

Earlier quoted context omitted.

You're coming from the same bias as the author of the article: Haskell and Rust are what a language should look like; Go doesn't look like that, therefore Go is bad. Take one of your points: > Go will never implement immutable data structures. Its impossible to write an immutable data structure library without generics. Fine; I won't argue whether your statement is correct. But so what? That only turns into something…

Once you get data races in Go, you realize that immutable data structures are indeed the right way. Too bad though. That non-threadsafe, racy map is your only generic data structure. I think that critics are generally cutting way too much slack to Go. Its a horrible language - with a decent library and excellent tooling and documentation, but still quite horrible.

> Once you get data races in Go, you realize that immutable data structures are indeed the right way.

False. There are more things in multi-threaded programming than are dreamt of in your philosophy. For some of them, immutability is very much the wrong way. It means some threads will be playing with stale data for some time.

I'm not saying that I'd want to write that kind of a program in Go, mind you. But your over-generalization is blatantly false.

And, in fact, I suspect that most people writing in Go aren't writing the kind of program where you could get data races at all. Multithreaded programming in Go (if I understand correctly) is mostly a matter of handling multiple independent data streams, not threads that need to access the same data objects.

I suspect that your over-generalization in the second paragraph is equally false, but I have less experience to validate that opinion.

Post reply on HN