kennethL
HiPE is the runtime and compiler support for native code generation of Erlang modules that some of you might have tried, it is part of the OTP repository today.
The OTP team is planning to remove HiPE in the OTP 24 release for the following reasons:
- we plan to introduce a new way of executing Erlang, the “JIT” described by Lukas Larsson at Code Beam V
- since OTP 22, HiPE is not fully functional (does not handle all beam instructions and combinations)
- there is no use of HiPE among our primary customers. We actually don’t know where HiPE is used except for speeding up Dialyzer which we have another solution for.
- The current support for HiPE in the code is a blocker or creates extra work in our new development.
In order to not remove HiPE in OTP 24, we really soon need maintainers committing (long term) to keep HiPE in shape and up to date with the rest of OTP.
Where Next?
Trending in Erlang News
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Bringing learning, work and compliance together since 1987.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #elixirconf-eu
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Master modern tools, write cleaner code, and tackle real-world challenges.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 6- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
hauleth
I have posted it in the similar time as you as I wasn’t sure if you are there as well. I have removed my post.
Personally - as long as there will be alternative way to have more performance out of Erlang like JIT backed by for example LLVM (I haven’t seen @garazdawi presentation yet) - I am ok with that, and keeping such complex codebase is not worth keeping HiPE.
kennethL
The new way of executing Erlang presented by Lukas is not dependent on LLVM at all, which is very nice.
kennethL
Well exactly how it works is not presented by Lukas only announced to be presented in September
christhekeele
For those interested, I believe this is the video under discussion
dimitarvp
I am quite interested to see what you guys come up with. I personally don’t think being dependent on LLVM is a bad thing per se but let’s see what your solution looks like!
StevenNunez
https://www.youtube.com/watch?v=lM7UV95Rpyo&feature=emb_title here’s an update on the JIT stuff.