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

41–50 of 466 posts

Re: Why Go Is Not Good (2014)

#41

Post by tptacek »

ltbarcly3 wrote: post #26
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…

>> Experience from languages that support those features has shown that what we gain in the very few situations where those extensions make sense Nope, this is just incorrect. The C++ is completely dominant in large swaths of the software industry largely because operator overloading allows the writing of generic algorithms (which allows you to write large scale software without losing C-like performance). Without op…

Could you go into more detail about why operator overloading enables generic functions in a way simple functions don't? I don't see it.

Re: Why Go Is Not Good (2014)

#42

Post by fixermark »

pcwalton wrote: post #25
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…

> If I need to find all instances of vector addition in my code and I'm searching for '+', I'm going to have a bad time. This is true of methods too. If you're searching for vector addition and you grep for "Add()", you're also going to have a bad time. To have a reliable code indexing scheme, you need typechecking/name resolution information, and once you have that you can easily handle operator overloading as well.

The difference is that "Add" is not a term that many search engines will drop on the floor. When you get out of the range of plain ASCII strings, you're leaving the range of symbols you can assume your tool of choice will be indexing into search for you.

This is likely a short-term reality, but it's the current reality.

Re: Why Go Is Not Good (2014)

#43

Post by aikah »

teps wrote: post #34

The author list features, shows you can't solve them easily with go and then conclude that go is not good. With similar argument, I could list every feature of xml, show that they are not easily solvable with json and conclude that json is not good.

> that json is not good

Json became the defacto serialization format, but in my opinion, Json isn't good for everything. Json and all its tools around it keeps trying to be like XML.

Re: Why Go Is Not Good (2014)

#44

Post by justin_vanw »

tptacek wrote: post #41
ltbarcly3 wrote: post #26

Earlier quoted context omitted.

>> Experience from languages that support those features has shown that what we gain in the very few situations where those extensions make sense Nope, this is just incorrect. The C++ is completely dominant in large swaths of the software industry largely because operator overloading allows the writing of generic algorithms (which allows you to write large scale software without losing C-like performance). Without op…

Could you go into more detail about why operator overloading enables generic functions in a way simple functions don't? I don't see it.

Because you would have to come up with a naming convention ahead of time.

Re: Why Go Is Not Good (2014)

#45

Post by lmm »

hitekker wrote: post #22
hbex5 wrote: post #8

Earlier quoted context omitted.

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.

Is the bunker-mentality a recurring pattern for all Google OSS? I've heard people talking about it in Dart, Angular, and V8/Chrome, and I'm not sure if it's true or not.

I don't think it's Google specific. I'm quite a Scala fan but there was a time when many of us, probably myself included, had an unhealthy bunker-mentality.

Re: Why Go Is Not Good (2014)

#47

Post by Veedrac »

pmilot wrote: post #12

I like this article and I agree with most of what was said there. Against that type of point-by-point criticism, fans of a language will usually use the argument: "but that language was not designed for that!". Then the question becomes: What was that language designed for? My impression was that Go was meant to be a slightly higher-level systems language with better constructs for concurrent programming. With that i…

I can't really see a world in which Rust is a "better Go". Rust is one of the more complex languages in existence, largely because it competes with C++ and thus can't afford to lose many features nor do many things the easy way.

Go is one of the simplest languages in existence. It's on the other side of the charts.

Re: Why Go Is Not Good (2014)

#48

Post by justin_vanw »

fixermark wrote: post #36
ltbarcly3 wrote: post #26

Earlier quoted context omitted.

>> Experience from languages that support those features has shown that what we gain in the very few situations where those extensions make sense Nope, this is just incorrect. The C++ is completely dominant in large swaths of the software industry largely because operator overloading allows the writing of generic algorithms (which allows you to write large scale software without losing C-like performance). Without op…

I think we're talking about different things. Can you give an example of how operator overloading improves one's ability to write a function that can be specialized on types that weren't specifically designed for such use?

Type 1 defines: .add(x)

Type 2 defines: .plus(x)

Type 3 defines: .vector_add(x)

Now, implement a function 'average' that can work on any of these three types.

If you can get everyone in the world to agree to a convention of how to express 'addition', then there is no difference, except we already have a convention for 500 years, and it is the '+' operator. Why you think the '+' operator is confusing but .plus() is not, that is what confuses me.

Or how about 'minimum'. In C people end up writing a minimum C macro, because there's not even a way to write one function that works on int, long, float! What a sad world that is, where you have to meta program to implement min(x,y).

Re: Why Go Is Not Good (2014)

#49

Post by cmrdporcupine »

jd3 wrote: post #37
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…

that's kind of what happens when you take some of the brightest minds that hacked on Plan9 and Inferno for years and have them build a programming language. It's going to be unique. Idealistic. Romantic. reading many of the points here makes me think: alienated java user who doesn't like change

No, not at all. I want more change. Go is a bizarre mix of very conservative mixed with some modern concepts.

We all know Rob Pike is smart. Doesn't mean I have to agree with him. I don't like the things that Go is conservative about. I think the lack of a good way of doing clear type safe operations in a statically typed language is a terrible oversight.

Re: Why Go Is Not Good (2014)

#50

Post by tuyguntn »

If there were GOOD language then all other languages will be dropped. Every language has its own disadvantage, but it doesn't mean its not good, thats just trade-off.

For me main selling point of golang is small lightweight threads with event loop. You write sequential blocking code and you get concurrency built in.

Post reply on HN