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

61–70 of 169 posts

Re: Joe Armstrong: Solving the wrong problem

#61

Post by rdtsc »

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…

> However it has barely evolved in the last 10 years, will 2013 be the year of the structs?

Eh... It is not perfect but considering everything else it brings to the table (fault tolerance, distribution, concurrency) I can easily overlook its warts.

There is always Elixir or some LISP like dialects running on the BEAM VM as an alternative.

I for one like its syntax. It makes sense to me somehow. I which maps were there and I think one day they will be. I would rather they'd work on concurrency, speed and distribution.

Re: Joe Armstrong: Solving the wrong problem

#62

Post by rdtsc »

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…

As the complexity increases one thing that starts to show is not speedup in palatalization but fault tolerance.

Debugging a non-concurrent program can be difficult, now throw in threads, shared memory, pointers and it quickly becomes a nightmare. The system could be fast, but if it crashes every week, is it useful. Often the answer is yes. But in some cases the answer it no.

There is no free lunch. Shared-nothing architecture doesn't come for free. You pay a toll in _sequential_ performance. It might or not matter to you.

> Automatic parallelization is very possible.

For numerical algorithms many and for small function scope scale I can see that. Numerical code. But the problem is (and what Joe was pointing out) is that applications and algorithm design has to be build concurrently to start with.

A compile will not re-factor your code to not access a single database and acquire a lock from 100k clients into using some eventually consistent or event-sourcing data store. It is something that has to be built from ground up.

Same thing with fault tolerance, it has to built in from ground up. Adding it later is not easy.

Re: Joe Armstrong: Solving the wrong problem

#63

Post by rdtsc »

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 implementation of A* or some patented sort algorithm.

You can think of parallelization at system level. Can you handle client connections concurrently (and in parallel?). If yes, that covers a large chunk of the usage domain for platforms these days.

> memory management isn't handled that well (and many more).

Can you expand on that?

Re: Joe Armstrong: Solving the wrong problem

#64

Post by rdtsc »

eridius wrote: post #2

If zlib could be rewritten in Erlang to be lock-free, why not just rewrite it in C to be lock-free instead of porting it? AFAIK Erlang isn't some magical language that allows traditionally-locked data structures to become lock-free.

Ok so you re-write zlib. Then re-write, imagemagic, then re-write glibc, then re-write other, etc, etc.

Yes you can do it. But after a while it is like plugging wholes in a piece of swiss cheese. That is what Joe was saying you start with code that doesn't run well concurrently because concurrency was added later. It is better sometimes to start from scratch with a language that makes concurrency the default and the sequential sections are the exception.

> AFAIK Erlang isn't some magical language that allows traditionally-locked data structures to become lock-free.

There is some magic in how it has separate heaps and how it maps schedulers n:m (n cpus say 2 to 24 to m processes say 2 to 300k), how it provides concurrent garbage collection without stopping the world, how it provides hot code reloaded if that is what you need.

No it won't make coffee for you and it might not work well for a lot of tasks but it just happens to be the right tool for the right job lately as reliable concurrent back-ends becomes more important (as opposed to say single threaded desktop applications)

Re: Joe Armstrong: Solving the wrong problem

#65

Post by rdtsc »

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…

That's alright. Right tool for the right job. Don't try to use a drill if a hammer is more appropriate, it won't work. If you know C#, Python, etc, you will still need them. If it helps you ship, heck, even COBOL works.

Re: Joe Armstrong: Solving the wrong problem

#66

Post by marshray »

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…

Sequential programs are getting slower relative to the parallel programs and both the theoretical capacity of the systems. Also much of the market is shifting to chips optimized for power consumption which are, in fact, slower.

So while obviously the most literal and absolute interpretation of the statement "sequential programs are getting slower" is nonsensical, I think there's a very valid point being made.

Re: Joe Armstrong: Solving the wrong problem

#68

Post by wrboyce »

dvt wrote: post #46
banachtarski wrote: post #36

Earlier quoted context omitted.

> memory management isn't handled that well. So... how would you have handled it, out of curiosity.

> So... how would you have handled it, out of curiosity. Imo separate heaps is the first big mistake. Even implementations like Erjang (Erlang on the JVM using the Kilim microthreading library -- which I've also contributed to) improve on the copy-from-heap mechanism prevalent in vanilla Erlang. Not only that, but Erlang's memory allocator isn't that well-suited for multi-threaded allocations, which also means that E…

Maybe I am missing something, but aren't separate heaps (i.e., no shared memory between processes) one of the things that makes concurrency such a "joy" in Erlang?

Why do you feel the major selling point was the first big mistake?

Re: Joe Armstrong: Solving the wrong problem

#69

Post by marshray »

pdog wrote: post #52
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.

AMD recently sacrificed some single-threaded performance in order to achieve an increased core count. Whether or not that was a good move or representative of the industry as a whole is open to debate, but it does occasionally happen.

http://www.anandtech.com/show/5057/the-bulldozer-aftermath-d...

Re: Joe Armstrong: Solving the wrong problem

#70

Post by dap »

This completely misses the fact that many network services are not compute bound, and multi-tenancy (as we get from "the cloud") lets "legacy" code make very efficient use of CPU resources, even a larger number of relatively slow cores.
Post reply on HN