Will it be possible to compile gleam into native code? what is the difference between jwm and beam? what are the pros and cons? RAM, processor, fault tolerance, etc.
@@lpil and directly into the beam code and how much better will it be? What's the point of having a strongly typed language if it still compiles into dynastic erlang?
@@olekollo7875 compiling directly to BEAM bytecode would mean sacrificing all the optimisations of the 40 year mature Erlang compiler, so Gleam applications would run slower. Worse the bytecode is not a stable target and evolves over time as the VM is improved, so there would be a sizeable ongoing maintenance cost. Additionally the compiler would be significantly more complicated, and harder for newcomers to work with. It’s best we compile to Erlang, just like Elixir, LFE, etc do. There would be no particular advantage of compiling to bytecode relating to types.
@@lpil If you compile in Erlang, do types play a role? that is, what are the advantages of a strictly typed gleam over a dynamic elixir, besides making it easier to catch errors at the development stage?
@@olekollo7875 Yes, we use type information when generating code to do things we would not be able to do otherwise, or that would have a runtime cost to do. There's lots of reasons you might prefer the style of programming offered by Gleam, but it's down to each programmer to decide what they prefer and why. Personally I really enjoy the simplicity of Gleam and how easy it is to understand Gleam code, as well as how much easier it is to refactor Gleam code.
