Why Go is doomed to succeed • Hacker News Board

Re: Why Go is doomed to succeed

#321

Post by com2kid » Mon, Jun 15, 2015, 4:39 AM UTC

coldtea wrote: post #29

pcwalton wrote: post #19

Earlier quoted context omitted.

How is Rust incomplete and too complex (especially "incomplete")? Compiler-enforced-correct manual memory management may not be the right choice for every project, of course, but I think "too complex" is too strong of a way to say that. That implies there was a simpler way Rust could have achieved the same goals, and I've never seen anyone suggest one that works.

Well, it's a very common complaint (and I found it to be true when I tried my hand at Rust) that the lifetimes and general scope management can make your life hard -- and certainly harder than conventional GC languages. Rust, as a core language, has a lot more concepts to grok compared to Go or even Java. As for incomplete, I mostly refered to the tooling and the available library ecosystem. Even Go lacks there, and…

> the lifetimes and general scope management can make your life hard -- and certainly harder than conventional GC languages.

Except you have to solve those very same problems on your own with every other type of resource that is not called "memory" in other languages.

Ownership is a huge problem, having built in primitives to handle it is a benefit. Having or not having GC is almost (but not quite!) a separate discussion.

Re: Why Go is doomed to succeed

#322

Post by pron » Mon, Jun 15, 2015, 4:59 AM UTC

Vendan wrote: post #310

pron wrote: post #302

Earlier quoted context omitted.

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

> I would think that all of your so called "escape hatches" are just as brittle

Why are they brittle? They're not brittle at all, they just have looser semantics than the core language. They have their own semantics, which the runtime guarantees to uphold.

> that binary will always run the same... If you aren't testing your code before deployment, that's your fault.

Why work in such a primitive way? We're very familiar with what happens when source-code is overly dependent on a specific compiler version. Besides, dropping to C/assembly in a language with such a high-level runtime (not only a GC but its own global scheduler) is not an escape hatch; it's just using power tools to break through a hatch-free thick wall, which might work if you're careful not to break the foundations by mistake. You could do the same in all languages that do provide an escape hatch, too (if you'd rather break through the wall instead of using the hatch).

> Too much "clever" is bad when programming.

Absolutely, but sometimes just the right amount of clever can let you do truly powerful things that would otherwise be beyond the reach of the language. It's there just for those moments when you're stumped[1].

Experience (and I've been doing this for twenty years) shows that this point where some cleverness is necessary, always arrives at some point in the project's lifetime, and that cleverness often saves you a whole ton of work. Remember, the average codebase lifetime is about 10 years.

[1]: Plus some truly powerful stuff, like the ability to inject tracing code into a running application and then take it out.

Re: Why Go is doomed to succeed

#323

Post by iamcreasy » Mon, Jun 15, 2015, 6:36 AM UTC

Merovius wrote: post #288

lucidguppy2000 wrote: post #188

Earlier quoted context omitted.

How does go prevent complexity?

Mostly by making abstractions harder. By making it pointless to think about "what is the best type-hierarchy for this software" or "what is the most general way this problem can be formulated and solved", it forces you to focus and solve the problem at hand, which leads to more straightforward and easier to understand code. Most people I've seen, that are frustrated with go, are people who want to have an impact on t…

Is there any detailed article on this topic that you know of?

Re: Why Go is doomed to succeed

#324

Post by pjmlp » Mon, Jun 15, 2015, 12:49 PM UTC

reagency wrote: post #182

Elrac wrote: post #142

Earlier quoted context omitted.

Only for small values of "all." The magic of concatenation and auto-conversion of strings that's baked into the Java compiler and, to a lesser extent, the Go compiler, is missing in C++ - not vital but convenient. Similarly, hashmaps, while built directly into the language in Go, are a library class in C++. Finally, garbage collection will likely never be part of C++.

The main problem of C++ is that it has far too large values of "all".

Which is still too less when compared with Java, CPAN, Gems, .NET....

Re: Why Go is doomed to succeed

#325

Post by spopejoy » Mon, Jun 15, 2015, 9:03 PM UTC

muraiki wrote: post #299

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…

You characterize certain language features as objectively better. Indeed, those who do not use the particular approach you advocate (FP) or the feature you desire are "haters who refuse to understand". Is this really a charitable way to look at other programmers? As people who, because they do not use your preferred language or languages, are apparently full of hatred and -- not a lack of understanding, but a _refusa…

I characterize FP as not worse, which of course implies that it must be better in some scenarios to even compete.

I characterize Go as having glaring warts. ":=" will bomb on reassignment UNLESS you destructure alongside a new variable. Wart. Try to close over a variable in a loop; wince in pain as you make a throwaway anonymous function to do so. Wart. Don't get me started on "interface {}".

Nonetheless, I think Go is a great tool for the right job. I don't think it's "better for open source" (WTF???). I wouldn't want to write a massively-concurrent (not parallel: concurrent) system in such a loose-goosey, non-polymorphic language. But that's just me, knock yourself out.

Re: Why Go is doomed to succeed

#326

Post by Merovius » Tue, Jun 16, 2015, 8:27 PM UTC

iamcreasy wrote: post #323

Merovius wrote: post #288

Earlier quoted context omitted.

Mostly by making abstractions harder. By making it pointless to think about "what is the best type-hierarchy for this software" or "what is the most general way this problem can be formulated and solved", it forces you to focus and solve the problem at hand, which leads to more straightforward and easier to understand code. Most people I've seen, that are frustrated with go, are people who want to have an impact on t…

Is there any detailed article on this topic that you know of?

The canonical answer is [0], though unfortunately, that's not very good to illustrate this specific point :) I came to this conclusion from reading the golang-{nuts,dev} mailing lists and whan pops up in the community. The usual answer to a proposal of a new language feature (most famously some form of generics) is "what real-world problem is this trying to solve and maybe we can solve it in other ways". And "real-world" always means "real-world", i.e. code that is currently running in some real project out there. And the answer of the people propositioning is almost always something in the neighborhood of "I want to write a foo-library, that makes bar simpler".

I remember reading an article a while back by someone explaining exactly that very well, but I can't seem to find it…

[0] https://talks.golang.org/2012/splash.article

Re: Why Go is doomed to succeed

#327

Post by Merovius » Tue, Jun 16, 2015, 8:55 PM UTC

pcwalton wrote: post #307

Merovius wrote: post #298

Earlier quoted context omitted.

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

Thanks for the detailed answer :) First let me say: I agree, with pretty much everything you say.

The communication issue is, that you seem to equate "generics" with how generics are implemented in rust. I don't see it that way. To me, generics are a language feature, that has multiple possible implementations, one is specialized code generation, as in rust. I think Russ Cox summarises this better than me [0].

And from that point of view, I was surprised to hear, that people thought they would improve performance. Because in my mind, they probably improve terseness and maybe improve productivity, but not performance, if you can write a generic algorithm as a template and do a search-and-replace for pretty much the same compiled result. I think, these difference in viewpoints was, what made this discussion so more lengthy than need be.

And it's important to note (I think) that no one in the world ever doubted the usefullness, of having generics as a language feature (instead of a standalone tool). When gophers say, that rust is overloaden with features, they don't mean useless features, they just mean, that there are a lot of features. Every feature in C++ is usefull. Every feature in python is usefull. But there are just so many of them, which creates a lot of cognitive overhead and always creates the impulse to contemplate "what's the most elegant way to express this", instead of just expressing it and going on to more important things (Mind you, I don't say this is a philosophy that needs to be shared by everyone, but it's the one people have, when they complain about the number of language features in e.g. rust). I think, Gustavo Niemeyer puts this very well [1].

Anyway, I hope you now understand my question better and also understand better, what the philosophy behind go's minimalism is and what people mean, when they complain about too many features :)

[0] http://research.swtch.com/generic [1] http://blog.labix.org/2012/06/26/less-is-more-and-is-not-alw...

Re: Why Go is doomed to succeed

#328

Post by icedchai » Tue, Jun 16, 2015, 8:59 PM UTC

rifung wrote: post #220

icedchai wrote: post #208

Earlier quoted context omitted.

In practice, it doesn't make much difference. You install the JVM once and rarely upgrade it. You build and distribute your Java apps as fat jars (meaning, all dependencies bundled.)

But what happens when some of the apps require different versions of the JVM?

You know you can have multiple VMs installed, with different JAVA_HOMEs, right?

This is a solved problem.

Re: Why Go is doomed to succeed

#329

Post by kibwen » Tue, Jun 16, 2015, 9:46 PM UTC

Merovius wrote: post #327

pcwalton wrote: post #307

Earlier quoted context omitted.

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

Thanks for the detailed answer :) First let me say: I agree, with pretty much everything you say. The communication issue is, that you seem to equate "generics" with how generics are implemented in rust. I don't see it that way. To me, generics are a language feature, that has multiple possible implementations, one is specialized code generation, as in rust. I think Russ Cox summarises this better than me [0]. And fr…

  > you seem to equate "generics" with how generics are 
  > implemented in rust

Given that your question was specific to Servo, and given that Rust is largely motivated by Servo, it should come as no surprise that pcwalton's response was specific to the implementation of generics that makes the most sense for use cases like Servo's.

  > I was surprised to hear, that people thought they
  > would improve performance.

Making the compiler aware of generics makes it easier to collapse duplicate implementations, which can have a cascading effect on reducing binary size and thereby reducing icache pressure.

Re: Why Go is doomed to succeed

#330

Post by wirrbel » Thu, Jun 18, 2015, 8:47 PM UTC

masklinn wrote: post #292

wirrbel wrote: post #290

Earlier quoted context omitted.

37signals and ruby? They were involved with Rails, but did they sponsor Ruby?

No, but IIRC Ruby had very little relevance/existence — at least outside Japan — before Rails.

for the point of the parent comment, ruby was chosen for its merits, not designed by 37 signals.