91–100 of 125 posts
Having worked with erlang for some time now, https://www.erlang.org/eeps/eep-0049 is _very exciting_ to me. One of the issues that I have with the codebase that I'm in is deep nesting, which could be solved with this feature. Very compelling. (HN mods: feel free to delete this comment or my comment at https://news.ycombinator.com/item?id=31426002 , since they're the same content)
This is great. I hope this finds its way to Elixir land.
Earlier quoted context omitted.
My thinking is Erlang’s been powering massive systems since the early 90s, I’m feeling pretty good about its longevity. Many of Elixir’s strengths are Erlang’s strengths. I wouldn’t hesitate to learn some Elixir if it’s interesting to you. It’s not as pervasive as other languages but it’s not niche either. Full disclosure, it’s been such a wild success for my team at New Relic the last 5 years that I’m very biased :)
New Relic is using Elixir?
Earlier quoted context omitted.
I know there's a lot of power there. Whatsapp was written in OTP and had something like half the world using it with a development team of maybe 12. I'm glad to hear the community is bigger than what I found. I don't actually remember that search process. What I remember clearest was running into the brick wall of the OTP documentation.
If you'd want to try again, I can recommend "Elixir in Action" [1]. It has a great introduction to the basics of OTP later on in the book. I understood it much better after reading that book that any other materials. While the book is about Elixir (which is a BEAM language) the underlying OTP principles are the same. The book covers "basic" OTP before moving on to some abstractions that Elixir provides. [1] https://w…
I've seen more than once recently an engineer saying that software solutions outside of the Serverless ecosystem (FaaS, DB, etc) is "the new legacy". And that cloud providers have solved all the pains that Erlang was supposed to address. What's your feeling on this? Elixir sounds very compelling to me, but I worry that I might be going in a direction that's not where the industry is going.
* The JIT now works for 64-bit ARM processors, including M1 * The JIT now does type-based optimizations based on type information in the BEAM files.
Also great if you have the option of deploying on AWS Graviton or similar.
Earlier quoted context omitted.
Serverless systems in almost every implementation are still stateless or limited stateful-serverless (the best examples are probably Microsoft's Durable Functions or Flink's Stateful Functions - there's also solid attempts by the Akka folks). These are largely built on top of either a stream processing (in case of Flink) or some flavor of Actor model based on event sourcing for peristence. What I'm getting at is that…
This is one of the best answer. Also: - the supervisor system in Erlang/Elixir is relatively complex. It goes much beyond the "restart my service" when it crashes but allow to restart some processes, without restarting the service, and in a specific order to keep the system coherent. - local and remote calls behave the same in Erlang/Elixir, allowing to start with a monorepo having different Erlang "apps" than run on…
This sounds very appealing to my context.
Earlier quoted context omitted.
Serverless systems in almost every implementation are still stateless or limited stateful-serverless (the best examples are probably Microsoft's Durable Functions or Flink's Stateful Functions - there's also solid attempts by the Akka folks). These are largely built on top of either a stream processing (in case of Flink) or some flavor of Actor model based on event sourcing for peristence. What I'm getting at is that…
This is one of the best answer. Also: - the supervisor system in Erlang/Elixir is relatively complex. It goes much beyond the "restart my service" when it crashes but allow to restart some processes, without restarting the service, and in a specific order to keep the system coherent. - local and remote calls behave the same in Erlang/Elixir, allowing to start with a monorepo having different Erlang "apps" than run on…
I wouldn't really say they behave the same. They have the same interface, so it doesn't take much to send to a remote node vs the local node, but there are a lot of details in the behavior that are clearly different, as is the nature of the beast. With a local process, if you monitor it, and receive a kill signal, you know it's dead; with a remote process, you may get a process died signal or a connection died signal; if the connection died you can't know if the remote process is dead or alive. That's new behavior and can be tricky sometimes.
Earlier quoted context omitted.
This is one of the best answer. Also: - the supervisor system in Erlang/Elixir is relatively complex. It goes much beyond the "restart my service" when it crashes but allow to restart some processes, without restarting the service, and in a specific order to keep the system coherent. - local and remote calls behave the same in Erlang/Elixir, allowing to start with a monorepo having different Erlang "apps" than run on…
> - local and remote calls behave the same in Erlang/Elixir, allowing to start with a monorepo having different Erlang "apps" than run on the same node, but then running the different apps on different nodes in the future, once the application, scales. This can be done very little changes to the application. I wouldn't really say they behave the same. They have the same interface, so it doesn't take much to send to a…
Have there been benchmarks of the JIT vs say JS or the JVM?
Erlang JIT takes BEAM bytecode and turns it into native code once at load time in order to avoid the overhead of the threaded code interpreter; if Erlang JIT is enabled, the interpreter is not used at all. Java's HotSpot JIT takes JVM bytecode and turns it into native code at runtime in order to improve performance of code that is run frequently (thus the name), guided by runtime information; lightly used code will be interpreted, heavily used code will hopefully be JITed to native. When HotSpot JITs, it may apply assumptions based on runtime use to produce faster code and if the assumptions don't hold for a call, the interpreter can be used instead (and if that happens often enough, the native code can be discarded and perhaps rebuilt), so the interpreter needs to be present always.
Erlang JIT has been focused more on always applying and speed of application (because it delays code loading), whereas HotSpot focuses more on getting performance gains when it applies, and speed of application is less important because it happens asynchronously. So if you benchmarked speed of applying the JIT, Erlang would probably win, and if you benchmarked optimization of the code, HotSpot would probably win, but either way you're comparing apples and oranges.
Having worked with erlang for some time now, https://www.erlang.org/eeps/eep-0049 is _very exciting_ to me. One of the issues that I have with the codebase that I'm in is deep nesting, which could be solved with this feature. Very compelling. (HN mods: feel free to delete this comment or my comment at https://news.ycombinator.com/item?id=31426002 , since they're the same content)
This is great. I hope this finds its way to Elixir land.