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

51–60 of 169 posts

Re: Joe Armstrong: Solving the wrong problem

#51

Post by burntsushi »

masklinn wrote: post #30
kkowalczyk wrote: post #25

Earlier quoted context omitted.

Go allows you to share memory between goroutines (i.e. concurrent code). It doesn't force you to do so. In fact, the Go team explicitly tells you not to do that: "do not communicate by sharing memory; instead, share memory by communicating." ( http://blog.golang.org/2010/07/share-memory-by-communicating... ) i.e. they tell you to use the Erlang model. But as everything, there are trade-offs. Even Go team uses shared…

> 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 with the same kind of concurrency model used in C.

> And yet they have refused to implement a correct model

What is a correct model? Erlang's model isn't correct. It's just more safe.

> (and having the interpreter get special status in breaking them, see generics)

What's your point? Purity for purity's sake?

Re: Joe Armstrong: Solving the wrong problem

#52

Post by pdog »

konstruktor wrote: post #22

> At this point in time, sequential programs started getting slower, year on year, and parallel programs started getting faster. The first part of this statement is plain wrong. Single thread performance has improved a lot due to better CPU architecture. Look at http://www.cpubenchmark.net/singleThread.html and compare CPUs with the same clock rate, where a 2.5 GHz. An April 2012 Intel Core i7-3770T scores 1971 point…

Obviously, sequential programs haven't been getting slower on new chips. However, the acceleration rate of single thread performance has been slowing, so even with all our tricks we're getting double in four years when it used to be every 18 months just by doubling the number of transistors on an IC.

Re: Joe Armstrong: Solving the wrong problem

#53

Post by artsrc »

Excel solves this right problem, and Erlang does not.

Erlang allows you to create concurrent programs, i.e.: programs where the result is schedule dependent.

One right problem is allowing people to write deterministic parallel programs. This gives you the speed (from parallel) with the reliability (from deterministic).

Re: Joe Armstrong: Solving the wrong problem

#54

Post by lucaspiller »

eksith wrote: post #32

There's one big problem Erlang couldn't solve that I live with to this day : Unlike another general purpose language (like say, C++ or C#) allow me to grasp what's happening after staring at it for 30 seconds. This is the same problem, I have with Lisp. Maybe I'm just dyslexic, but these rhetoric pieces for one language or another that says it's concurrent (which it is), fast (obviously), more C than C, will bring th…

I think Erlang/OTP probably has a higher learning curve than other frameworks, but I guess is a lot down to history. As another poster said Erlang solved this problem 20 years ago, where as more modern languages are typically based on the C syntax, so they share a lot in common.

Back to your point though, I think once you understand the language it is actually a lot simpler to understand what is going on. Modules are usually very self contained, and you don't get the layers upon layers of indirection you see in other frameworks (I'm looking at you Rails). I think the functional style of programming as well helps to keep things simple, it doesn't make sense to have a 20 line function in Erlang.

Re: Joe Armstrong: Solving the wrong problem

#55

Post by jd007 »

konstruktor wrote: post #22

> At this point in time, sequential programs started getting slower, year on year, and parallel programs started getting faster. The first part of this statement is plain wrong. Single thread performance has improved a lot due to better CPU architecture. Look at http://www.cpubenchmark.net/singleThread.html and compare CPUs with the same clock rate, where a 2.5 GHz. An April 2012 Intel Core i7-3770T scores 1971 point…

Your point is absolutely correct, but your example could be better IMO. It's not fair to compare a desktop chip with 45W TDP with a laptop chip rated at 35W. Not to mention that the newer i7 actually goes up to 3.7Ghz turbo (vs. 2.5Ghz constant for the C2D) for single threaded loads, so the clock rate is not really comparable in that benchmark (even though base clocks are the same).

A better example would be C2D E8600 @ 3.33Ghz and i5 3470S @ 2.90GHz (3.6Ghz turbo). They are both 65W desktop parts, and the single threaded clock speed is similar. You can see that the C2D gets 1,376 in the single threaded benchmark, while the i5 gets 1,874. The difference is not as drastic (the C2D launched at a significantly higher price point as an enthusiast level chip, while the i5 is a budget chip) but definitely still significant. There are probably even better comparisons but I didn't spend too much time picking out comparable CPUs from different generations.

Re: Joe Armstrong: Solving the wrong problem

#56

Post by jeremyjh »

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…

It would be nice if Go provided for immutable variables.

Re: Joe Armstrong: Solving the wrong problem

#57

Post by MichaelGG »

tieTYT wrote: post #15
daleharvey wrote: post #11

I cant help but read a lot of irony in this. Erlang solved a problem really well over 20 years ago, its the sanest language by far that I have used when dealing with concurrent programming. (I havent tried go or dart yet) and I owe a lot of what I know to the very smart people building erlang. However it has barely evolved in the last 10 years, will 2013 be the year of the structs? (I doubt it), every new release com…

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.

Re: Joe Armstrong: Solving the wrong problem

#58

Post by splicer »

> We’re right and the rest of the word is wrong. We (that is Erlang folks) are solving the right problem, the rest of the world (non Erlang people) are solving the wrong problem.

> The problem that the rest of the world is solving is how to parallelise legacy code.

As member of the rest of the world, I can assure you that I'm not trying to solve either of these problems. :p

Re: Joe Armstrong: Solving the wrong problem

#59

Post by tieTYT »

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.

You mean like the Scala and Clojure libraries? You can use those in Java code if you want.

Re: Joe Armstrong: Solving the wrong problem

#60

Post by necrodome »

larsberg wrote: post #35
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…

I completely agree. As someone who works on a parallel functional language, it's very hard to sell a parallel language that isn't as fast as parallel fortran or hand-tuned C code that uses pthreads and the fastest parallel implementation of BLAS and other libraries. The people who really care about performance are using those. The ones who don't are honestly mostly still writing code that has large constant factors o…

Does/can Manticore have a such unique application domain?
Post reply on HN