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

271–280 of 367 posts

Re: Why Go Is Not Good

#271

Post by rcxdude »

comex wrote: post #254
pcwalton wrote: post #142

Earlier quoted context omitted.

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

I don't know if it has to do with generics , but you can't blame it on LLVM. /usr/src/rust/src/libsyntax % time /usr/src/rust/x/x86_64-apple-darwin/stage2/bin/rustc lib.rs -o /tmp/x.dylib --crate-type dylib -C prefer-dynamic -Z time-passes [most output removed...] time: 6.186 s type checking time: 5.084 s translation time: 7.221 s LLVM passes /usr/src/rust/x/x86_64-apple-darwin/stage2/bin/rustc lib.rs -o /tmp/x.dylib…

I don't think the rust compiler has been particularly extensively optimised at this point. There's no blindingly obvious hotspots (last I profiled the biggest single time sink was hashmap lookups in type checking), but there's not been any real effort in reducing compile time yet, as far as I know.

Re: Why Go Is Not Good

#272

Post by LamaOfRuin »

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++.

Doesn't this assume that compiler complexity/work is not a cost?

Re: Why Go Is Not Good

#273

Post by p0nce »

mustpax wrote: post #114
pcwalton wrote: post #56

Earlier quoted context omitted.

> When abstractions break, you not only have to deal with a broken system but the broken abstraction itself too. (Anyone who has ever seen a gcc compiler error for C++ knows how this feels.) Using C++ template error messages to attack generics in Rust and Haskell is pretty weak, because typeclasses were explicitly designed to avoid the problems of "ad-hoc" templates in languages like C++. Error messages are in fact w…

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.

Where is that great software that breaks new ground?

Re: Why Go Is Not Good

#274

Post by exabrial »

"A Good Solution: Operators are Functions"

NO. No. No.

Allowing users to change the language specification and side effects on a per-file, per-project, per-anything basis is a terrible terrible terrible idea.

"This is all covered in Knuth, and we don't have time to go over it again."

Re: Why Go Is Not Good

#275

Post by LamaOfRuin »

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 .

Fast build time is explicitly something Go was built for, to fix 40 minute compile times.

Re: Why Go Is Not Good

#276

Post by jerf »

illumen wrote: post #251
oscargrouch wrote: post #201

Earlier quoted context omitted.

I have the same line of thinking as you do.. is the difference in use something you like and can work, and choose something you can use in a bigger group.. HN crowd are top smart.. things like Rust and Haskell are a breeze for people here.. but this is not the reality of the tech field.. the majority of people i know in tech, cant handle more powerful languages.. its too much for them In the end is just that.. know h…

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…

"I've seen newbie programmers learn Haskell as a first language in under a term."

Even as a fan of Haskell, I have to say that if you spent one term on Haskell and one term on Go, the latter students are going to be far closer to a place where you could drop them into a real job and get real work out of them. (That said, as I sit here and look back on what "one term" really constitutes, it's not much, regardless of language.)

Re: Why Go Is Not Good

#277

Post by lmm »

mustpax wrote: post #114
pcwalton wrote: post #56

Earlier quoted context omitted.

> When abstractions break, you not only have to deal with a broken system but the broken abstraction itself too. (Anyone who has ever seen a gcc compiler error for C++ knows how this feels.) Using C++ template error messages to attack generics in Rust and Haskell is pretty weak, because typeclasses were explicitly designed to avoid the problems of "ad-hoc" templates in languages like C++. Error messages are in fact w…

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.

Is there demonstrably great software written in Go yet? I've seen some people using it but I've yet to see a "killer app" (the way e.g. MLDonkey convinced me I should take OCaml seriously, or Pandoc convinced me I should take Haskell seriously).

Re: Why Go Is Not Good

#278

Post by orbifold »

zimbatm wrote: post #139
Mr_P wrote: post #69

Earlier quoted context omitted.

These two statements made me cringe: > But, for systems programming, abstractions suck. They always, always have a cost. > Generics? Here's another if statement, put it inside your for loop. If you care about speed (and many systems programmers do), this is exactly the opposite of what you want to do. Unlike your proposal of putting potentially-costly if-statements inside of for loops, generics/templates in c++ provi…

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.

Which in c++ you can easily do, as you probably know. All you need to do is have an if statement that compares the type parameter of your template to int32 and int64. The good thing is that this kind of optimizations is transparent to the user if the code works. Even Haskell has something similar, with the SPECIALIZE pragma. Although in this case you have to trust the compiler to come up with the optimizations.

Re: Why Go Is Not Good

#279

Post by steveklabnik »

axaxs wrote: post #219
pcwalton wrote: post #118

Earlier quoted context omitted.

> Rust, C++, Haskell, Scala will never be good at that because they're too damn complicated (although each of them make the nasty parts a little less painful!) Why is Rust too complicated to allow you to do low-level hacking?

I don't think it's bad, but to me(and only to me), disappointing. I'm a long time mozilla fan...heck a Netscape fan really. Go was a pleasure to learn, there were no 'gotchas' initially...just a small, easy to reason about language. Rust...with its arrows, angle brackets, pattern matching, etc. seemed just so complex to fit in my brain. I'd love to be proven wrong and try again, but the docs aren't the best. And I kn…

> the docs aren't the best.

This week is week two of my being contracted by Mozilla to write docs full time. First up, a new tutorial. You can see my work from last week http://doc.rust-lang.org/guide.html , and my first task after I finish breakfast is to clean up https://github.com/rust-lang/rust/pull/15229 , which got some review over the weekend.

So, you're right (at least about the docs) but I'm on it.

Re: Why Go Is Not Good

#280

Post by aktau »

logicchains wrote: post #247
aktau wrote: post #237

Earlier quoted context omitted.

And some methods for manipulating it (slicing it), and reference counting. And macro's for automatically ref'ing/unref'ing.

Reference counting? I didn't know reference counting was used with slices, I thought they just used the GC.

Yes, but since C is not a GC-language, I thought I'd add that to reach more equivalence :).
Post reply on HN