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

Erlang/OTP: Garbage Collector

medium.com

Post reply on HN
Print view View original

61–70 of 79 posts

Re: Erlang/OTP: Garbage Collector

#61

Post by weatherlight »

pron wrote: post #58
weatherlight wrote: post #57

Earlier quoted context omitted.

To be a competitor, to be fair, implies there's competition. ¯\_(ツ)_/¯. There's no world, where I'd allow for some future developer to write some Java on the same VM as my Erlang/Elixir code and risk the entire VM crashing. JVM and Erlang's VM cater to different needs and programming paradigms. While they might share some features or learn from each other's innovations, they are not direct competitors but rather addr…

What do you mean by "the entire VM crashing"? The JVM is no more susceptible to crashes than BEAM. BTW, my point is that can now be a very good platform for Erlang/OTP. Its performance will allow Erlang/Elixir programs to reduce their reliance on native code and to handle higher loads.

It's my understanding the state of the art in observing JVM-based applications is a combination of using thread dumps, gc logs, thread activity visualizations. Thread dumps give us a snapshot of the the name of the thread, its current running state (waiting, blocked, etc), and the stacktrace of the work its currently doing. GC logs give you a record of when and how much garbage was collected and Thread activity visualizations show you the timeline of thread moving between different running states.

The BEAM gives you the ability to see the bottlenecks in your system, via the REPL (in real time!)

It has world-class introspection built in that gives you the power to observe and manipulate your running application through a REPL.

The BEAM has hundreds of features like this, because the BEAM is more of an OS than and VM.

I get it, you're a JVM expert, but the BEAM is more than a check list of optimizations that on paper the JVM can do.

I strongly suggest, before the next time you comment on an BEAM VM vs.JVM debate, please consider watching https://www.youtube.com/watch?v=JvBT4XBdoUE, "The Soul of Erlang and Elixir • Sasa Juric • GOTO 2019"

and reading https://github.com/happi/theBeamBook " an attempt to document the internals of the Erlang runtime system and the Erlang virtual machine known as the BEAM."

Best of luck!

Re: Erlang/OTP: Garbage Collector

#62

Post by Nezteb »

travisgriggs wrote: post #35
Nezteb wrote: post #14

Earlier quoted context omitted.

Is any part of that relay open-source by chance? If not, what libraries are you using?

I’m not a big fan of framework mashups, so I’ve kept it pretty light and straightforward. Also, I was learning (and of course still am) when I started putting this together, so less things to learn was a boon. - tortoise311 - I’ve toyed rewriting my own. We do very simple MQTT, 0 QoS, no wills, etc. the existing implementation creates many long lived procs per connection and we keep our connections live; they’re most…

I appreciate the list, thanks! `tortoise311` was the only one I hadn't previously heard of.

Re: Erlang/OTP: Garbage Collector

#63

Post by vips7L »

weatherlight wrote: post #61
pron wrote: post #58

Earlier quoted context omitted.

What do you mean by "the entire VM crashing"? The JVM is no more susceptible to crashes than BEAM. BTW, my point is that can now be a very good platform for Erlang/OTP. Its performance will allow Erlang/Elixir programs to reduce their reliance on native code and to handle higher loads.

It's my understanding the state of the art in observing JVM-based applications is a combination of using thread dumps, gc logs, thread activity visualizations. Thread dumps give us a snapshot of the the name of the thread, its current running state (waiting, blocked, etc), and the stacktrace of the work its currently doing. GC logs give you a record of when and how much garbage was collected and Thread activity visua…

> The BEAM gives you the ability to see the bottlenecks in your system, via the REPL (in real time!)

The JVM has done this forever via VisualVM and more recently via Flight Recorder and Mission Control.

Re: Erlang/OTP: Garbage Collector

#64

Post by nickpeterson »

throwawaymaths wrote: post #38
nickpeterson wrote: post #25

Earlier quoted context omitted.

As the other reply noted, I’d be shocked if it wouldn’t be much better now, seeing something like graal being used would be really interesting. I think if Elixir could target beam or jvm it would be an amazing language for many tasks.

> it would be an amazing language No, it wouldn't. Elixir is getting really fast computation through, e.g. nx, and the user story is incredible (OS install to stable diffusion in 40 minutes, most of which is dicking around figuring out how to install CUDA). Is it easy to run stable diffusion on jvm?

I think you might be taking my comment as implying the jvm is better than beam but that isn’t the argument I’m making. Having a strong jvm option means you can cut through a ton of corporate red tape. I don’t need to convince some skeptical CTO if the jvm is reasonable. It’s makes choosing elixir for a project feel about as hard a change as using clojure or groovy.

Re: Erlang/OTP: Garbage Collector

#65

Post by throwawaymaths »

nickpeterson wrote: post #64
throwawaymaths wrote: post #38

Earlier quoted context omitted.

> it would be an amazing language No, it wouldn't. Elixir is getting really fast computation through, e.g. nx, and the user story is incredible (OS install to stable diffusion in 40 minutes, most of which is dicking around figuring out how to install CUDA). Is it easy to run stable diffusion on jvm?

I think you might be taking my comment as implying the jvm is better than beam but that isn’t the argument I’m making. Having a strong jvm option means you can cut through a ton of corporate red tape. I don’t need to convince some skeptical CTO if the jvm is reasonable. It’s makes choosing elixir for a project feel about as hard a change as using clojure or groovy.

Yeah and not too many ctos would choose clojure or groovy either, and the ones that are, aren't oking it "because it's on the jvm".

Re: Erlang/OTP: Garbage Collector

#66

Post by weatherlight »

vips7L wrote: post #63
weatherlight wrote: post #61

Earlier quoted context omitted.

It's my understanding the state of the art in observing JVM-based applications is a combination of using thread dumps, gc logs, thread activity visualizations. Thread dumps give us a snapshot of the the name of the thread, its current running state (waiting, blocked, etc), and the stacktrace of the work its currently doing. GC logs give you a record of when and how much garbage was collected and Thread activity visua…

> The BEAM gives you the ability to see the bottlenecks in your system, via the REPL (in real time!) The JVM has done this forever via VisualVM and more recently via Flight Recorder and Mission Control.

In a repl, in a terminal, with no reliance on the OS, with just text. so no the JVM doesn’t do this. It’s not the same.

Re: Erlang/OTP: Garbage Collector

#67

Post by pron »

weatherlight wrote: post #61
pron wrote: post #58

Earlier quoted context omitted.

What do you mean by "the entire VM crashing"? The JVM is no more susceptible to crashes than BEAM. BTW, my point is that can now be a very good platform for Erlang/OTP. Its performance will allow Erlang/Elixir programs to reduce their reliance on native code and to handle higher loads.

It's my understanding the state of the art in observing JVM-based applications is a combination of using thread dumps, gc logs, thread activity visualizations. Thread dumps give us a snapshot of the the name of the thread, its current running state (waiting, blocked, etc), and the stacktrace of the work its currently doing. GC logs give you a record of when and how much garbage was collected and Thread activity visua…

You can do all that with the JDK, too, and at higher performance.

As an Erlang fan for many, many years, I am quite familiar with BEAM's design (and why I think Erlang would gain a lot by running on the JVM (or, more precisely, from implementing BEAM and OTP on top of the JVM). Aside from implementation details -- the JDK has simply had a lot more work put into it -- the main difference between the two is that BEAM is higher level, and the runtime itself does more things out of the box, while the JVM is lower level and you can do more in libraries (with no loss of performance, because Java is compiled to very efficient machine code).

Not only would Erlang and Elixir gain better performance and be able to reduce application's reliance on NIFs, but maintaining and evolving them would require less effort.

There is now (as of JDK 19, released six months ago) no capability offered by BEAM -- including runtime manipulation of code through a REPL -- that couldn't be implemented at least as efficiently as a library on top of the JDK. You can see the API here: https://docs.oracle.com/en/java/javase/20/docs/specs/jvmti.h...

Re: Erlang/OTP: Garbage Collector

#68

Post by pron »

weatherlight wrote: post #66
vips7L wrote: post #63

Earlier quoted context omitted.

> The BEAM gives you the ability to see the bottlenecks in your system, via the REPL (in real time!) The JVM has done this forever via VisualVM and more recently via Flight Recorder and Mission Control.

In a repl, in a terminal, with no reliance on the OS, with just text. so no the JVM doesn’t do this. It’s not the same.

You can write a library/tool that does exactly that, and the JVM offers an API precisely for that purpose. The reason such a tool isn't offered out of the box is that it trades off performance. For example, the JIT can optimise a variable or even an entire object away. When you want to inspect them at runtime, this would trigger a "deoptimization", where the representation would go back to the original bytecode from the optimised machine code. Observability that doesn't trigger deoptimization is, therefore, encouraged, but everything is available.

Re: Erlang/OTP: Garbage Collector

#69

Post by nickpeterson »

throwawaymaths wrote: post #65
nickpeterson wrote: post #64

Earlier quoted context omitted.

I think you might be taking my comment as implying the jvm is better than beam but that isn’t the argument I’m making. Having a strong jvm option means you can cut through a ton of corporate red tape. I don’t need to convince some skeptical CTO if the jvm is reasonable. It’s makes choosing elixir for a project feel about as hard a change as using clojure or groovy.

Yeah and not too many ctos would choose clojure or groovy either, and the ones that are, aren't oking it "because it's on the jvm".

I don’t think we’re going to reach an agreement. I believe languages running on the jvm helps give assurance to businesses. You disagree with that belief, we can leave it there.

Re: Erlang/OTP: Garbage Collector

#70

Post by vips7L »

weatherlight wrote: post #66
vips7L wrote: post #63

Earlier quoted context omitted.

> The BEAM gives you the ability to see the bottlenecks in your system, via the REPL (in real time!) The JVM has done this forever via VisualVM and more recently via Flight Recorder and Mission Control.

In a repl, in a terminal, with no reliance on the OS, with just text. so no the JVM doesn’t do this. It’s not the same.

You’re moving the goal post. The JVM does provide real time observability into your application.

Personally I think in a terminal with just text is inferior to a proper gui tool. If you really want this jcmd can convert jfr data into different formats that you then can script against.

Post reply on HN