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

71–79 of 79 posts

Re: Erlang/OTP: Garbage Collector

#71

Post by weatherlight »

vips7L wrote: post #70
weatherlight wrote: post #66

Earlier quoted context omitted.

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.

There's no goal post moving, that's a virtue of the VM.

a "Proper GUI tool" is not.

the BEAM is an OS, the JVM is not.

and as of matter of fact.

https://mrjoelkemp.medium.com/jvm-struggles-and-the-beam-4d9...

It's the actor model all the way down... that's the abstraction.

Simple systems, are easy to manage, complex systems are harder to manage, hence why you need a full blown GUIS to manage the JVM, because it does everything, and tries to satisfy every use case, so it has to handle every use case.

https://www.youtube.com/watch?v=SxdOUGdseq4

Re: Erlang/OTP: Garbage Collector

#72

Post by vips7L »

weatherlight wrote: post #71
vips7L wrote: post #70

Earlier quoted context omitted.

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.

There's no goal post moving, that's a virtue of the VM. a "Proper GUI tool" is not. the BEAM is an OS, the JVM is not. and as of matter of fact. https://mrjoelkemp.medium.com/jvm-struggles-and-the-beam-4d9... It's the actor model all the way down... that's the abstraction. Simple systems, are easy to manage, complex systems are harder to manage, hence why you need a full blown GUIS to manage the JVM, because it does…

It is a goal post move. You went from "Beam provides real time observability" to "real time observability is only in a terminal with a repl" when provided with facts that the JVM also provides real time observability.

> a "Proper GUI tool" is not.

I don't know what this means.

> hence why you need a full blown GUIS to manage the JVM,

Did you read the post you linked? The author required a GUI written by someone else.

I don't know what point you're trying to make anymore, you're just spitting out random sentences, that don't have to do with anything I was replying to (real time obserability).

You have some extreme bias. Cheers mate.

Re: Erlang/OTP: Garbage Collector

#73

Post by weatherlight »

vips7L wrote: post #70
weatherlight wrote: post #66

Earlier quoted context omitted.

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.

Is the GUI apart of the VM? It is not.

Re: Erlang/OTP: Garbage Collector

#74

Post by pron »

weatherlight wrote: post #71
vips7L wrote: post #70

Earlier quoted context omitted.

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.

There's no goal post moving, that's a virtue of the VM. a "Proper GUI tool" is not. the BEAM is an OS, the JVM is not. and as of matter of fact. https://mrjoelkemp.medium.com/jvm-struggles-and-the-beam-4d9... It's the actor model all the way down... that's the abstraction. Simple systems, are easy to manage, complex systems are harder to manage, hence why you need a full blown GUIS to manage the JVM, because it does…

The author of the article you linked is about a decade out of date. "The state of the art in observing your JVM-based applications is a combination of using thread dumps, gc logs, thread activity visualizations." -- that has been untrue for quite some years now. The basic observability offered by the JDK is now the Flight Recorder, a low-overhead in-production tracing and profiling engine that BEAM is many years away from being able to achieve.

The JVM supports all the same runtime observation and manipulation as BEAM. If you want to use them via a shell -- you may. If you want to use the actor model "all the way down" you can do it. The JVM is simply a virtual machine at a lower level than BEAM, but it does provide all the primitives the Erlang model needs.

The reason I'm telling you this is that I think that targeting the JVM would allow Erlang/Elixir to evolve faster -- enjoying the low-level work done by the large OpenJDK team -- as well as reach a wider audience. At the same time, the wider Java platform community will be exposed to all the great ideas that have come out of Erlang. All the necessary foundational work is now, finally (as of JDK 19), in place.

Re: Erlang/OTP: Garbage Collector

#75

Post by pron »

weatherlight wrote: post #60
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.

The JVM has 9 9s of reliability? Citation needed please.

I don't know what that means. The JVM itself is at least as reliable as BEAM, and probably more so -- it's subject to both more development testing and field testing -- but what needs high reliability is applications. The JVM runs much more critical code than BEAM does, and on a far wider scale and more stressful workloads. The VM itself is the cause of neither Java's reliability nor Erlang's. It's the programming model that matters. The JVM can now support the Erlang model at least as well -- and, I claim, significantly better -- than BEAM ever could with its limited resources. BEAM's Achilles heel has always been performance. That has harmed Erlang application's reliability, as they need to depend on unsafe native code -- that can crash the entire process -- much more than JVM applications.

Re: Erlang/OTP: Garbage Collector

#76

Post by hissssst »

pron wrote: post #75
weatherlight wrote: post #60

Earlier quoted context omitted.

The JVM has 9 9s of reliability? Citation needed please.

I don't know what that means. The JVM itself is at least as reliable as BEAM, and probably more so -- it's subject to both more development testing and field testing -- but what needs high reliability is applications . The JVM runs much more critical code than BEAM does, and on a far wider scale and more stressful workloads. The VM itself is the cause of neither Java's reliability nor Erlang's. It's the programming m…

> The VM itself is the cause of neither Java's reliability nor Erlang's. It's the programming model that matters. The JVM can now support the Erlang model

That's a common misconception. There is a huge practical difference between "being able to write share-nothing" and "having whole ecosystem built around it". While you're referring to Erlang running unsafe native code, you're completely ignoring the Java running unsafe Java code. To ensure guarantees like "share nothing" or "restartable processes" Erlang developer just needs to write only Erlang and Java developer needs to carefully pick every dependency and almost always rewrite some of them.

That's the exact reason why Akka didn't replace OTP: you're most likely using the dependency which is not written with Akka, and it might share mutable memory, use global mutable state etc. So, even with possibility of writing Erlang-like software, you most certainly will end up with Frankenstein where some parts are fault tolerant, immutable, functional and reasonable, and some parts are oldschool java 8 bullshit.

Do you know what is the definition of DSL? It is when you write your code in one language and get exception in another. And that's exactly why almost every JVM language (except Java) is a DSL.

You just can't have guarantees Erlang has without rewriting everything with your Akka of the day.

Re: Erlang/OTP: Garbage Collector

#77

Post by pron »

hissssst wrote: post #76
pron wrote: post #75

Earlier quoted context omitted.

I don't know what that means. The JVM itself is at least as reliable as BEAM, and probably more so -- it's subject to both more development testing and field testing -- but what needs high reliability is applications . The JVM runs much more critical code than BEAM does, and on a far wider scale and more stressful workloads. The VM itself is the cause of neither Java's reliability nor Erlang's. It's the programming m…

> The VM itself is the cause of neither Java's reliability nor Erlang's. It's the programming model that matters. The JVM can now support the Erlang model That's a common misconception. There is a huge practical difference between "being able to write share-nothing" and "having whole ecosystem built around it". While you're referring to Erlang running unsafe native code, you're completely ignoring the Java running un…

I think you misunderstood my point. I wasn't trying to argue for Java over Erlang. The people writing Java will continue writing Java, and people writing Erlang will continue doing that.

I was merely pointing out that at this point, the JVM offers a great platform for Erlang itself, which could both increase its visibility and give it a technological boost. You could have everything be Erlang, top to bottom, with far better performance than BEAM could ever achieve, less work, and better interop with where a lot of people actually are.

There could be some disadvantages but overall I think it would be a great opportunity, and one that Erlang could really use.

> And that's exactly why almost every JVM language (except Java) is a DSL.

Other JVM languages choose to have "exceptions in Java" because it's so much less work for them to use existing libraries and they consider it a small enough price to pay. But even if you want virtually all of it to be Erlang, it would still be less work than BEAM.

You could even control exceptions and stack traces, as that's programmable:

https://docs.oracle.com/en/java/javase/20/docs/api/java.base..., https://docs.oracle.com/en/java/javase/20/docs/api/java.base...()

Re: Erlang/OTP: Garbage Collector

#78

Post by weatherlight »

pron wrote: post #54
bitwalker wrote: post #52

Earlier quoted context omitted.

The BEAM is so much more than just a green thread runtime - and it is not straightforward at all to just "bring it over" to another virtual machine, the entire BEAM VM is designed around the scheduler, and core features such as signals (used most notably for links/monitors, but also for a number of other system features) and messaging, are deeply integrated with the scheduler; as are system tasks, execution of NIFs (…

I am well familiar with BEAM, and my fascination with it ~20 years ago was one of the things that inspired me to become a VM engineer. Bringing that over to the JDK was, indeed, a large effort, but we are a large, well-funded team.

The guy you are responding to is an Erlang VM engineer, just sayin'

Re: Erlang/OTP: Garbage Collector

#79

Post by pron »

weatherlight wrote: post #78
pron wrote: post #54

Earlier quoted context omitted.

I am well familiar with BEAM, and my fascination with it ~20 years ago was one of the things that inspired me to become a VM engineer. Bringing that over to the JDK was, indeed, a large effort, but we are a large, well-funded team.

The guy you are responding to is an Erlang VM engineer, just sayin'

And, as a JDK engineer with Erlang experience, I'm just sayin' that as of the past six months, the JDK has all the primitive building blocks required for a very efficient Erlang runtime. Even the thread scheduler is not built into the JVM but written in Java, and will soon be made completely pluggable. Any scheduling algorithm that Erlang wishes to employ can be provided as a library on top of the JVM. If I've missed anything, we'll consider adding it.

It's been a dream of mine to port BEAM to the JDK to give Erlang much better performance and greater visibility. Unfortunately, this work can't be funded as there's insufficient demand for Erlang. If the Erlang community does it, however, it could increase its evolution velocity, improve performance, and give it higher visibility.

Post reply on HN