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

261–270 of 330 posts

Re: Why Go is doomed to succeed

#261

Post by pjmlp »

mkramlich wrote: post #242
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…

bingo Google: Go Microsoft: C# Sun/Oracle: Java almost all others: more on their own merits, from developers eyes (Python, Perl, C++, Ruby, Rust, D, Scala, LUA, JS, etc.) a language should have innate merits, of course, but never discount the advantages of having a single corporate entity with lots of cash and focus and a built-in install base of eyes

Let me fix that list

CNRI: Python

AT&T: C++

Unisys: Perl

EPFL: Scala

37signals: Ruby

Mozilla: Rust

Re: Why Go is doomed to succeed

#262

Post by pjmlp »

vezzy-fnord wrote: post #10

Go is doomed to succeed because it extends the mental model of C with a concurrency model that finds a decent compromise between power and ease of use, makes the typing less prone to subversion, adds memory safety via GC, uses a structural subtyping system through interfaces that brings many OO-like benefits while still keeping to the C struct way of thinking, first-class functions, various syntactic rough edges clea…

I don't like how Go's design turnoud to be, but I surely appreciate that it means less C code and more memory safe code.

Eventually C will be squeezed into an Assembly like niche, used only for shaving out ms out of an application, kernel stuff or those little code tricks not exposed on the safe layer.

Re: Why Go is doomed to succeed

#263

Post by pjmlp »

vezzy-fnord wrote: post #41
aaggarwal wrote: post #14

Earlier quoted context omitted.

I have never used Go before. From the sound of it, it looks like Go hits a sweet spot between C and Java? and of course the Google support is a major factor for a possible success.

Not quite. To understand Go, you need to understand the history of the Bell Labs gurus somewhere around the late 9th and 10th editions of Research Unix, when the vestiges of what would become Plan 9 and Inferno began to take shape (the sam editor that would influence acme, the rc shell, mk and the predecessor to 9P [streams] would all originate here - see "Interprocess Communication in the Ninth Edition Unix System"…

You missed out the Oberon-2 influence on method declaration syntax. :)

Re: Why Go is doomed to succeed

#264

Post by pjmlp »

pcwalton wrote: post #157
pron wrote: post #152

Earlier quoted context omitted.

Why do exceptions interact badly with RAII?

You have to think carefully about how to clean up your object if something throws during its constructor, and throwing an exception in a destructor can lead to your program aborting if that destructor was called as a result of another exception being thrown. Note that I don't think banning exceptions is really the answer; in particular, the destructor issue is just a specific case of "handling errors during finalizat…

Although I would say that is a C++ problem, many other languages with exception support do enjoy more sane models than C++.

Re: Why Go is doomed to succeed

#265

Post by stox »

Go is simply the follow on to Limbo. It is the product of many years of experience supporting the construction of large systems. Most of its roots are from Bell Labs.

Re: Why Go is doomed to succeed

#266

Post by pjmlp »

xamuel wrote: post #166
Elrac wrote: post #25

Earlier quoted context omitted.

"Between C and Java" hits it very well, I'd say. When I jumped ship from C to Java, Java's object orientation wasn't exciting to me, and its exception handling is an acquired taste. But dynamically growable, garbage collected buffers are something I'd missed for a long time. And the simple ability to concatenate strings without first reserving space for the result. Oh, and hash maps! Remarkably versatile data structu…

>And the simple ability to concatenate strings without first reserving space for the result Not exactly the same thing, but routine string manipulation in C gets considerably easier once you discover a highly underrated function called asprintf (basically combines sprintf and malloc, calculating the buffer size for you).

Not in ANSI C nor POSIX.

Re: Why Go is doomed to succeed

#267

Post by wyager »

freyr wrote: post #243
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…

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.

Re: Why Go is doomed to succeed

#268

Post by pjmlp »

Elrac wrote: post #142
okasaki wrote: post #129

Earlier quoted context omitted.

Well, C++ has all of that.

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

> Finally, garbage collection will likely never be part of C++.

C++11 has a GC API defined.

Reference counting is part of any GC book in CS speak.

Re: Why Go is doomed to succeed

#269

Post by wyager »

Elrac wrote: post #142
okasaki wrote: post #129

Earlier quoted context omitted.

Well, C++ has all of that.

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

There are a large number of people who would strongly disagree with the claim that implicit casting is a good thing.

Re: Why Go is doomed to succeed

#270

Post by kibwen »

MetaCosm wrote: post #259
pcwalton wrote: post #254

Earlier quoted context omitted.

> Rust-the-community (and you as a member of it) see no problem with it... which for me, IS the problem. The timing, the fact that it played into all the existing narratives about why you never trust Rust, it made it a brutal bit of political weaponry in the hands of those who are pushing against Rust in organizations... and a bit of a kick in the junk to those of us who supported it. Tell me what you wanted Rust to…

> Tell me what you wanted Rust to do instead... Well -- if we are going into what I would have preferred. I would have preferred a rest period after release. No ongoing changes across 3 trains on a 6 week cycle. Give the community time to accept, adapt, bitch, moan, whine, create workarounds, and then better workarounds. Let enterprises have time to buy in, test, accept or reject and give feedback. Deal with critical…

You appear to have an expectation that the 1.0 release itself is an LTS release. I'm not sure where that expectation came from, but it is not correct. 1.0 is just the foundation for the language's stable evolution, and I don't expect any Rust code to linger on 1.0 in lieu of upgrading to 1.1.

The arrival of the 1.0 release also doesn't imply that the language is "done" or ready to use for anyone's particular use case (e.g. Servo is still on nightly, and will be for the foreseeable future). There are crucially important things that are currently being stabilized, and delaying those for an additional three release cycles would just be an arbitrary obstacle for those seeking to shift their code from nightly to stable.

We also don't need three release cycles to get feedback because we've been collecting feedback all throughout the 1.0-alpha and 1.0-beta cycles. Now would be the worst time to institute a freeze on API additions because of all the APIs that people are clamoring for but that didn't make it to stable for 1.0 (https://github.com/rust-lang/rust/issues/24028).

We're also working closely with several dozen companies using Rust to determine what development to prioritize (if you would like to add your company to this list, then please see the email address in my HN profile). As a result of this collaboration I expect to submit an RFC next week to propose that Rust 1.5 become the first LTS release, with subsequent LTS releases happening every at every fifth release. Do note that this idea is very preliminary (don't take it as gospel), but if accepted it would mean that we have until October 30 to stabilize any features that we want corporate users to be able to take advantage until the next LTS.

(As for that proposed "breaking change" that 1) wouldn't break any code in the wild, 2) would be trivially fixable with a lifetime annotation, and 3) could be opted out of with a single attribute, every company that I have asked about it has said that we should go through with it.)

Post reply on HN