Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Go is doomed to succeed

texlution.com

Post reply on HN
Print view View original

301–310 of 330 posts

Re: Why Go is doomed to succeed

#301

Post by Vendan »

pron wrote: post #141
spotman wrote: post #83

Earlier quoted context omitted.

I agree that the JVM is way, way ahead when it comes to things like agents and monitoring. For me personally, those aren't a big of enough of a win. I would rather have simple code that is fast to scale and fast to understand. Dealing with something like a thundering herd of traffic is much more difficult when your application can take upwards of an entire minute to start up, and to optimize itself to run at decent s…

I can see your point, and it's the best one I've heard so far in favor of Go over the JVM. But I feel that there are two serious fundamental problems with Go -- or rather two classes of problems -- that are likely to hinder progress as a Go project grows: 1. Go's over-fitting to Google's development style, especially the over-reliance on dependencies as source-code. 2. Go's lack of hackability that might bite you dow…

You forget to mention that golang also has an "unsafe" portion, and I've used it to "hack" around several issues before, all the way up to a (very hacky) dynamic code injection. Don't forget that golang also has an escape hatch of assembly.

Re: Why Go is doomed to succeed

#302

Post by pron »

Vendan wrote: post #301
pron wrote: post #141

Earlier quoted context omitted.

I can see your point, and it's the best one I've heard so far in favor of Go over the JVM. But I feel that there are two serious fundamental problems with Go -- or rather two classes of problems -- that are likely to hinder progress as a Go project grows: 1. Go's over-fitting to Google's development style, especially the over-reliance on dependencies as source-code. 2. Go's lack of hackability that might bite you dow…

You forget to mention that golang also has an "unsafe" portion, and I've used it to "hack" around several issues before, all the way up to a (very hacky) dynamic code injection. Don't forget that golang also has an escape hatch of assembly.

That's a terrible escape hatch, because it's brittle and very much dependent on the runtime. A new runtime version can break your code and crash your process. It's mostly intended (as is Java's unsafe) to manually manage off-heap memory -- not to hack around language semantics.

Re: Why Go is doomed to succeed

#303

Post by ngrilly »

eropple wrote: post #145
microtonal wrote: post #93

Earlier quoted context omitted.

I find it incredibly primitive, well past the point of "stupid code is impossible to misunderstand" and into "stupid code because the language demands it." Since the parent mentioned C and Java. What are you missing in Go compared to Java besides generics? What are you missing in Go compared to C besides manual memory management? To me, Go seems to have about the same amount of expressiveness as C and Java. The diffe…

> Since the parent mentioned C and Java. What are you missing in Go compared to Java besides generics? That's a clever way to attempt to constrain the conversation away from the elephant in the room. "Other than the bullet in your stomach, how are you feeling?" Not having at least Java-style "dumb" generics, in 2015, is unacceptable; the existence of `go generate` should mortify everybody involved with Go. Not having…

I agree with you that the lack of generics is a weakness of Go. Even Rob Pike agrees [1]. But some of your arguments are just plain wrong:

- `go generate` was never designed as a way to bring generics to Go.

- Most Go programmers are not "ignorant of basic functional programming". They use FP in other languages, and even in Go which has first-class functions, higher-order functions and closures. But it's true that the lack of generics severely limits the usage of FP techniques in Go.

- Go partisans don't "recommend" to stuff everything in interface{} and use "blind" type assertions everywhere. They even recommend the contrary. Give me a link to the Go official documentation that recommends that and I'll revisit my position.

To be clear, just like you, I sometimes miss generics in Go, especially when I'd like to use some FP techniques. But for me, it's just an inconvenience. It sounds like for you it's a showstopper and I understand that. But I don't think that using words like "junk", "stupid" or "dumb" helps in making your point.

I hope, and I'm confident, that the Go team will find a way to add some form or type parametricity that fits well with the overall language.

[1] http://blog.golang.org/slices

Re: Why Go is doomed to succeed

#304

Post by ngrilly »

wyager wrote: post #267
freyr wrote: post #243

Earlier quoted context omitted.

Right, Google just needs to will something to succeed, and poof , the world rallies around it. Like Dart, and Google Wave, and Google+, and Google Glass, and Google Answers, and Google Buzz. It doesn't matter if it's good or bad, because if it has Google's stamp on it, it's destined to be a wild success. Certainly, having a big corporate sponsor doesn't hurt, but it's clearly neither a necessary nor a sufficient cond…

Languages are not products. The analogy is not reasonable.

The analogy holds for Dart at least.

Re: Why Go is doomed to succeed

#305

Post by ngrilly »

Animats wrote: post #154

It's very clear what Go is for. Go is for the kind of stuff Google runs on their servers. C++ is too complex, too unsafe, and too hard to maintain, and Python is too slow. (Remember that "slow" at that scale means "we have to add another acre of servers.") Go is an OK language for server-side stuff. It's not perfect. The concurrency isn't as airtight as its proponents originally claimed. Reflection and type "interfac…

> Other than that, there are few killer problems with the language when doing server-side stuff.

Which ones?

Re: Why Go is doomed to succeed

#306

Post by spopejoy »

ngrilly wrote: post #297
spopejoy wrote: post #238

Go succeeds because Google's behind it. Go certainly doesn't succeed because of smug/boring articles like this one. The potshot at Erlang early on (also cf. slurs on Rust and Haskell in some of these comments) betrays the same old "we like it here in our cave" bias of Go boosters whenever confronted with its glaring warts. Go is a great choice for certain workloads, is reasonably fun to code in, and has great doc sup…

The article claims, and tries to "prove", that Go succeeds because it was designed from the very beginning to be a mainstream language, trying to stay simple enough to be accessible to most programmers. You're not discussing this in your comment. You claim that Go succeeds because Google's behind it. Maybe, maybe not. Then write your own article to make your point. The paragraph about Erlang was not a "potshot". The…

Yes, it won’t always keep you safe from data races as Erlang will, but Erlang keeps you safe by copying your data over and over, making it significantly slower, TANSTAAFL.

Potshot. Defend it at your peril.

Re: Why Go is doomed to succeed

#307

Post by pcwalton »

Merovius wrote: post #298
masklinn wrote: post #294

Earlier quoted context omitted.

Static dispatching, and all the possible optimisations from that rather than the "black box" of a dynamic dispatch (you can optimise either side of a dynamic call, but not optimise the whole thing because the compiler can't peek through the dispatch). Note that this can have a cost in binary size as generic functions and types have to be instantiated to their actual generic parameters (that can be optimised somewhat…

The claim was specifically "without generics there would be no point for servo to exist, because it would be too slow". This explanation only limits what kind of generics you can use for speed, but not why generics in itself (and specifically as a language feature) are a necessity to get the job done. You could get the same performance (or better) by not writing generic code or by using code generation. Don't get me…

> You could get the same performance (or better) by not writing generic code or by using code generation.

There are two ways to work around not having generics: use virtual dispatch/reflection (what you usually do in Go, with interfaces) or code duplication.

Virtual dispatch is a non-starter from a performance point of view, not only because of the virtual call but also because of the heap allocation that's usually required to use it. Reflection is even worse.

Manual code duplication makes it extremely annoying to write well-performing code and reduces productivity. Even worse, though, it reduces safety: lots of the generics in Rust use unsafe code under the hood. If you had to manually duplicate all the code, then the amount of unsafe code would explode. (Imagine having to write atomic reference counting from scratch for each and every type that's atomically reference counted!)

As for automatic code duplication via a code generator, that is what generics are. It's just that generics are a particularly good implementation of code duplication: they're integrated with the type system so that the compiler will automatically generate the appropriate code for you without having to go through the trouble of using a separate tool. Having to use a separate tool buys you nothing, as everyone has to learn the tool to write performance-sensitive code, and having to manually request generic instantiations instead of having the compiler do it is a huge nuisance, one that would push people toward not using generics at all and going to virtual dispatch—which brings us back to the performance problems.

Re: Why Go is doomed to succeed

#308

Post by ngrilly »

4ad wrote: post #28
rwmj wrote: post #18

Earlier quoted context omitted.

More like "... whether you've used any more modern languages than C" (such as ML and many other functional and research languages).

I have used SML, OCaml, Haskell, and many other languages, and I like Go, and use it for almost anything I do these days. So your statement is false. The only thing I did like more in functional languages was writing compilers (which ironically happens to be what I'm doing now in Go).

What kind of compiler are you writing? For which language and target?

Re: Why Go is doomed to succeed

#309

Post by 4ad »

ngrilly wrote: post #308
4ad wrote: post #28

Earlier quoted context omitted.

I have used SML, OCaml, Haskell, and many other languages, and I like Go, and use it for almost anything I do these days. So your statement is false. The only thing I did like more in functional languages was writing compilers (which ironically happens to be what I'm doing now in Go).

What kind of compiler are you writing? For which language and target?

For Go and sparc64, I did arm64 before.

Re: Why Go is doomed to succeed

#310

Post by Vendan »

pron wrote: post #302
Vendan wrote: post #301

Earlier quoted context omitted.

You forget to mention that golang also has an "unsafe" portion, and I've used it to "hack" around several issues before, all the way up to a (very hacky) dynamic code injection. Don't forget that golang also has an escape hatch of assembly.

That's a terrible escape hatch, because it's brittle and very much dependent on the runtime. A new runtime version can break your code and crash your process. It's mostly intended (as is Java's unsafe) to manually manage off-heap memory -- not to hack around language semantics.

I would think that all of your so called "escape hatches" are just as brittle, if not more. Once I compile a golang program, that binary will always run the same, no dependencies on a runtime that could be updated/changed out at anytime. If you aren't testing your code before deployment, that's your fault.

The only one that actually seems decent is the metaprogramming, which, in my experience, tends to lead to overcomplicated code and worse performance.

All in all, the only times I've ever needed an escape hatch is when I've been writing hacky things, or trying to be too clever. Too much "clever" is bad when programming.

Post reply on HN