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

31–40 of 169 posts

Re: Joe Armstrong: Solving the wrong problem

#31

Post by cube13 »

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.

I'm confused where the lock that TFA is talking about is in zlib. We've used zlib in a multithreaded environment for years, and haven't had any issues with it, and as far as I can see, there isn't any mutex or semaphore usage in the source code(http://zlib.net/ ) for the library.

It sounds like this is a zlib usage issue more than anything else.

Re: Joe Armstrong: Solving the wrong problem

#32

Post by eksith »

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 the dead to life, create unicorns and other wonderful, fantastic things that I'm sure are all true, just don't seem to be capable of passing into my grey matter.

You know another thing all these amazing super power languages haven't been able to do that even a crappy, broken, in many ways outright wrong, carcinogenic etc... etc... language like even PHP has allowed me to do? Ship in 48 hours.

Before, I get flamed, I already tried that with Nitrogen (http://nitrogenproject.com). It didn't end well, but maybe it will work for someone already familiar with Erlang.

It's like you've written the Mahabharata; it'a a masterpiece and it's one of the greatest epics of all time. Unfortunately, it's written in Sanskrit.

Re: Joe Armstrong: Solving the wrong problem

#33

Post by lobster_johnson »

kkowalczyk wrote: post #25
masklinn wrote: post #16

Earlier quoted context omitted.

> I havent tried go or dart yet Well Go uses shared-memory concurrency and no other so... Rust still looks more interesting there, though they still have to deliver the language (it's still heavily in flux)

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…

An important side effect of not permitting sharing memory is that you can always recover sanely.

An Erlang process has its own heap, so when it blows up, its state just goes away, leaving your remaining program's state untouched. With Go, there is no way to recover sanely; even if your goroutines are designed to copy memory, Go itself has a single heap.

Now, this is a very odd design decision for a language that claims it's designed for reliability. Perhaps Go's authors thinks it's better just for the entire program to die if a single goroutine falls over; well, that's one way, but it's a crude one. Erlang's design is simply better.

I wonder if Go can ever adopt per-goroutine heaps, or whether it's too late at this stage. I was happy to see that Rust has chosen to follow Erlang's design by having per-task heaps, even if all the pointer mechanics (three times of pointers, ownership transfer, reference lifecycles and so forth) result in some fairly intrusive and gnarly syntax.

Re: Joe Armstrong: Solving the wrong problem

#35

Post by larsberg »

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 of _sequential_ performance available as low-hanging fruit. Sure, they'd take free performance, but the rewrite/porting/debug costs (even in automatic parallel compilers for the same language) are at least as high as just firing up a profiler.

I'm increasingly of the opinion that if you can't win a top spot in the supercomputer performance fight, you have to have a unique application domain. Erlang's seems to be reliability. I suspect that a parallel variant of javascript that runs in every browser will end up being the next compelling parallel language, as opposed to all of us who are either inventing or attempting to resurrect languages that target x86 or GPUs.

Re: Joe Armstrong: Solving the wrong problem

#36

Post by banachtarski »

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…

> memory management isn't handled that well.

So... how would you have handled it, out of curiosity.

Re: Joe Armstrong: Solving the wrong problem

#37

Post by djvu9 »

We used Erlang several years ago. The code base has ~100k lines of code so it should be representative. We abandoned it later and switched to C++ because of performance (mostly in mnesia) and quality issues (some drivers in OTP). We didn't expect too much from performance considering it is functional (which seldom does in place update) but it is still below expectation.

It is understandable though. Just think about how much resources have been put into development of Erlang VM and the runtime/libraries(OTP), and compare it with JVM/JDK. There is just no magic in software development. When talking about high concurrency and performance, the essential things are data layout, cache locality and CPU scheduling etc for your business scenario, not the language.

Re: Joe Armstrong: Solving the wrong problem

#38

Post by abc_lisper »

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…

Now, I have never read or written PHP. Here's the thing. PHP fills a niche. That niche is being super-productive early on. There are other goals, like, the code being readable, ease of being reasoned about, fast and so on.

And there are languages that fill those niches. When people say crappy language, more often than not, crappy for their needs(or sometimes their expertise). There is no need to fight about it; its like saying who prefers which color.

The reason you do lisp is not to do coding in it(given the current state of affairs), but to reshape one's mind by thinking in terms previously unseen because we could not see forest for the trees.

And that ability to see something from different view points arms you with weaponry to solve challenging problems. There is atleast a physicist who agrees with me on that :) http://www.youtube.com/watch?v=IfUhkSEoku0

Re: Joe Armstrong: Solving the wrong problem

#39

Post by jrajav »

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…

So somebody else doesn't waste a minute or two googling up the wrong tree: It's Hystrix, not Hysterix.

https://github.com/Netflix/Hystrix

http://akka.io/

Re: Joe Armstrong: Solving the wrong problem

#40

Post by rcfox »

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…

> 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.

I had the same problem with Lisp (Scheme, to be more specific) and I thought that it'd be impossible to reason about run-times and such. That is, until I learned the language and the standard libraries. I've never looked at Erlang, but I'd bet it's the same issue.

A C++ programmer can look at C# code and figure out what it's doing because they have similar syntax and vocabulary. Just because Erlang isn't immediately accessible to you, it doesn't mean it isn't any good for shipping in 48 hours.

Perhaps if you spend 24 hours sharpening your axe, you'll chop that tree down in another 4 hours instead of using the full 48.

Post reply on HN