Why Go Is Not Good (2014) • Hacker News Board

Re: Why Go Is Not Good (2014)

#281

Post by TheDong » Wed, Dec 09, 2015, 6:38 PM UTC

nteon wrote: post #30

cmrdporcupine wrote: post #15

Earlier quoted context omitted.

Then it needs to stop calling itself a 'systems programming language.' Or maybe it doesn't, but others need to stop calling it that. To me, it's a replacement for Java, not C++. I think that's a reasonable target. Mandatory GC, lack of generics and therefore rampant use of downcasting & duck typing -- these make it difficult to write safe and fast code for systems level or embedded type work.

C doesn't have generics, and is certainly a systems language. I don't think you have a strong point here. Systems != embedded.

C has generics as of C11 via '_Generic'. Google can tell you more, and here's a blogpost with examples: http://abissell.com/2014/01/16/c11s-_generic-keyword-macro-a...

Re: Why Go Is Not Good (2014)

#282

Post by ionforce » Wed, Dec 09, 2015, 6:38 PM UTC

gbhn wrote: post #235

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…

My (inexpert) opinion is that the kind of computer language researcher or practitioner interested in exploring how far you can go with type systems is dissatisfied with Go. But there are many types of static analysis which accomplish similar (or more dramatic) goals than what can be down with type analysis, and the simplicity of a language makes those kinds of analyses more reachable. Examples: gofmt and gofix. I thi…

What part of types is change resistant?

Re: Why Go Is Not Good (2014)

#283

Post by oscargrouch » Wed, Dec 09, 2015, 6:38 PM UTC

insulanian wrote: post #115

When one mentions Go, I imagine the crowd. When one mentions Haskel/OCaml/F#, I imagine an artist.

Whats the problem in enabling more people to program computers like Python, Go and Javascript does?

And the most funny thing about this arrogant attitude for some languages, is that the greatest popular tools, and the "killer apps" tend to occur in those languages.. as a indication that there is actually pretty smart people using the language contrary to common believe.

So is more likely that the "artist" might actually end using Go than Haskell

Re: Why Go Is Not Good (2014)

#284

Post by eropple » Wed, Dec 09, 2015, 6:42 PM UTC

15155 wrote: post #183

bndr wrote: post #56

Earlier quoted context omitted.

> Any critique of Go seems to be met with angry pitchforks in this place. You can say that about any language. The people that like the language will always defend it. e.g. PHP, C, Ruby. They all have flaws and yet when one talks about their shortcomings, the people get defensive.

Talk about the (legitimate) Haskell shortcomings and you'll be met with open, honest acceptance, mitigation strategies, and academic discussion. IRC, /r/haskell, whatever.

Rust too. The bunker mentality of the Go community is not unique, but its fervency, I think, is not currently matched anywhere else.

Re: Why Go Is Not Good (2014)

#285

Post by doodpants » Wed, Dec 09, 2015, 6:43 PM UTC

issaria wrote: post #168

This post seems to rising from ash. Definitely saw it on HN year ago. I don't want to say the word "perfect language", but there is no such language that can meet the demands of every nerd on the planet, the goal of the Go programming language is stated clearly, compiling speed overweight the needs for generics, that's why LLVM is not considered for the go compiler. Also the language is considered feature complete, i…

One of my big peeves is when a blog does not have a date stamp at the top of each post. Some have the date at the bottom of the post, which is less convenient, but at least it's there. Others don't have a date stamp at all, but you can guess when the post was written by looking at the date of the earliest comment, or the date is included as part of the permalink URL.

Will Yager's blog seems to have no possible way of determining when a post was written. Which is especially frustrating since the very first paragraph of the post in question includes the phrase "at the time of writing". Well, when was that!?

Re: Why Go Is Not Good (2014)

#286

Post by [deleted] » Wed, Dec 09, 2015, 6:46 PM UTC

hbex5 wrote: post #8

cmrdporcupine wrote: post #2

While many of these points (on generics especially) are completely legitimate, this article will fall on deaf ears. My impression of the Go community (both within Google and outside of it) is that there is a very ... moralistic? .... sense of "You don't really need that, we know best" going on. It aims to be a pragmatic language. But IMHO the anemic nature of the type system is a practical handicap that they have mad…

Any critique of Go seems to be met with angry pitchforks in this place. As you say, the Go developers seem to have developed a kind of bunker mentality where they interpret legitimate criticisms of the language design as personal attacks, and respond by wearing Go's shortcomings as a badge of honour. It's not, I think, entirely healthy.

[deleted]

Re: Why Go Is Not Good (2014)

#287

Post by BinaryIdiot » Wed, Dec 09, 2015, 6:47 PM UTC

fixermark wrote: post #6

"Go does not support operator overloading or keyword extensibility." Very much working as intended, I believe. Experience from languages that support those features has shown that what we gain in the very few situations where those extensions make sense (such as defining mathematical operations on vectors using the same symbols that are used in vector mathematics), we lose in too many developers thinking they have a…

While I think your point about using them improperly is good (I know I've seen some weird shit back in the day I did C++) I still think there is merit to allowing operator overloading. Many times you may create units that should work when added together but need unique logic to make it happen and that just can't happen in GO today (you have to make an add() method or something similar).

So I think operator overloading can be exploited pretty horribly but can also make code far more intuitive. It's certainly not something that can't be worked around but I always err on the side of letting it happen and the community can direct people to using them most properly.

Re: Why Go Is Not Good (2014)

#288

Post by fizzbatter » Wed, Dec 09, 2015, 6:48 PM UTC

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

> If you incorrectly cast an interface{} to a type it's not, it will be a runtime error.

Sidenote, you may or may not have meant a panic - so i just want to clarify.

Casting an interface to a type incorrectly will not cause a panic/crash, assuming you use the proper syntax.

    // Will panic
    foo := myInterface.(BadType)
    // Will not panic
    foo, ok := myInterface.(BadType)

In the latter, you simply check if `ok` is true or not. If not, the interface value does not implement the given type/interface.

Re: Why Go Is Not Good (2014)

#289

Post by SneakerXZ » Wed, Dec 09, 2015, 6:49 PM UTC

bliti wrote: post #233

cmrdporcupine wrote: post #2

While many of these points (on generics especially) are completely legitimate, this article will fall on deaf ears. My impression of the Go community (both within Google and outside of it) is that there is a very ... moralistic? .... sense of "You don't really need that, we know best" going on. It aims to be a pragmatic language. But IMHO the anemic nature of the type system is a practical handicap that they have mad…

I've written and maintain various Go systems and agree. Go is like Rails was about 5 years ago. It ends up hurting the community members themselves in the end. I won't abandon the language because it works well for my use case, but I'm not pouring any open source efforts into it.

But Ruby is at least syntactically very powerful. Go feels like it was written to have fast parser but this they killed with the latest version.

Re: Why Go Is Not Good (2014)

#290

Post by crimsonalucard » Wed, Dec 09, 2015, 6:50 PM UTC

Imagine a flawless gemstone with a permanent stain on one of the edges. This is go, and this is why people complain endlessly.

The creators of go only look at the gemstone from a single angle. So they never see the stain and they really don't care. When people complain to them, they just tell the complainers that they're looking at the gemstone from the wrong angle.