I can think of a few reasons: same language between front and backend, extensive standard library, repl driven development, simplicity, brevity, spec.
With Phoenix + LiveView maybe you won't need the frontend.
it's such a weird concept to me.. "server-rendered html" is what i was doing most of my webdev career and suddenly it's the "hot new thing"?
anyway i still don't see why i would need it with Clojure if i can have single codebase and language for backend and frontend and render whatever i want at either -end.
The JVM is a kitchen sink environment. The BEAM is very opinionated. I would expect the VM built from the ground up to support a specific programming model to be superior at doing just that.
BEAM is a wonderful VM, but calling it "optimized" for anything is problematic. It has focused on certain use cases, but it's seen less than 1% of the investment in the JDK, so I guess it's better to call it "specialized". While it works well enough for many things, its performance is like the JVM limping on both legs after a terrible car accident and a bad case of pneumonia while trying to walk on an icy road. You a…
I think your statement goes too far. In my experience, it's very difficult to do lightweight threading on the JVM anywhere near the performance of the BEAM, as well as region allocation in the style used by high-performance Erlang programs. I think a comparison is unfair. The BEAM definitely sucks for compute-oriented tasks, but it's an immense amount of work to make a JVM-based program compete in the areas where it's good.
There is no doubt that JVM can provide massively better performance for a lot of stuff, but I wouldn't be suprised if Beam kicked JVM's butt in at least some areas. It's pretty much the only system I know of that provides for massive numbers of fairly scheduled, preemptive green threads. To do so it makes trade-offs that are not generally attractive, but I'd be surprised if it didn't beat the JVM here.
I would be. BEAM is just a very slow platform, not just compared to Java, but also compared to JavaScript and Go. Again, that's not to say it's not very useful for some things (although many Erlang apps are really mixed Erlang/C apps because of BEAM's performance). Hey, CPython is really slow, too and yet very useful. Green threads is another matter as it's not a feature that currently exists on the Java platform (th…
There’s Akka. Also Scala has Future’s. Both are very similar to green threads.
Clojure is incredibly popular, and there are probably lots of people that are interested in learning Clojure but scared away by the JVM ecosystem.
There’s no way either statement you’re saying ia true. Clojure is certainly not “incredibly popular.” And if you think many people are scared away from the JVM vs the BEAM, I don’t even know what to say.
Just use Erlang with Dialyzer. It's not quite as nice as a lanugage with types built-in, but if you're strict about using it, it does work. I won't code without it.
I have burned more time than I care to admit trying to decipher dialyzer output shenanigans. I love dialyzer when my code doesn't generate any errors, and the rest of the time I kind of want to cry.
Not sufficient, and not for Erlang, but Dialyxir has a `mix dialyzer.explain` command, which gives an example of code that might cause a certain error. Some errors I have been unable to reproduce and I welcome examples of code that would produce them, so PRs are welcome =). Here is what I say for no_return, for example [0].
I maintain a library for converting Erlang Dialyzer messages to Elixir (Erlex [1]) which I hope to one day be able to retire with a stronger Elixir/Erlang communication (AST instead of string communication, e.g., and direct diffs between types).
There is no doubt that JVM can provide massively better performance for a lot of stuff, but I wouldn't be suprised if Beam kicked JVM's butt in at least some areas. It's pretty much the only system I know of that provides for massive numbers of fairly scheduled, preemptive green threads. To do so it makes trade-offs that are not generally attractive, but I'd be surprised if it didn't beat the JVM here.
I would be. BEAM is just a very slow platform, not just compared to Java, but also compared to JavaScript and Go. Again, that's not to say it's not very useful for some things (although many Erlang apps are really mixed Erlang/C apps because of BEAM's performance). Hey, CPython is really slow, too and yet very useful. Green threads is another matter as it's not a feature that currently exists on the Java platform (th…
It's true that BEAM has excellent concurrency, parallelism, supervision, message passing... but I don't know understand why that has to come at the expense of being terrible at everything else. Why doesn't it have even a baseline reasonable quality JIT? Why doesn't its GC use a design more recent than half a century ago? It's got big corporate backers and PhDs working on it.
BEAM is a wonderful VM, but calling it "optimized" for anything is problematic. It has focused on certain use cases, but it's seen less than 1% of the investment in the JDK, so I guess it's better to call it "specialized". While it works well enough for many things, its performance is like the JVM limping on both legs after a terrible car accident and a bad case of pneumonia while trying to walk on an icy road. You a…
There is no doubt that JVM can provide massively better performance for a lot of stuff, but I wouldn't be suprised if Beam kicked JVM's butt in at least some areas. It's pretty much the only system I know of that provides for massive numbers of fairly scheduled, preemptive green threads. To do so it makes trade-offs that are not generally attractive, but I'd be surprised if it didn't beat the JVM here.
I'd say the feature of BEAM is fault-tolerant massive scalability of concurrency rather than performance/throughput. JVM as a platform lacks all the concurrency tooling of BEAM like the integrated debugging and monitoring tools. The AKKA implementation seems like a total afterthought rather than the fundamental core which it is in Erlang.
Moreover, from what I understand unlike BEAM, JVM does not prioritize low consistent latency but throughput instead.
I just feel they're designed for very different purposes. BEAM is most definitely not a general computing platform and would not perform well as such. In contrast, I'd imagine it'd be painful to develop concurrent stateful distributed systems on top of the JVM, regardless of the language.
BEAM is a wonderful VM, but calling it "optimized" for anything is problematic. It has focused on certain use cases, but it's seen less than 1% of the investment in the JDK, so I guess it's better to call it "specialized". While it works well enough for many things, its performance is like the JVM limping on both legs after a terrible car accident and a bad case of pneumonia while trying to walk on an icy road. You a…
I think your statement goes too far. In my experience, it's very difficult to do lightweight threading on the JVM anywhere near the performance of the BEAM, as well as region allocation in the style used by high-performance Erlang programs. I think a comparison is unfair. The BEAM definitely sucks for compute-oriented tasks, but it's an immense amount of work to make a JVM-based program compete in the areas where it'…
Yeah, but lightweight threading is a built in primitive in BEAM, so if you only measure scheduling overhead it is very low, but once you do any work inside those processes, it runs like any code running on low-performance runtimes. The isolated heaps are also OK, but the modern JVM GCs would still give you lower latency even with a shared heap. BEAM, CPython, MRI Ruby and other low-performance runtimes get the job done for whatever it is they're used for, and if all you're doing is IO it may not be too bad, but let's not mention those runtimes anywhere near good performance. BEAM is certainly in the bottom half or third of the Techempower benchmarks.
There is no doubt that JVM can provide massively better performance for a lot of stuff, but I wouldn't be suprised if Beam kicked JVM's butt in at least some areas. It's pretty much the only system I know of that provides for massive numbers of fairly scheduled, preemptive green threads. To do so it makes trade-offs that are not generally attractive, but I'd be surprised if it didn't beat the JVM here.
I'd say the feature of BEAM is fault-tolerant massive scalability of concurrency rather than performance/throughput. JVM as a platform lacks all the concurrency tooling of BEAM like the integrated debugging and monitoring tools. The AKKA implementation seems like a total afterthought rather than the fundamental core which it is in Erlang. Moreover, from what I understand unlike BEAM, JVM does not prioritize low consi…
> In contrast, I'd imagine it'd be painful to develop concurrent stateful distributed systems on top of the JVM, regardless of the language.
Concurrent stateful distributed systems on the Java platform probably outnumber those on BEAM 100 to 1, but I agree that we absolutely love Erlang's relevant constructs, which is why we're bringing them to the Java platform.
I would be. BEAM is just a very slow platform, not just compared to Java, but also compared to JavaScript and Go. Again, that's not to say it's not very useful for some things (although many Erlang apps are really mixed Erlang/C apps because of BEAM's performance). Hey, CPython is really slow, too and yet very useful. Green threads is another matter as it's not a feature that currently exists on the Java platform (th…
It's true that BEAM has excellent concurrency, parallelism, supervision, message passing... but I don't know understand why that has to come at the expense of being terrible at everything else. Why doesn't it have even a baseline reasonable quality JIT? Why doesn't its GC use a design more recent than half a century ago? It's got big corporate backers and PhDs working on it.
I would imagine that's because they'd rather focus whatever resources they have on the needs and priorities of their target audience, which probably don't think performance is critical. I hope that one day TruffleBEAM+Loom would be a great platform for all those wonderful Erlang apps.