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

Joe Armstrong: Solving the wrong problem

joearms.github.com

Post reply on HN
Print view View original

71–80 of 169 posts

Re: Joe Armstrong: Solving the wrong problem

#71

Post by marshray »

MichaelGG wrote: post #57
tieTYT wrote: post #15

Earlier quoted context omitted.

I was following you until your last sentence. I've never done concurrency in a FP language before, but I do know that writing it in Java makes it hard to get right.

What prevents you from implementing an actor/message passing system in Java? Erlang's core concept of concurrency seems like something that'd be better suited as a library and app server than a whole language and runtime. I've yet to hear of any Erlang-specific magic that cannot be implemented inside another language.

Erlang itself is, after all, implemented in C and ASM.

But what you can't (practically) implement yourself in other languages is all the professional care and maturity that have gone into the whole package over its long history. AFAICT, Erlang/OTP is much more than just a library.

Re: Joe Armstrong: Solving the wrong problem

#72

Post by seanmcdirmid »

mncolinlee wrote: post #18

I worked in Cray's compiler department for seven years. If we couldn't dramatically parallelize someone's code, we couldn't sell a vector supercomputer. Period. Automatic parallelization is very possible. The problem is tends to be less efficient. A decent developer can often do a better job than the compiler by performing manual code restructuring. The compiler cannot always determine which changes are safe without…

Erlang is not designed for parallel programming; it is designed for concurrent programming. These are two very different programming domains with different problems.

Every time someone conflates parallelism with concurrency...everyone gets very confused.

Re: Joe Armstrong: Solving the wrong problem

#73

Post by Peaker »

rdtsc wrote: post #63
dvt wrote: post #27

Same old hype. Erlang is good I guess, and I've used it in production a couple of times. But it's just a language that solves 3 problems but creates another 30. Just like C++11, Dart, Go, etc. This kind of belligerent rhetoric (we're solving the right problems, everyone else is dumb) is the kind of drivel that gives momentum to language zealots that think language X is better than language Y. I've contributed to Goog…

> The syntax is outdated and stupid (Prolog lol), How is it any more or less stupid than curly bracket. Show me another production ready language that has the same level of pattern matching as Erlang. > Often times, algorithms simply cannot be parallelized. Who cares. How many people here have implemented individual algorithms and delivered them as units of execution. Sure middleware companies maybe sell a cool imple…

Haskell has nicer pattern matching capabilities.

Re: Joe Armstrong: Solving the wrong problem

#74

Post by Evbn »

burntsushi wrote: post #51
masklinn wrote: post #30

Earlier quoted context omitted.

> Go allows you to share memory between goroutines (i.e. concurrent code). Go will share memory, by default, and special attention must be taken preventing or avoiding it. It's not an allowance. > In fact, the Go team explicitly tells you not to do that And yet they have refused to implement a correct model, even though they have no problem imposing their view when it fits them (and having the interpreter get special…

> Go will share memory, by default, and special attention must be taken preventing or avoiding it. Not really. If you use channels to communicate between goroutines, then the concurrency model is that of sequential processes, even if channels are implemented using shared memory under the hood. That is, the default concurrency model militated by Go is not shared memory, but that of CSP. It's disingenuous to affix Go w…

for i:= range list { go func() { foo(i) } }

(This is a bug in the spec, but will not be fixed before Go 2 because Go 1.0 is frozen.)

Shared memory by default.

Re: Joe Armstrong: Solving the wrong problem

#75

Post by sshumaker »

MichaelGG wrote: post #57
tieTYT wrote: post #15

Earlier quoted context omitted.

I was following you until your last sentence. I've never done concurrency in a FP language before, but I do know that writing it in Java makes it hard to get right.

What prevents you from implementing an actor/message passing system in Java? Erlang's core concept of concurrency seems like something that'd be better suited as a library and app server than a whole language and runtime. I've yet to hear of any Erlang-specific magic that cannot be implemented inside another language.

Ultra-lightweight actors, a VM scheduler tuned for scheduling massive numbers of concurrent ops, etc. If you tried doing this in with a java library running java code, you couldn't get anywhere near their level of concurrency.

Re: Joe Armstrong: Solving the wrong problem

#76

Post by Evbn »

MichaelGG wrote: post #57
tieTYT wrote: post #15

Earlier quoted context omitted.

I was following you until your last sentence. I've never done concurrency in a FP language before, but I do know that writing it in Java makes it hard to get right.

What prevents you from implementing an actor/message passing system in Java? Erlang's core concept of concurrency seems like something that'd be better suited as a library and app server than a whole language and runtime. I've yet to hear of any Erlang-specific magic that cannot be implemented inside another language.

Java's syntactic overhead stops most humans. "final" everywhere, big method names for every primitive message passing operation, etc

Re: Joe Armstrong: Solving the wrong problem

#77

Post by jeremyjh »

masklinn wrote: post #20
meshko wrote: post #12

The lack of understanding is amazingly widespread. I often have to explain to people that when they look at their CPU utilization and it is at 10% it means "you are throwing money way", not "you are efficient".

That's not really true though, or at least not on all workloads: much as you are not "throwing money away" by not pegging your car engine in the red zone 100% of the time, you're not throwing money away by not being at 100% CPU all the time, there are other metrics, values and issues to take in account e.g. a pegged CPU but an unresponsive computer is useless for a desktop, a pegged CPU which can't serve requests bec…

It sounds like you missed the point here. If an eight-core server is at 10% utilization, it effective has a single processor nearly pegged and the process doing it is thus CPU bound (and maybe serving responses at a high latency) while you have other cores sitting idle. Conserving CPU resources and running under capacity is wise, but has nothing at all to do with this comment.

Re: Joe Armstrong: Solving the wrong problem

#78

Post by SoftwareMaven »

MichaelGG wrote: post #57
tieTYT wrote: post #15

Earlier quoted context omitted.

I was following you until your last sentence. I've never done concurrency in a FP language before, but I do know that writing it in Java makes it hard to get right.

What prevents you from implementing an actor/message passing system in Java? Erlang's core concept of concurrency seems like something that'd be better suited as a library and app server than a whole language and runtime. I've yet to hear of any Erlang-specific magic that cannot be implemented inside another language.

How would you get per-actor heaps that cannot be violated by other actors? That is critical to Erlang's ability to recover from processes dying. I spent a lot of time doing Java and can't think how you could (you could in the JVM if you had language constructs for it, but then we are back to a new language).

There's a reason Stackless Python's actors aren't just a library on top of Python.

Re: Joe Armstrong: Solving the wrong problem

#79

Post by SoftwareMaven »

mncolinlee wrote: post #18

I worked in Cray's compiler department for seven years. If we couldn't dramatically parallelize someone's code, we couldn't sell a vector supercomputer. Period. Automatic parallelization is very possible. The problem is tends to be less efficient. A decent developer can often do a better job than the compiler by performing manual code restructuring. The compiler cannot always determine which changes are safe without…

If the code isn't efficient, you'll run into Ahmdal's Law much more quickly. In fact, I think your comment aligns with what Joe was saying: automated paralellization is not going to happen. You will have to go through and find all your contention points, just like your application experts did.

I completely agree with your last sentence. For those of us who have dived in a way, the advantages become clear, but TFA was really just preaching to the choir.

Re: Joe Armstrong: Solving the wrong problem

#80

Post by SoftwareMaven »

pnathan wrote: post #49
eksith wrote: post #42

Earlier quoted context omitted.

I used hyperbole of course, but in fairness, I've spent on the order of several months getting into Lisp. Mabye it's because I didn't work with it exclusively (I've been told here on HN that you need to be immersed in it completely and continously) that I still didn't become OK in any semblance of the term. But here's the thing: I switched to C# from VB.Net. Before that, it was VBScript (ASP pages) and even before th…

Basically, I would say that what you are suffering from is a kind of mental block syndrome: you think in a procedural/imperative paradigm. All your listed languages operate in that paradigm. It's a very transferable paradigm, as it so happens. I can come up to (some approximation of) speed in an imperative language in under 2 weeks. In order to ship Lisp(Prolog, Haskell...), you have to break out of that paradigm. I…

I couldn't break that thinking in college and struggled every day of my software engineering course where we implemented a Pascal compiler in Scheme. It wasn't until 10 years later that I started to get a handle on functional programming, due in part to some trickle-down from my Emacs config files. :)
Post reply on HN