Earlier quoted context omitted.
CSP == Continuation Style Passing or?
Communicating Sequential Processes.
Ah, thank you.
Why Go is doomed to succeed
291–300 of 330 posts
Re: Why Go is doomed to succeed
#292Earlier quoted context omitted.
Let me fix that list CNRI: Python AT&T: C++ Unisys: Perl EPFL: Scala 37signals: Ruby Mozilla: Rust
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.
Re: Why Go is doomed to succeed
#293Earlier quoted context omitted.
This is helpful. Thanks! I have one more question, how does Go ensure easy concurrency?
It provides built-in lightweight thread abstraction ("goroutines", and "channels" for communication between these). Beware though, Go uses shared-memory concurrency (as opposed to, say, Erlang) so if you pass a pointer to a mutable structure through a channel the structure won't be copied or moved, both sides will be able to alter it. It does provide a data race detector but it's just that, you have to hit the corrup…
Thanks for informing, that is an important point to keep in mind, ignoring this would lead to potential bugs and very difficult debugging as you said.
Re: Why Go is doomed to succeed
#294Earlier quoted context omitted.
That last paragraph is ridiculous. Name one feature in Rust that you think is too much complexity and I'll tell you where I need it to get my job done in Servo. Without generics and traits, for example, there would literally be no reason for Servo to exist, because it would be too slow. Performance is not optional . Safety is not optional . They are my job . If I opposed language features that are needed for competit…
I find it counterintuitive, that generics and traits improve speed. I would enjoy a deeper explanation of that :)
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 when the parameters themselves are dynamic, IIRC while .Net uses reified generics Microsoft's implementation uses a single instantiation for all reference types)
Re: Why Go is doomed to succeed
#295Earlier quoted context omitted.
That last paragraph is ridiculous. Name one feature in Rust that you think is too much complexity and I'll tell you where I need it to get my job done in Servo. Without generics and traits, for example, there would literally be no reason for Servo to exist, because it would be too slow. Performance is not optional . Safety is not optional . They are my job . If I opposed language features that are needed for competit…
I find it counterintuitive, that generics and traits improve speed. I would enjoy a deeper explanation of that :)
It's all about specializing code to a certain type at compile time and therefore removing any kind dynamic dispatch during runtime.
Re: Why Go is doomed to succeed
#296Compiled to native binary, garbage collected, no JVM and not object oriented is why I like it.
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.
Re: Why Go is doomed to succeed
#297Go 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 author is just pointing out a tradeoff, which is real. There is no question that Erlang is a great language and system.
Re: Why Go is doomed to succeed
#298Earlier quoted context omitted.
I find it counterintuitive, that generics and traits improve speed. I would enjoy a deeper explanation of that :)
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 wrong. No one doubts the usefullness of generics (not even the core authors of go. Not even Rob Pike as the biggest advocate against generics in go). Just the necessity. And in this specific case, claimed performance improvements.
Re: Why Go is doomed to succeed
#299Go 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 _refusal_ to understand?
How about we consider the author of the blog post, the Go community, and the Go language's designers in a more charitable light. Perhaps the points made in the article are actually valid: that language features involve tradeoffs, some of which are measured not just in terms of performance, and that languages are designed to achieve certain goals that might not align with yours.
Yes, I imagine that "Go certainly doesn't succeed because of smug/boring articles like this one" although I'd remove "smug/boring." Before I used Go I hated it "from first principles", because I had used Scala and Clojure and Haskell and Reactive Extensions and all sorts of FP goodness. But to make a long story short, once I started using Go I really enjoyed it and now I willingly choose to use it to solve problems. It was the use of Go that convinced me that perhaps these absolutes from FP I believed in weren't quite absolutes after all. But this doesn't mean that I consider Go to be some kind of perfect holy grail of programming, either.
Does that make me a hater who refuses to understand? Does it make me some kind of idiot for regressing from FP? Or perhaps the goals of Go aligned with my team's goals, and that was really helpful and valuable to us?
Re: Why Go is doomed to succeed
#300Earlier quoted context omitted.
Woo hoo, thanks for the tip! But I still need to worry about creating a memory leak with this. :(
Also, asprintf is a GNU-extension, so if you want to write portable code, it's a no-go (as for everything usefull in C).
Thankfully, I'm not doing much C any more. Those hoity-toity hand-holding languages have spoiled me, and now I don't want to be bothered about memory management and other "trivia." :)