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

Ian Lance Taylor's Response to “Go Is Google's Language”

groups.google.com

Post reply on HN
Print view View original

331–340 of 346 posts

Re: Ian Lance Taylor's Response to “Go Is Google's Language”

#331

Post by pizza234 »

tsimionescu wrote: post #228
pizza234 wrote: post #20

Earlier quoted context omitted.

I think it's also worth highlighting this: no successful language-indeed, no successful free software project of any sort is a democracy [...] Successful languages pay attention to what people want, but to change the language according to what most people want is, I believe, a recipe for chaos and incoherence. I believe that every successful language must have a coherent vision that is shared by a relatively small gr…

Isn't C++ committee-driven, which could be considered a type of democratic process? Or would that not be considered an open-source project? On that note, I also seem to remember that LLVM/Clang are pretty democratic, but I haven't dug deeply and may be completely wrong.

Well, interestingly, "design by comittee" is a pejorative, so it raises the question whether C++ is, in a (specific, not universal) sense, a success or not.

Re: Ian Lance Taylor's Response to “Go Is Google's Language”

#332

Post by apta »

grumpydba wrote: post #314
apta wrote: post #294

Earlier quoted context omitted.

Java will use however much memory is assigned to it, since it defaults to throughput performance (though now with G1 and Shenandoah that can also be tuned)[1]. Compilation times are not that different, especially when using incremental compilation. I worked on large projects in both languages, and for any non-trivial code base, the difference isn't that far off. I'd argue that readability is better in Java due to thi…

You mention a lot of workarounds and knobs though. And the excessive use of layers of abstractions in the Java world is scary.

Large projects are complex. The JVM is designed to be a platform for developing general purpose software, which is why it provides options for tuning and whatnot. golang only comes with a low latency GC, which basically means you cannot use golang if you're looking for high throughput.

Re: Ian Lance Taylor's Response to “Go Is Google's Language”

#333

Post by tyrankh »

geodel wrote: post #251
oaeide wrote: post #212

"They don't necessarily have the freedom to call that forked language "Go" (I'm not sure), but I think that limitation is OK; it serves nobody to call different projects by the same name. " Oh, the irony

Yeah big irony. Millions of users still remain confused between original 'Go!' and Google's hijacked version 'Go' language.

Not sure if sarcasm...?

Re: Ian Lance Taylor's Response to “Go Is Google's Language”

#334

Post by ernst_klim »

KirinDave wrote: post #17

Googler here, but these are my own opinions formed from less than a year at the company. My observation of Google's culture is that it can be very difficult to see the ways in which they dominate projects they participate in because it's very difficult to keep perspective on how even small investments by Google tend to overwhelm the volume of other contributers project. Google has a lot of great, productive engineers…

Yeap, that's google.

Go is not the only such project. For how long did linux hw decoding patch for chromium wait for being merge?

And it's still not merged because of the "maintenance burden" (needless to say big linux distros maintain this patch and apply it to their chromium packages just fine).

Android hw support is merged, no problems. Oh, and Chromium OS has hw decoding as well, while having 0.0001% market share. Because it's a google's product.

For google open source is nothing but a way to obtain free labor and make more money. These are their products, meant to make money for them. Others are mere free contributors.

Re: Ian Lance Taylor's Response to “Go Is Google's Language”

#335

Post by grumpydba »

apta wrote: post #332
grumpydba wrote: post #314

Earlier quoted context omitted.

You mention a lot of workarounds and knobs though. And the excessive use of layers of abstractions in the Java world is scary.

Large projects are complex. The JVM is designed to be a platform for developing general purpose software, which is why it provides options for tuning and whatnot. golang only comes with a low latency GC, which basically means you cannot use golang if you're looking for high throughput.

> golang only comes with a low latency GC, which basically means you cannot use golang if you're looking for high throughput.

I you're looking for high throughput you just need to allocate less. Or use unsafe. And it's totally doable.

Re: Ian Lance Taylor's Response to “Go Is Google's Language”

#336

Post by apta »

grumpydba wrote: post #335
apta wrote: post #332

Earlier quoted context omitted.

Large projects are complex. The JVM is designed to be a platform for developing general purpose software, which is why it provides options for tuning and whatnot. golang only comes with a low latency GC, which basically means you cannot use golang if you're looking for high throughput.

> golang only comes with a low latency GC, which basically means you cannot use golang if you're looking for high throughput. I you're looking for high throughput you just need to allocate less. Or use unsafe. And it's totally doable.

So you "only" have to make significant, error prone (by using unsafe) code changes as opposed to tuning a couple of parameters for the GC to account for a different workload? Again, this shows the superiority of the JVM here.

And the same approaches can be done in Java (e.g. self-managed off heap allocations), even more-so when they introduce value types.

Re: Ian Lance Taylor's Response to “Go Is Google's Language”

#338

Post by einpoklum »

pizza234 wrote: post #331
tsimionescu wrote: post #228

Earlier quoted context omitted.

Isn't C++ committee-driven, which could be considered a type of democratic process? Or would that not be considered an open-source project? On that note, I also seem to remember that LLVM/Clang are pretty democratic, but I haven't dug deeply and may be completely wrong.

Well, interestingly, "design by comittee" is a pejorative, so it raises the question whether C++ is, in a (specific, not universal) sense, a success or not.

C++'s design by committee is well-suited to achieve one of the key goals in the (ongoing) design on the language, which is maintaining extreme backwards compatibility and extensive mulling of potential changes by numerous independent interested parties so that changes that do make it in are nearly-consensual.

You could argue whether those are the goals a language should pursue, but it's pretty obvious a central designer with free reign would not have achieved those goals.

Re: Ian Lance Taylor's Response to “Go Is Google's Language”

#339

Post by einpoklum »

didibus wrote: post #193

Honestly, I'm very confused by all this. Don't like it, fork it no? Isn't that the whole point of open source? Any project needs to have a certain set of people in charge of making actual decisions and working on those. You'll never have every single user be a part of that decision making. It wouldn't scale. What language is not driven by a handful of decision maker? Even what could be argued to be committee driven l…

No. Forking a language is very difficult from forking an application (which is itself a Herculean task if the app is big). And few end-users of a piece of software will switch to a fork with much less backing because of soft-power influence or governance model.

Re: Ian Lance Taylor's Response to “Go Is Google's Language”

#340

Post by grumpydba »

apta wrote: post #336
grumpydba wrote: post #335

Earlier quoted context omitted.

> golang only comes with a low latency GC, which basically means you cannot use golang if you're looking for high throughput. I you're looking for high throughput you just need to allocate less. Or use unsafe. And it's totally doable.

So you "only" have to make significant, error prone (by using unsafe) code changes as opposed to tuning a couple of parameters for the GC to account for a different workload? Again, this shows the superiority of the JVM here. And the same approaches can be done in Java (e.g. self-managed off heap allocations), even more-so when they introduce value types.

Object pools are really easy. Unsafe is only for extreme cases. Some cache libraries use it. You don't have to code it yourself. Yes this is better than relying on the end user/admin to tune things. It is more predictable.
Post reply on HN