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

311–320 of 330 posts

Re: Why Go is doomed to succeed

#311

Post by ngrilly »

bostik wrote: post #255
davidw wrote: post #172

Earlier quoted context omitted.

> Why don't people use Erlang/Elixir Because Erlang is different . It's not just the syntax, even though that throws many people uncomfortable with much that's not a direct descendant of C syntax; it's the whole programming model which requires a real shift in perspective that simply isn't easy. It's worth it once you start to "get it", but that can take a bit. I do think Elixir gives the Erlang VM a better shot at t…

> Because Erlang is different. I'd say that fails to capture the full scope of the statement. From where I stand, Erlang is not just a language - it's an extremely robust, highly opinionated event loop with its very own DSL.

> an extremely robust, highly opinionated event loop with its very own DSL

It's very reductive. Erlang is a distributed platform with a functional programming language, lightweight processes communicating through distributed asynchronous shared-nothing message passing, preemptive scheduler, etc.

Re: Why Go is doomed to succeed

#312

Post by ngrilly »

spopejoy wrote: post #306
ngrilly wrote: post #297

Earlier quoted context omitted.

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.

Erlang processes are shared-nothing and, by design, data must be copied when processes communicate:

> All data in messages between Erlang processes is copied, with the exception of refc binaries on the same Erlang node. [1]

But I have to agree with you that the paragraph about Erlang in the article overstates the issue. In most cases, messages should be relatively light and then the copy is not issue. It's an issue only when you need to transfer or share a complex data structure.

If I'm not mistaken, in the current implementation of BEAM, each lightweight process has its own heap and this is the reason why data must be copied. But it could be possible to allocate memory from an arena shared by all processes, and because Erlang data structures are immutable, messages exchanged by processes could contain only references. The cost would be a more complex garbage collector, with the related latency issues.

[1] http://www.erlang.org/doc/efficiency_guide/processes.html

Re: Why Go is doomed to succeed

#313

Post by kibwen »

MetaCosm wrote: post #271
kibwen wrote: post #270

Earlier quoted context omitted.

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…

> if you would like to add your company to this list... Sadly, in the near term, the Rust boat has sailed. LTS releases would give a real good reason to reconsider if they ever come about. What support durations are you considering for LTS, and where can I read more?

I'm not sure of all the parameters yet, I'm coordinating with our corporate partners to see what they would find most useful. I'll be posting the RFC to the users forum and reddit once it's done. You can also give me your email address and I'll notify you when it's ready. :)

Re: Why Go is doomed to succeed

#316

Post by rakoo »

reagency wrote: post #179
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…

Does Google use Go in any high-load services?

Vitess (https://github.com/youtube/vitess) scales mysql for youtube level of usage.

Re: Why Go is doomed to succeed

#317

Post by rakoo »

wz1000 wrote: post #296
lohengramm wrote: post #51

Earlier quoted context omitted.

Very well put. I would also add nice UTF-8 support, easy concurrency and overall simplicity.

All those points along with the parents apply to Haskell too. Yet Haskell does not enjoy the same hype/success.

I think you'll find some people who wouldn't say that Haskell is overall simple, or at least as simple as Go can be.

Re: Why Go is doomed to succeed

#318

Post by eropple »

ngrilly wrote: post #303
eropple wrote: post #145

Earlier quoted context omitted.

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

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

Unix was designed to port Spacewar. What's that got to do with anything?

> Most Go programmers are not "ignorant of basic functional programming".

That doesn't match my experience. The overwhelming majority of Go people I know, and the loudest advocates to whom I am exposed, seem to regard functional programming as a nothing. Your experience may differ.

> Go partisans don't "recommend" to stuff everything in interface{} and use "blind" type assertions everywhere.

Again, that doesn't match my experience; this was literally recommended to me by a senior-level Google engineer. To his credit, he suggested instead using `go generate` as an alternative. (Because that's better. =/ )

> I don't think that using words like "junk", "stupid" or "dumb" helps in making your point.

Completely fair criticism. But let me put it this way: I view Go, and the terminally blinkered Rob Pike, and his disciples, to be so obviously and monstrously disastrous to what I do for a living that those were the remains after a pretty heavy dose of editing and self-censorship.

I could tell you how I actually feel if you'd like. =)

Re: Why Go is doomed to succeed

#319

Post by codygman »

rakoo wrote: post #317
wz1000 wrote: post #296

Earlier quoted context omitted.

All those points along with the parents apply to Haskell too. Yet Haskell does not enjoy the same hype/success.

I think you'll find some people who wouldn't say that Haskell is overall simple, or at least as simple as Go can be.

> I think you'll find some people who wouldn't say that Haskell is overall simple, or at least as simple as Go can be.

You'll also find some people who say the opposite. We need to qualify what kind of simple we are talking about? Are we talking purely about language?

Are we talking about standard libraries? Ease of use of API's? Ease of use in analyzing performance?

If we just compare Go's syntax to Haskell's syntax you'll find they both have few reserved words.

Re: Why Go is doomed to succeed

#320

Post by thisrod »

fao_ wrote: post #116
vezzy-fnord wrote: post #41

Earlier quoted context omitted.

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

CSP == Continuation Style Passing or?

or this:

http://usingcsp.com/

Post reply on HN