My first attempt was a server for a dungeon crawler that superficially looked like a rogue-like, but was actually 12 frames/sec realtime instead of turn based. It started out on Clojure, but I afterwards ported it to Go. In this server, the world was divided into 80x24 subgrids that did most of their processing in parallel. Processing would happen in two stages: 1) local data processing, where each entity got updated…
Why did you leave Clojure?
Clojure weenies on IRC. To be fair, the Go weenies aren't much better. If you like hanging out on IRC so that you can emotionally abuse newbies, ask yourself what you're doing with your life.
A practical language based on well-researched first principles. Details in the armstrong_thesis_2003.pdf * java is unsuitable * no pthreads, please (wrong concept) * immutable data (no locks - no problem) * isolated lightweight processes (share nothing) * communication by message-passing (grom Kay's OOP) * dynamic typing (good-enough, quick prototyping) * pattern matching (on receive) * supervision hierarchies (fault…
I've not found immutable data to be the big win people tout it as. In most of what I do acting on stale data is just as bad, which means I wind up needing a lock anyway.
Doing a < b and taking an action based on that result is as harmful with stale data.
Not really. Experience after designing and deploying systems that run 100,000 transactions/sec per box: don't bother with engineers that cannot achieve proficiency in Erlang. Elixir is a crutch, and not something you want to show up with in 400 meters hurdles race. You will look pathetic.
https://blog.discordapp.com/how-discord-handles-push-request... Erlang has its uses and Elixir has its uses. Dismissing Elixir's userbase as 'pathetic' is pretty rude and a disservice to a pretty incredible language. See the Discord article where they clearly demonstrate Elixir and Genstage are ready for production and can be used to write performant services. I get that you really like Erlang and its quirks, but may…
Unrelated to your discussion with the parent, but I just wanted to point out that the fact that a system which was implemented in Elixir and runs on the Erlang virtual machine is able to sustain that traffic (and here I am referring to the link you posted) is and should be regarded as, largely, a quality of the Erlang virtual machine, and only to a very small extent to the programming language that it has been implemented in, if any at all. The fact that a system implemented in Elixir can sustain a large quantity of traffic while running on the Erlang virtual machine does not prove much about Elixir itself, other than the fact that it’s usable; you can implement the exact same system in Erlang also, or any other programming language for that matter. There is no inherent quality of Elixir itself that makes programs handle large amounts of traffic. That’s a quality of the Erlang virtual machine; Elixir is just syntax.
I get that, but as I say we already knew how to scale those linearly in most programming languages. Erlang brought nothing new there. It does have advances in things like reloading and supervision.
Erlang was invented 30 years ago to solve problems that were not easily solvable by the back then prevalent programming languages. The claim that Erlang hasn’t brought anything new to the table couldn’t be further from the truth. Designing concurrent, fault-tolerant programs was not a problem solved in a satisfying way by the programming languages and technologies that were mainstream back then, which is exactly why…
I acknowledged the areas where Erlang did bring advancements such as fault tolerance.
I read that paper, more than once, and his thesis, when I was doing my own PhD on parallelism, so I know the area and related work fairly well.
I don't think I'm embarrassing myself when I say that it's silly to claim that an arbitrary Erlang program should achieve linear scalability. But we don't need to debate with vague claims to originality - as I say Amdahl has done the maths and shows that it is only possible for a program that is embarrassingly parallel.
> Your Erlang program should just run N times faster on an N core processor But only if your program is embarrassingly parallel with at least N times available parallelism in the first place! If you have one of those it's already trivial to write a version that runs N times faster on N cores in C, Java, multi-process Python, whatever. If your program has sequential or less parallel phases or needs to communicate then…
I searched many times the comparison of Erlang BEAM and JVM regarding performance but couldn't find much. May be it is not done, or maybe it is not publicly available. At my work some folks keep pushing RabbitMQ over ActiveMQ for no other good reason than it is in Erlang so we will get much better performance. I know it is not true but could not find web links to support that.
BEAM is slower than the JVM for sequential code but it doesn't have a block the world GC and it has preemptive multi processing. It'll have worse steady state performance but a lot of the worst cases that Java can have are heavily mitigated.
A practical language based on well-researched first principles. Details in the armstrong_thesis_2003.pdf * java is unsuitable * no pthreads, please (wrong concept) * immutable data (no locks - no problem) * isolated lightweight processes (share nothing) * communication by message-passing (grom Kay's OOP) * dynamic typing (good-enough, quick prototyping) * pattern matching (on receive) * supervision hierarchies (fault…
I've not found immutable data to be the big win people tout it as. In most of what I do acting on stale data is just as bad, which means I wind up needing a lock anyway. Doing a < b and taking an action based on that result is as harmful with stale data.
But the data can't be stale, because `a` and `b` are immutable
https://blog.discordapp.com/how-discord-handles-push-request... Erlang has its uses and Elixir has its uses. Dismissing Elixir's userbase as 'pathetic' is pretty rude and a disservice to a pretty incredible language. See the Discord article where they clearly demonstrate Elixir and Genstage are ready for production and can be used to write performant services. I get that you really like Erlang and its quirks, but may…
Unrelated to your discussion with the parent, but I just wanted to point out that the fact that a system which was implemented in Elixir and runs on the Erlang virtual machine is able to sustain that traffic (and here I am referring to the link you posted) is and should be regarded as, largely, a quality of the Erlang virtual machine, and only to a very small extent to the programming language that it has been implem…
Thanks for your clarification. I think 'just syntax' is a bit dismissive of the importance that well-designed syntax has on being able to reason clearly in a certain way. Elixir's "just syntax" has made it so easy for me to understand FP concepts like pattern matching and higher order functions. I've struggled with these concepts before while trying to learn Haskell, Erlang and many other FP languages. Does that make me a bad programmer? The parent commenter would certainly think so.
I totally take your point that everything written in Elixir could be written in Erlang. That much is a fact. However, my point in saying they serve different uses is saying that better syntax in itself isn't nothing. If a language enables many people to grasp actor-based concurrency in an easy to understand fashion, can we reduce that to "just syntax"? I guess my point is that introducing syntactic clarity is in itself a massive feature that shouldn't be dismissed.
Erlang was invented 30 years ago to solve problems that were not easily solvable by the back then prevalent programming languages. The claim that Erlang hasn’t brought anything new to the table couldn’t be further from the truth. Designing concurrent, fault-tolerant programs was not a problem solved in a satisfying way by the programming languages and technologies that were mainstream back then, which is exactly why…
I acknowledged the areas where Erlang did bring advancements such as fault tolerance. I read that paper, more than once, and his thesis, when I was doing my own PhD on parallelism, so I know the area and related work fairly well. I don't think I'm embarrassing myself when I say that it's silly to claim that an arbitrary Erlang program should achieve linear scalability. But we don't need to debate with vague claims to…
Concurrency is not parallelism. You conflate parallelism with concurrency in your comments both here and above. I should also mention that for a big part of its life the Erlang virtual machine has had no support for parallelism. Erlang was not invented to solve parallelism so your hypothesis is downright wrong. Parallelism was just a consequence of the concurrency which was not exploited by the Erlang virtual machine until a much later point. And yes, if you read the paper I have referred to in my previous comment you will happily find out exactly the reasons for why Erlang was invented and what sort of problems it has solved. Also, to clarify, I did not claim that you were wrong about Amdahl’s law; you are however completely wrong in your claim that Erlang has brought nothing new other than supervisors and hot code reloading to the table.
This was back in a brief period when Erlang was being hyped by people as a potential Next Big Thing. Unfortunately it never really got that much momentum though, until Elixir and Phoenix came along.
Similar thing for Ruby: it wasn't popular until Ruby on Rails. It may be just
that most programmers need to write dynamic websites, as opposed to network
services (most likely with custom protocols).