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

331–340 of 367 posts

Re: Why Go Is Not Good

#331

Post by sergiosgc »

sagichmal wrote: post #328
sergiosgc wrote: post #259

Earlier quoted context omitted.

>I wish developers would stop equating "complicated" to things "I don't understand". The argument is a bit more about evolved than that, but flawed nonetheless. The argument usually invoked for Go is that, by eschewing selected language features, it prevents developers shooting themselves in the foot with unneeded complexity introduced by faulty abstractions. I get the argument. I have seen my fair share of dug-out-f…

> The endgame is "Computer, build me a Mars round-trip ship". I think nobody would argue against that endgame, in the broad strokes. But I think Go can be understood as a response to [what the Go developers perceive as] overly expressive languages, languages that have overstepped our ability to responsibly abstract details, languages whose abstractions hide details that are still important and necessary to make expli…

I agree. That is a correct reading. Where I do not agree is on the assumption that a basic feature set can be construed as a simpler language. While true for the language proper, it isn't true for real usage of language plus libraries.

Take operator overloading. It can be used to create hellish code. It can also be used to create great libraries (numpy for instance). Because of the danger of hellish code, Go makes it impossible to create numpy in Go.

In the end, while Go is simpler, a numpy in Go would be more complex[1], because the language is not expressive enough. The simplicity argument, while true for the language proper, is false for advanced usage.

[1] For example, you can't write Ma * Mb, but must remember the dot product method name.

Re: Why Go Is Not Good

#332

Post by KMag »

jvermillard wrote: post #264

I'm reading that while doing my daily Java code and I stumble on this error : Bound mismatch: The generic method immutableEnumSet(Iterable ) of type Sets is not applicable for the arguments (Integer). The inferred type Integer is not a valid substitute for the bounded parameter > Sorry for advanced type systems but I really want to go back hacking Go code :)

Who holds Java up as a poster child for advanced type systems? You've mad an unintentional straw man argument.

In this particular case, you're using an Integer where a subclass of Enum is called for. The value you're passing may very well be a valid value for the Enum you're trying to use. You may be doing something silly, or it's possible that this is an artifact of generics being bolted on to Java after the fact. In this case, it may be possible for the compiler to infer which Enum you really wanted and insert a runtime check and cast, but then it would be doing you a disservice by silently inserting an opportunity for a runtime error.

I'm not advocating Java's type system, but be glad Java at least has typesafe enums. Every couple of years (across several employers) I run into a very bad bug due to two different return code enums happening to use either 0 or 1 as their "ok" values, and enums of one type being silently cast to the other, resulting in silently okay behavior in the common case and spectacularly bad error recovery in corner cases. Just today I fixed an error where someone had designed an API where an enum of one type was passed to a function needing an enum of a different type, without any translation. Some users had gotten correct behavior by passing an enum of the incorrect type to the API, and some users had followed the API documentation and gotten wrong behavior.

Re: Why Go Is Not Good

#333

Post by nwmcsween »

loup-vaillant wrote: post #260
zimbatm wrote: post #139

Earlier quoted context omitted.

If you truly care about speed you'll have different optimizations for int32 and int64. Depending on who you are working with, the lack of generics is a blessing. Some developers can't restrain themselves and create over-complex abstractions that are used only once.

Generics generally simplify code, you know. Plus, generic code tend to make guarantees non-generic code cannot. Picture this function: foo :: (a -> b) -> (b -> c) -> (a -> c) What does it do? As you can see this function takes 2 arguments, which appears to be functions. It also returns a function. The argument and return type of these functions are unknown, so you can't manipulate them. You can just pass them around…

Parametric polymorphism does not simplify code, it obfuscates it as now you have to see _what_ is calling it. A better form IMO is restricting the types allowed as it: 1. makes understanding much easier, 2. Doesn't create bloat in the form of n copies for visible symbols.

Re: Why Go Is Not Good

#334

Post by KMag »

jules wrote: post #310
rcxdude wrote: post #269

Earlier quoted context omitted.

It depends on how you quantify cost. There isn't any performance cost, yes (which is what 'zero-cost abstractions' usually means in C++), but there is a) an increase in code size, and b) an increase in complexity/difficulty of understanding of implementation (and to some extent use). These may be good tradeoffs to make (in many of the areas where C++ is used they make sense), but I think 'zero-cost' is a disingenuous…

How are generics more difficult to understand than hacking your own mechanism together with casts? That is something I do not understand.

That's the thing. It's easier to hack something together with casts that looks like it's okay, and not understand that you're doing something wrong.

With generics, the novice finds cases where the compiler catches them doing something wrong, so they rewrite the code using casts in a way that looks right but is subtly wrong.

The end result is code that appears correct to the novice, the novice walking away with the feeling that generics are too complicated, and a mysterious corner-case bug that bites off someone's arm once every five years.

The nature of failing to understand is that the person who fails to understand often fails to understand that they misunderstand, or often misattribute their misunderstanding. The tool gets blamed for getting in their way of writing "good" code. On the other hand, there are plenty of tools that give perfectly sensible error messages to anyone with a PhD in type theory, but a second year university student sees "Attempt to cast non-monoid endofunctor to monad. Please uninstall compiler and shave off neck beard."

Re: Why Go Is Not Good

#335

Post by wyager »

riwsky wrote: post #291
wyager wrote: post #117

Earlier quoted context omitted.

>Go makes the cost of generic code explicitly visible. Generics encourage over-generalizing behavior that runs counter to writing highly performant code. I think you may be missing some info regarding generics in Rust and Haskell. As I mentioned in the article, there is zero runtime overhead for generic programming in Rust and Haskell. Zip. Zilch. Nada. That's why their constraint-based static generics system is awes…

Haskell's generic programming constructs do not have zero runtime overhead (at least on GHC, the dominant compiler). Typeclass-overloaded functions take an extra argument at runtime, in which the class "methods" are looked up. In particular, the typeclass-based definition of add3 turns into this Core code, which has an extra "$dNum_az0" arg to carry Num methods: ghci>let add3 a b c = a + b + c ==================== Si…

If you have an explicit type signature and compile with -O, GHC will auto-specialize, afaik.

Re: Why Go Is Not Good

#336

Post by ponce »

Dewie wrote: post #9
oscargrouch wrote: post #6

Go, Rust, Haskell, come from diffent ways of thinking about how to solve problems using programming languages.. Go aims to be more simple and concise, in the end you write less code to do the same thing, as you would in C++, Haskell or Rust.. because those 3 languages decided to "cover everything" and are worried about other things, creating more burden to the programmer, but with something else to gain Go is more of…

> Go aims to be more simple and concise, in the end you write less code to do the same thing, as you would in C++, Haskell or Rust.. I sincerely doubt that Go is more concise than Haskell. I won't say whether concise is good or bad, but I very much doubt that Go is the most concise.

Go doesn't allow to create reusable, zero-cost abstractions so I guess it's not more concise than C++ either.

Re: Why Go Is Not Good

#337

Post by stcredzero »

axman6 wrote: post #191
stcredzero wrote: post #95

Earlier quoted context omitted.

Hmm, so some people are bent out of shape because of feature regression and over the fact that Go doesn't have the newest, shiniest gadgets. However, fans keep saying that their overall experience is great. Reminds me of something else...

The newest, shiniest gadgets? Like generics? You're kidding right?

The newest, shiniest gadgets? Like generics? You're kidding right?

Like putting words into people's mouths as a discussion tactic? You're kidding, right? So it also lacks some not-new "old dependable" gadgets as well. So what?

Re: Why Go Is Not Good

#338

Post by stcredzero »

axman6 wrote: post #191
stcredzero wrote: post #95

Earlier quoted context omitted.

Hmm, so some people are bent out of shape because of feature regression and over the fact that Go doesn't have the newest, shiniest gadgets. However, fans keep saying that their overall experience is great. Reminds me of something else...

The newest, shiniest gadgets? Like generics? You're kidding right?

The newest, shiniest gadgets? Like generics? You're kidding right?

Like putting words into people's mouths as a discussion tactic? You're kidding, right? So it also lacks some not-new "old dependable" gadgets as well. So what? I don't see what point you're making. Did you write that comment just to overlay in indefensible position on me?

As an exercise: Name a language feature Go doesn't have that's newer than generics.

Re: Why Go Is Not Good

#339

Post by stcredzero »

sergiosgc wrote: post #331
sagichmal wrote: post #328

Earlier quoted context omitted.

> The endgame is "Computer, build me a Mars round-trip ship". I think nobody would argue against that endgame, in the broad strokes. But I think Go can be understood as a response to [what the Go developers perceive as] overly expressive languages, languages that have overstepped our ability to responsibly abstract details, languages whose abstractions hide details that are still important and necessary to make expli…

I agree. That is a correct reading. Where I do not agree is on the assumption that a basic feature set can be construed as a simpler language. While true for the language proper, it isn't true for real usage of language plus libraries. Take operator overloading. It can be used to create hellish code. It can also be used to create great libraries (numpy for instance). Because of the danger of hellish code, Go makes it…

Is it necessarily a good idea to make Go into a number crunching language?

Re: Why Go Is Not Good

#340

Post by stcredzero »

oscargrouch wrote: post #323
illumen wrote: post #251

Earlier quoted context omitted.

Rust and Haskell are made to reduce the amount of problems you have. I've seen newbie programmers learn Haskell as a first language in under a term. So I don't believe the marketing from the Google people that their language is worse because it is simpler. Choosing something because marketing told you it was easier is just as silly as choosing something because of ego. Calling people egoists when they choose a tool b…

> Choosing something because marketing told you it was easier is just as silly as choosing something because of ego. Calling people egoists when they choose a tool because of reasoned arguments based on evidence is simply anti-intellectual, and rude. I Just dont know where in the post i did say something like that.. marketing? egoists? where did i said that? If you happen to be above average in say english language f…

If you happen to be above average in say english language for instance.. and you know a lot of words and sentences, poems.. but the thing is.. if you choose the speak in the english you know better, you will communicate with fewer people.. or you can just jump to a lower level to communicate so everybody can understand..

Intended side effect of irony?

Post reply on HN