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

141–150 of 367 posts

Re: Why Go Is Not Good

#141

Post by frowaway001 »

mustpax wrote: post #64
wyager wrote: post #54

Earlier quoted context omitted.

>But, for systems programming, abstractions suck. Could you clarify what you mean by "systems programming"? To me, that means working with embedded systems, which Go is certainly not appropriate for.

By systems programming I mean writing the code that applications and distributed systems run on top of. Raft ( https://github.com/goraft/raft ) and groupcache ( https://github.com/golang/groupcache ) come to mind as examples. That's a good point though. A lot of people mean different things by systems programming.

> A lot of people mean different things by systems programming.

Actually, no. It meant one thing until Go proponents tried to market their language and realized that their target audience didn't actually care.

Re: Why Go Is Not Good

#142

Post by pcwalton »

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.

> Lack of generics is part of the reason why…the Go compiler is faster than, say, Rust.

The speed of the Rust compiler has little to do with generics and everything to do with LLVM and its optimizations and code generation. (Run with -Z time-passes if you don't believe me.)

Re: Why Go Is Not Good

#143

Post by [deleted] »

plainOldText wrote: post #99

Reading this article and the HN comments made me realize, how people want to use the same language for everything. Unfortunately, this is not possible, since each language was design with certain use cases in mind. I too, am guilty of wanting a language to do everything, to be fast, memory efficient and also easy to program in. Perhaps our ultimate quest in terms of designing languages is to design one smart enough t…

[deleted]

Re: Why Go Is Not Good

#144

Post by dcposch »

> A Good Solution: Constraint Based Generics and Parametric Polymorphism

> A Good Solution: Operators are Functions

> A Good Solution: Algebraic Types and Type-safe Failure

> A Good Solution: Pattern Matching and Compound Expressions

People have tried this approach. See languages like C++ and Scala, with hundreds of features and language specification that run into the thousands of pages.

For an unintentional parody of this way of thinking, see Martin Odersky's "Scala levels": http://www.scala-lang.org/old/node/8610

For additional hilarity, note that it is an undecidable problem whether a given C++ program will compile or not. http://stackoverflow.com/questions/189172/c-templates-turing...

--

Go was created by the forefathers of C and Unix. They left out all of those features on purpose. Not unlike the original C or the original Unix, Go is "as simple as possible, but no simpler".

Go's feature set is not merely a subset of other langages. It also has canonical solutions to important practical problems that most other languages leave do not solve out of the box:

* Testing

* Documentation

* Sharing code and specifying dependencies

* Formatting

* Cross compiling

Go's feature set is small but carefully chosen. I've found it to be productive and a joy to work with.

Re: Why Go Is Not Good

#145

Post by personZ »

We've seen this same article re-written countless ways. Seriously, this is (intentionally or not) a rewording of every existing criticism of Go, by people who complain that it isn't a language that it isn't.

No, Go's solution to generics is not interface{}. The moment you say that, you have lost. You are trying to fight Go and make it a language that it is not.

Always remarkable that such critiques always focus on the utterly trivial, while absolutely ignoring things like concurrency or composing complex systems. As always, the color of the shed is what the laymen want to argue about.

Re: Why Go Is Not Good

#146

Post by rtpg »

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.

Could you elaborate on the costs of the features mentioned about Haskell?

As just one example, ADTs in Haskell are implemented in an extremely efficient fashion.

Type classes are implemented in the same way that Go's interfaces are implemented (basically the same way as vtables are in C++).

The immutability features (const) are compile-time checks, and can even help the compiler be more efficient.

"if as an expression" has no real cost.

Re: Why Go Is Not Good

#147

Post by richo »

Dewie wrote: post #89
TheHydroImpulse wrote: post #79

Earlier quoted context omitted.

Null pointer dereference is unsafe memory access.

Not if you just throw something like an exception when the program tries to do it instead of actually accessing that memory location.

that's what mapping an -rwx page at 0x0 does, and as a result it segfaults, which is an access violation.

Re: Why Go Is Not Good

#148

Post by seanmcdirmid »

dcposch wrote: post #144

> A Good Solution: Constraint Based Generics and Parametric Polymorphism > A Good Solution: Operators are Functions > A Good Solution: Algebraic Types and Type-safe Failure > A Good Solution: Pattern Matching and Compound Expressions People have tried this approach. See languages like C++ and Scala, with hundreds of features and language specification that run into the thousands of pages. For an unintentional parody…

I get what you are saying, but why convolute C++ and Scala? One is a horribly designed complex language with macro-like templates rather than modular parametric polymorphism. The other is much more well designed but, as you say, still complicated. You could have stayed at Scala without degrading into a comparison with C++, which is a universally kicked dog anyways.

It is possible to do type parameters in a way that is simple yet effective. But I can understand why it wasn't done this early in Go's lifetime, especially since Rob Pike isn't exactly well into generics (vs. Odersky's experience with Java/Pizza).

Re: Why Go Is Not Good

#149

Post by wyager »

dcposch wrote: post #144

> A Good Solution: Constraint Based Generics and Parametric Polymorphism > A Good Solution: Operators are Functions > A Good Solution: Algebraic Types and Type-safe Failure > A Good Solution: Pattern Matching and Compound Expressions People have tried this approach. See languages like C++ and Scala, with hundreds of features and language specification that run into the thousands of pages. For an unintentional parody…

>See languages like C++ and Scala

Of the 4 you mentioned (Constraint based generics and parametric polymorphism, operators as functions, algebraic types and type-safe failures, and pattern matching/compound expression) C++ really only has 1 (operators as functions).

>with hundreds of features and language specification that run into the thousands of pages.

This describes neither Rust nor Haskell.

>Go is "as simple as possible, but no simpler".

It has mandatory heap usage, garbage collection, green threads. It's more than generous to call that "as simple as possible".

Of the 5 features you mention that Go has "canonical solutions" to (in the form of external tools), I know off the top of my head that Haskell's Cabal takes care of at least 4 of them. I'm not sure about formatting. Rust probably has similar tools, or if it doesn't, they can certainly be added without changing the language.

Re: Why Go Is Not Good

#150

Post by sanxiyn »

mholt wrote: post #57
autodidakto wrote: post #47

Earlier quoted context omitted.

People use the word "complex" in different ways. Do you mean number of features? Do you mean the size of the compiler? By some measures, operator overloading adds complexity; By another measure, it add simplicity.

I use complexity here the same way the Go community does: it is whatever its authors and users consider it to be. So chances are, if it slows down compilation, it's complexity. If it adds significantly to the grammar or syntax or keyword list, it's complexity. If it does things that can already be done, just differently, it's complexity. If it makes code less clear, it's probably complexity. (You get the idea.)

> I use complexity here the same way the Go community does

It is more important for the implementation to be simple than the interface.

-- http://dreamsongs.com/RiseOfWorseIsBetter.html

Post reply on HN