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

Why Erlang Matters

sameroom.io

Post reply on HN
Print view View original

91–100 of 210 posts

Re: Why Erlang Matters

#91

Post by jerf »

adrusi wrote: post #81
jerf wrote: post #6

Earlier quoted context omitted.

Erlang may be useful for coordinating computation tasks, but, yes, even with HIPE it is not a good numerical language on its own. It would be interest to re-engineer a language today that tries to fit into Erlang's niche but has a stronger performance focus. Rust, Cloud Haskell, and Go all sort of cluster in the area I'm thinking about, but none are quite what I'm thinking of. Cloud Haskell is probably closest but wr…

You can't really achieve Erlang's goals with a statically typed language, at least it would be very hard to make it easy to intuit whether a live reload will be sound. A language that allows mutable state aside from at process scope is also a no-go. In Erlang you're not supposed to think about what code will be running on which machines as you write the business logic, so you have to assume that every process is runn…

Live reload is a funny thing with Erlang. When I claim it's a feature, but describe the pain it is to use, I get told nearly nobody uses it. When I claim that nobody uses it, I get told that lots of people use it. I'm not sure it's something that an Erlang competitor would have to get right. And it would be valid to use a different mechanism for live reloads, perhaps something that explicitly migrates state between OS processes instead. At the very least I think the Erlang community would have to agree that it's a dodgy, improvable process.

"A language that allows mutable state aside from at process scope is also a no-go."

Well, I did say the language I'm spec'ing probably doesn't exist. Rust is an interesting example of what can be done to make it so that not actually copying memory is safe, but you'd still have to do some work to make it do the copying more transparently across nodes, which is why I said it's "just" a regular language from Erlang's point of view.

"Nothing about Erlang is inherently slow."

I now believe that dynamically-typed languages that are not built from speed from the beginning (LuaJIT being pretty much the only reason I even have to add that parenthetical) are inherently slow. I've been hearing people claim for 20 years that "languages aren't slow, only implementations are", I've even echoed this myself in my younger days, yet (almost) none of the dynamic languages go faster than "an order of magnitude slower than C with a huge memory penalty" even today, after a ton of effort has been poured into them. Some of them still clock in in the 15-20x slower range. Erlang is a great deal simpler than most of them, and I don't know whether that would net an advantage (fewer things to have to constantly dynamically check, although "code reloading" mitigates against some of these) or disadvantage (less information for the JIT to work with). Still, at this point, if someone's going to claim that Erlang could go C speed or even close to it in the general case, I'm very firmly in the "show me and I'll believe it" camp.

At some point it's time to just accept the inevitable and admit that, yes, languages can be slow. If there is a hypothetical JS or Python or PHP interpreter that could run on a modern computer and be "C-fast", humans do not seem to be capable of producing it on a useful time scale.

Re: Why Erlang Matters

#92

Post by adrusi »

jallmann wrote: post #80
adrusi wrote: post #63

Earlier quoted context omitted.

I know you weren't aiming for maximum accuracy in your definitions, but I think this is worth bringing up. Parallelism and Concurrency are not mutually exclusive terms. All parallelism is concurrent. Concurrency is whenever more than one thing is happening at the same time conceptually . Everything from iterators to threads. Parallelism is whenever more than one thing is happening at the same time physically . From a…

Yes. The intuition is a good one of parallelism being a deliberate way of designing a system to run its parts simultaneously (physically), with concurrency being a property of a system that may or may not have its parts running simultaneously (conceptually, 'overlapping', whether physically or logically). There are many, many ways to think about this difference, and it's fun (and beneficial!) to do so every once in a…

Well obviously threads aren't always running at the same time since each cpu can do only one thing at a time (or a finite number, if we're counting hardware threads) and you can have more threads than cpus.

It's the fact that they might run at the same time. Also from the perspective of the programmer, there's no difference between two threads running at the same time or by time sharing, since preemptive multitasking is non-deterministic and has the same implications as true parallelism.

Re: Why Erlang Matters

#93

Post by vvanders »

ssmoot wrote: post #82
vvanders wrote: post #78

Earlier quoted context omitted.

Not everything is web-apps either. If you've got soft realtime requirements( Erlang's GC model is just incredibly elegant. Almost like pooled allocators that we used to use in GameDev but in a completely transparent and intuitive way.

I'll concede that. But you have to admit this is an incredibly niche problem space. OTOH the JVM will have much higher throughput on the other 99% of apps. Don't get me wrong. I like Erlang. It's definitely in my top.. Uhm... 3 languages of interest. Being the only other language I know with Pattern Matching is a huge huge part of that. For most developers I'd just be careful in making that jump. Because most of what…

Yeah, but real-time is about latency not throughput :).

FWIW a lot of game engines use message passing between components/actors due to the low coupling and architectural benefits so it's not quite as small of a domain as you think.

Re: Why Erlang Matters

#94

Post by yelnatz »

namelezz wrote: post #42
aaron-lebo wrote: post #24

Earlier quoted context omitted.

I think it depends on your hiring process. Do you hire people who know how to code in language X and are really good at coding in language X but nothing else? Or, do you hire people who are go-getters, want to use the best tool for the job, and want to learn? Because if the latter, Erlang/Elixir might be esoteric, but Elixir specifically is a simpler language than currently more popular languages like Python or Ruby.…

Sometime I wonder why Elixir tries too hard to have Ruby syntax. Erlang: loop_through([H|T]) -> io:format('~p~n', [H]), loop_through(T); loop_through([]) -> ok. It seems convenient to use ';' to separate multiple definitions of a function compared to using 'end' in Elixir(function definition continues in the next block) Elixir: def loop_through([h|t]) do IO.inspect h loop_through t end def loop_through([]) do :ok end

Much of the Ruby influence is because the creator of Elixir (José) was previously from the Rails core team.

Re: Why Erlang Matters

#95

Post by rdtsc »

elihu wrote: post #26
jandrese wrote: post #2

I'm a very green Erlang noob, but given what I have seen from it I find articles like this kind of strange. Sure concurrent programming is difficult and we need to think hard about how to make programs run quickly in a multiprocessor environment, but the fundamental architecture of Erlang seems to be in conflict with big data and high speed computing. It seems like a language that can scale much better, but has such…

For years, I didn't see what the point of Erlang was. It might scale well, but if it takes an Erlang process running on a hundred processors to equal the performance of a single-threaded C application, what's the point? When I learned a bit more about Erlang, I realized that the point is that there are a lot of applications that are IO bound rather than computation bound, and for those apps Erlang performs very well…

One of the main points of Erlang is fault tolerance. Everyone forgets about that and talks actors and scalability, which is fine. But without fault tolerance and proceses with isolated heaps it doesn't matter how fast the C code is, it can process millions of transaction a second, and then segfault, and the availability and transaction rate goes to 0 on that node.

The other advantage is power of abstraction. With Erlang it is easy to describe and program distributed system with lots concurrent components. Sure you can do it with C++, Java, and Node.js etc, but those things are awkward there -- either threads share memory and have to deal mutexes, or you in are in callback/promise hell.

Re: Why Erlang Matters

#96

Post by rdtsc »

jandrese wrote: post #14
Jtsummers wrote: post #7

Earlier quoted context omitted.

> even strongly typed. A nit: Erlang is strongly typed. You cannot (ok, excluding numbers) almost transparently convert a string into a number into a tuple like you could in C, to which everything is merely memory so casting allows trivial but potentially erroneous conversions. Erlang is dynamically typed, not statically typed. Dialyzer + type annotations (and some inferred) allows for static analysis, but it's not d…

You've hit on the tradeoff though. By decentralizing your state, you've increased your inter-process synchronization requirements. In the worst case everything ends up being tightly bound and your application runs like a single threaded application because everything is always blocked waiting for the state update from a remote thread. Huge parallelism is easy if your data and processes are largely independent, but th…

> By decentralizing your state, you've increased your inter-process synchronization requirements.

But you've also increased your reliabily as well. Who cares if the tight single threaded application with a shared heap cand handle 100K connections, if as soon as one of those connection leads to a segfault, all the other 99999 crash as well.

Re: Why Erlang Matters

#98

Post by rdtsc »

arh68 wrote: post #77
wcummings wrote: post #37

Earlier quoted context omitted.

You could write NIFs in Rust (well not sure if you can now, but I don't see any reason it couldn't be supported) for the high perf bits and use Erlang to coordinate, I figure. At least Rust code is less likely to explode and bring down the whole VM than C.

Any idea if a network-level FFI has been started? I'm thinking along the lines of the Haskell erlang-ffi [0]. Speaks the Erlang network protocol and impersonates an Erlang node on the network. Fully capable of bi-directional communication with Erlang. NIFs still limit you to [0] https://hackage.haskell.org/package/erlang

Not anymore with dirty schedulers you will be able to (as of 19.0 I think) have any long running C code as a NIF!

Re: Why Erlang Matters

#99

Post by adrusi »

jerf wrote: post #91
adrusi wrote: post #81

Earlier quoted context omitted.

You can't really achieve Erlang's goals with a statically typed language, at least it would be very hard to make it easy to intuit whether a live reload will be sound. A language that allows mutable state aside from at process scope is also a no-go. In Erlang you're not supposed to think about what code will be running on which machines as you write the business logic, so you have to assume that every process is runn…

Live reload is a funny thing with Erlang. When I claim it's a feature, but describe the pain it is to use, I get told nearly nobody uses it. When I claim that nobody uses it, I get told that lots of people use it. I'm not sure it's something that an Erlang competitor would have to get right. And it would be valid to use a different mechanism for live reloads, perhaps something that explicitly migrates state between O…

I don't know if live reload is widely used or not, but the other features of erlang allow you to create systems that see decades of uptime. But without code hot swapping your uptime is limited by how often you ship new code. Typically a distributed application will be made of independent programs on various machines that you can upgrade and spawn and kill at your leisure. In erlang your entire distributed application is kind of like just one program, and what was an executable in the traditional model is now a module, so in order to match the capabilities of a traditional system, you need to be able to upgrade modules without killing everything.

---

There are a number of other dynamically typed languages that have fast implementations. Javascript has a few; Common Lisp, Self, Julia, to name some others. They'll never be as fast as C, certainly not when comparing highly optimized programs, but they're fast. It looks like most dynamically typed languages can be made to run 10x slower than C. Compare that to CPython and HiPE which are more like 100x slower.

I don't think code reloading would hurt JIT performance too much. The prerequisites for runtime specialization of procedures basically accomodate eveything hot swapping would need. I also think the way people use Erlang's type system is probably more ammenable to conservative type inference than the existing fast dynamic languages, and that's one of the more important metrics.

Re: Why Erlang Matters

#100

Post by jrobn »

pmontra wrote: post #51
catnaroek wrote: post #43

Earlier quoted context omitted.

Erlang processes are objects in their own right, not "dual" to them. The dual of object types (records of methods) are sum types: Object types are defined by how you can eliminate them (calling a method on an object), whereas sum types are defined by how you can introduce them (applying a constructor to suitable arguments).

He probably means that an Erlang process is equivalent to an object and message passing among processes is equivalent to method calls. In my experience with Elixir, objects, method calls and mutable data are easier to write than processes, messages and immutable data. It's not the mutable and immutable part, it's more about the boiler plate of spawning processes, receiving messages and matching them to dispatch them…

There is Pony (http://www.ponylang.org).
Post reply on HN