Why Go Is Not Good • Hacker News Board

Re: Why Go Is Not Good

#261

Post by dbaupp » Mon, Jun 30, 2014, 11:41 AM UTC

wtetzner wrote: post #257

tinco wrote: post #81

Earlier quoted context omitted.

I don't agree with the GP, but if Go were very similar to C and the only big difference would be that C has no GC it would pretty easy to picture what the C equivalent of Go code would be. Exactly the same but with calls to `free()` at the end of some functions. (or preempted between instructions at unpredictable places) Don't make GC's a bigger deal then they are. They are a tool to remove the need to call `free()`…

> They are a tool to remove the need to call `free()` at the right time, with the downside that you don't get to control what the GC thinks is a right time instead. That's not actually true. They also allow you to do things that you otherwise couldn't. Try implementing persistent [1] maps or sets without a GC. [1] http://en.wikipedia.org/wiki/Persistent_data_structure

That's still just a problem of deciding when to call free.

Re: Why Go Is Not Good

#262

Post by zik » Mon, Jun 30, 2014, 11:59 AM UTC

Peaker wrote: post #199

stcredzero wrote: post #101

Earlier quoted context omitted.

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.

I'm writing a language in Go. It is fun. Sum types (and ASTs) are implemented with interfaces which provide a pretty clean and type safe way of doing this.

Re: Why Go Is Not Good

#263

Post by coldtea » Mon, Jun 30, 2014, 12:05 PM UTC

coldtea wrote: post #243

axaxs wrote: post #231

Earlier quoted context omitted.

I'm not saying you're wrong nor will I argue about it as in the end it really comes down to taste I feel. To me, and perhaps to others, these things make a language harder to read/use, regardless of how pervasive...

While some of it can come to taste, I think having higher abstractions (as long as they don't leak) is beneficial to reading/using a language. Like, objectively. And foreach vs for is not a leaky abstraction. Nor is pattern matching vs traditional checking and extracting the values. So their value is not geting lost on having corner cases that the equivalent "based on primitives" code wouldn't have. If anything they…

To expand on this: isn't what Go does with built-in channel and parallelism primitives similar to that?

They sure didn't exist in C. But people see the value of having this higher level abstractions.

So, why draw the line on Channels and Goroutines, and not add pattern matching in there? Just because Go already came out offering the former?

If anything, pattern matching is even more applicable to the work we do day-to-day, than channels and goroutines are.

Millions of people write programs without parallelism/concurrency every day, but nobody writes programs without pattern matching. They just do it by hand with lots of if/else and various manual extraction techniques, if their language doesn't offer it.

Re: Why Go Is Not Good

#264

Post by jvermillard » Mon, Jun 30, 2014, 12:12 PM UTC

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 :)

Re: Why Go Is Not Good

#265

Post by Argorak » Mon, Jun 30, 2014, 12:18 PM UTC

jacquesm wrote: post #209

ScottBurson wrote: post #109

Earlier quoted context omitted.

You rolled your own? Why not use the Boehm conservative collector?

In three letters: NIH. Management decision was that all IP had to be 100% owned by the company and had to be in 'C', in spite of an enormous amount of friction between C and the project as well as a bunch of work by others that could have been leveraged if we had decided to use code from other contributors. I got called in long after these decisions were made and it was very clear they weren't going to budge on those…

So, the implementation was "conservative", but on a very different level.

Sorry, could not resist.

Re: Why Go Is Not Good

#266

Post by personZ » Mon, Jun 30, 2014, 12:25 PM UTC

jeremyjh wrote: post #256

Laremere wrote: post #179

Earlier quoted context omitted.

Immutable values will complicate a type system and implementation. The Go creators are very strict about adding features to the language without enough justification, which is one of the biggest features of the language imo. There are more synchronization features than channels in Go. Channels and switches solve most problems very well. However when another synchronization method is just simply required, check out: h…

It is fine to say you want a simple language, but then please do not talk up how great it is at concurrency. It lacks basic features common to every other language with a good concurrency story.

Go is absolutely fantastic at pragmatic, practical concurrency. In most real-world cases, that does not include a strong immutability base, for instance.

Here's the thing about the "Go sucks because Haskell is the best language ever" retort: Haskell has been around for decades longer than Go. It has made essentially zero impact, and even for the case of many of those who use it as the "my big brother" comparison against Go, it isn't a viable part of their daily toolset.

It's a theoretical solution that just makes for a nice checklist comparison against Go. You know this is true. We all know this is true. And everyone goes back to Java or C# or whatever else is your daily driver.

Yet people are making Go their daily driver. Solutions are being built, en masse, in Go. People are having great degrees of success with Go.

Isn't that weird? Might it be that Go adds primitives in a way that makes them usable and intuitive, without becoming strictly theoretical?

So people can keep posting these "Haskell, which I don't actually use in any credible way, is way better" articles, but they simply miss the point. They really do.

Re: Why Go Is Not Good

#267

Post by jacquesm » Mon, Jun 30, 2014, 12:30 PM UTC

Argorak wrote: post #265

jacquesm wrote: post #209

Earlier quoted context omitted.

In three letters: NIH. Management decision was that all IP had to be 100% owned by the company and had to be in 'C', in spite of an enormous amount of friction between C and the project as well as a bunch of work by others that could have been leveraged if we had decided to use code from other contributors. I got called in long after these decisions were made and it was very clear they weren't going to budge on those…

So, the implementation was "conservative", but on a very different level. Sorry, could not resist.

No, no need to apologize. It's one of the strangest assignments I've ever had and there were a few twists to the whole story that would make for a good book.

Re: Why Go Is Not Good

#268

Post by personZ » Mon, Jun 30, 2014, 12:34 PM UTC

Daishiman wrote: post #173

personZ wrote: post #145

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 t…

But the fact that Go proponents don't actually have solutions to those problems is an issue. How do you make a custom, generic data structure without syntax overhead? I have not seen any counter proposal to this aside from "maps should be enough for everybody". How do you avoid the noise from not having operator overloading or a similar alternative? This, again, goes unadressed. What are the succint alternatives to f…

How do you make a custom, generic data structure without syntax overhead?

In real-world code, the need for generic data structures is shockingly uncommon. It really is. This requirement exaggeration comes about by people acting as language tourists, building amorphous code of uncertain purpose, where things like "I'm going to sum up a bunch of unknown objects" seems like a serious need.

For most people who find Go to be a compelling language, it excels for practical, real-world needs.

Re: Why Go Is Not Good

#269

Post by rcxdude » Mon, Jun 30, 2014, 12:48 PM UTC

jules wrote: post #236

mustpax wrote: post #50

There's something very seductive about languages like Rust or Scala or Haskell or even C++. These languages whisper in our ears "you are brilliant and here's a blank canvas where you can design the most perfect abstraction the world has ever seen." But, for systems programming, abstractions suck. They always, always have a cost. When abstractions break, you not only have to deal with a broken system but the broken ab…

This is incorrect. Generics in C++ are zero cost, since they are specialized at compile time. On the other hand if you want to write generic code in Go you have to use Object types everywhere. That means that objects have to be tagged, those tags checked with run time checks, additional pointers everywhere, bad memory layout, etc. So generic code in Go is significantly slower than in C++.

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 way to put it.

Re: Why Go Is Not Good

#270

Post by rcxdude » Mon, Jun 30, 2014, 12:51 PM UTC

cantankerous wrote: post #176

mustpax wrote: post #126

Earlier quoted context omitted.

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.

Last I checked compilation time wasn't really a thing a ton of folks worry about (myself included). Faster machines and reasonably better compilers have mostly solved this problem. I'd take zero-overhead generics over a slightly faster compiler any day of the week .

(incremental) compilation needs to be fast enough. A too-slow build cycle can really kill productivity, both in trying out new ideas for code and in debugging. The build times of the rust compiler are pretty close to the limit of what I'll tolerate, and I would really love to have compilation speeds similar to go.