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

191–200 of 367 posts

Re: Why Go Is Not Good

#191

Post by axman6 »

stcredzero wrote: post #95
rakoo wrote: post #45

Earlier quoted context omitted.

> Tell me again that Go does nothing new for us. I do agree with the author here: Go the language does nothing new. Go the platform , on the other hand, is a really pleasant new experience when compared with other languages. The language is a regression in features compared to what other languages can do, but that is totally understandable when you look at what Go is aimed at.

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?

Re: Why Go Is Not Good

#192

Post by orclev »

mustpax wrote: post #126
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…

Lack of generics is part of the reason why Go is easier to learn and the Go compiler is faster than, say, Rust. Sure, generics don't have runtime overhead in Rust and Haskell but they have other costs. You always pay for abstractions some way.

Based on this logic I assume you code in nothing but machine code? After all even assembler is an abstraction and therefore must have a cost. Heaven forbid you should do something as extravagant as use C for something, that level of abstraction (all those long jumps and stack manipulations, oh my) must positively destroy performance. Do you also happen to program using the gentle flapping of butterfly wings to disturb air currents and redirect cosmic rays?

Re: Why Go Is Not Good

#193

Post by theseoafs »

stcredzero wrote: post #96
wyager wrote: post #49

Earlier quoted context omitted.

>In modern systems, simplicity is a powerful debugger. I don't consider the features I mentioned in this article to constitute "complexity". I think that Haskell is a beautifully simple language, in the same way that e.g. Euler's identity is beautifully simple. The reasoning behind it may be somewhat complicated, but the result is very simple (and impressive) to behold.

So why not just use Haskell? Why didn't Haskell take over Go's niche?

Because they're completely different languages. The philosophies of the two languages are completely opposite in almost all respects (purely functional vs. procedural, highly general vs. not-general-at-all, and so on and so forth). If you find Go interesting you probably don't find Haskell interesting and vice versea.

Re: Why Go Is Not Good

#194

Post by oscargrouch »

fpgeek wrote: post #154
mustpax wrote: post #114

Earlier quoted context omitted.

There's no question that Rust and Haskell have better tools than C++ for abstracting code. Go is just demonstrating that you can write great software without the aid (and cost) of generics.

What is Go demonstrating about programming without generics that Lisp, Java (pre-2004), Python and tons of other languages haven't already demonstrated?

Nothing, thats the point.. its not language that the creators did because they are vain, or want to prove they are smart, or know what beauty is.. its a language that are created to get things done! the beauty of it its the same beauty that we see in Unix or C.. its simplicity..

Dear God.. I dont know why so many programming languages anyway to do the same thing all over again.. just because of the sake of the sintax or the type system.. or because the guy fell sooo smart because hes using FP.. so he can fell instelectually superior to all human beings

Since C.. its all the same programming paradigm.. the rest is just detail.. the only langs that have its own way that are not cover by the C paradigm are Lisps

Really my language of dreams.. will be to use notes like in a music sheet.. this is a really different paradigm.. or use DSP with just I/O signals.. this is something new.. the rest is just vanity..

And i dont want to be the rat lab of some language designer full of himself, that doesnt think of me, the poor programmer that has to maintain the code in the lang he creates!!

This is the unix philosophy... theres too much noise, im sure these are the kind of things that make people run away from technology...

We need to somehow find our way to simplicity.. for our own sake

Re: Why Go Is Not Good

#195

Post by Peaker »

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…

> Tell me again that Go does nothing new for us

None of the things you mentioned are new.

> Go makes concurrent programming safe and easy

Mutability & concurrency, nils, interface casts -- these things all go against safe.

> Tell me again that there isn't good engineering behind Go.

You seem to think that a language that has baked in syntax for concurrency, or that has famous people behind it necessarily has "good engineering" behind it. I don't understand how one leads to the other.

When so many mistakes and regressions go into a language, one shouldn't care that famous names are behind it.

> Go tackles newer problems in a newer way

Go is essentially Algol 69 with baked in concurrency syntax.

> Tell me again that Go is a regression from other programming languages

Losing null safety, sum types & pattern matching, parameteric polymorphism and type-classes, all form a huge regression in PL design from the state of the art.

Re: Why Go Is Not Good

#196

Post by Peaker »

mseepgood wrote: post #38

So he wants Haskell. Haskell already exists and has all the features he wants. He should have written his blog in Haskell, but he didn't, and I know why: because a language, which throws all these features together is no longer a practical language. He only sees the benefits of features, not the cost they introduce.

Haskell powers quite a few blogs and websites.

The claim that it is "no longer a practical language" is as silly as the "Real World" fallacy.

Re: Why Go Is Not Good

#197

Post by djur »

briantakita wrote: post #121

This article presumes that everybody wants an elaborate type system. I'm not sure that is the case. I still see an elaborate type system as incidental complexity. I may be in the minority and I may not have worked in domains which benefit from such modeling. Maybe I'm stuck in a blub paradigm. Here's my reasoning. I'm a fan of human language & domain ontologies. Word definitions are quite flexible & do not have an el…

This is a good argument in favor of dynamic typing, but Go is not dynamically typed. It has a static type system that its critics consider insufficiently powerful.

Re: Why Go Is Not Good

#198

Post by Perceptes »

briantakita wrote: post #121

This article presumes that everybody wants an elaborate type system. I'm not sure that is the case. I still see an elaborate type system as incidental complexity. I may be in the minority and I may not have worked in domains which benefit from such modeling. Maybe I'm stuck in a blub paradigm. Here's my reasoning. I'm a fan of human language & domain ontologies. Word definitions are quite flexible & do not have an el…

Ambiguity is not something that's generally, if ever, desirable in a program, so if a simpler type system has that to offer, I'm not sure it's a benefit. You could also argue that a more elaborate type system allows you to be more expressive in the design of your programs, rather than restricting you.

Re: Why Go Is Not Good

#199

Post by Peaker »

stcredzero wrote: post #101
wyager wrote: post #83

Earlier quoted context omitted.

>The correct solution is for people to implement languages like Haskell and Clojure in Go, making them execute as fast as possible. Uh, what? Haskell already compiles to native code, and is faster than Go in many cases. Also, if you were implementing a programming language, there are much better languages to do it in than Go.

Depends on your particular value of "better." If you're optimizing for programmer time, writing a language in Go is not a bad tactic. You get out of having to write your own GC, you can incorporate a few nice concurrency features with little effort, and you still get pretty good performance. (Admittedly, far from the best performance, though.)

Writing a language in Go, which doesn't have sum types won't be fun.

Also, if you want to implement a compiler, and not an interpreter, the host language having GC is not very useful to get GC.

Haskell is going to make working with ASTs much easier and safer. It also has a superset of the concurrency features of Go.

Re: Why Go Is Not Good

#200

Post by dbaupp »

richo wrote: post #190
jjnoakes wrote: post #166

Earlier quoted context omitted.

No, you are wrong. First, mapping that page doesn't cause all null pointer dereferences to segfault. And second, the language doesn't require a segfault. In fact, it explicitly permits the implementation to do whatever it likes. That is the difference between safe and unsafe. It is in the language definition.

"The language" ? C doesn't define behaviour of a null deref, but most compilers map a -rwx page there to ensure that attempts to deref fault. In what circumstance do they not?

The compilers don't map pages there, the operating system does. The problem is the compiler will optimise assuming that a null deref never happens, so you can have source that looks like it should crash due to a null deref, but the compiler has "misoptimised" it to have very different behaviour.

http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

Post reply on HN