<story><title>Elixir and Rust is a good mix</title><url>https://fly.io/phoenix-files/elixir-and-rust-is-a-good-mix/</url></story><parent_chain><item><author>RhodesianHunter</author><text>&amp;gt;Also, some of us are as anti-typing as you are pro-typing.&lt;p&gt;Assuming ample experience with both, how does one reach this conclusion?&lt;p&gt;I have yet to see a project of any size that needs to be worked on by multiple teams and is written in an untyped language not descend into dumpster fire.</text></item><item><author>toast0</author><text>Rust doesn&amp;#x27;t have a lot of good runtime introspection tools (or they&amp;#x27;re very not obvious). If you&amp;#x27;re running a system with a lot of concurrency, it&amp;#x27;s nice to be able to attach a debugger and find out exactly what&amp;#x27;s going on with each of your tasks.&lt;p&gt;I haven&amp;#x27;t seen hot loading for Rust (but a quick search shows there&amp;#x27;s some out there), and I&amp;#x27;m not sure how amenable Rust is to dlopen and friends to force the issue.&lt;p&gt;Erlang (and Elixir) have a constrained language that allows for BEAM to be effectively premptive in a way that a Rust concurrent runtime can&amp;#x27;t be. At every function call, BEAM checks if the process should be preempted, and because the only way to loop is recursion, a process &lt;i&gt;must&lt;/i&gt; call a function in a finite amount of time. A Rust runtime cannot preempt, if you need preemption, you&amp;#x27;ve got to use OS threads, which limits capacity, or you need to accept cooperative task switching.&lt;p&gt;Also, some of us are as anti-typing as you are pro-typing. :)</text></item><item><author>satvikpendem</author><text>I used to use Elixir, but the lack of static types got to me (especially since I prefer the type-driven development methodology). Using Rust afterwards was great, plus it was faster than the BEAM. I guess, why not use Rust entirely instead of as a FFI into Elixir or other backend language? I&amp;#x27;ve been using Axum and it works pretty well. The only time I had to do FFI with Rust was with Flutter via flutter_rust_bridge, for running a CRDT library (automerge) that was implemented in Rust, for offline app functionality.</text></item></parent_chain><comment><author>toast0</author><text>I work on a lot of &amp;#x27;glue&amp;#x27; issues, often with languages like Perl, PHP, and Erlang (and a bit of Javascript here and there). Specifying types all over the place in languages like C, C++, Java, and Rust feels like it gets in the way and limits more than it helps. (feelings more than data here, of course)&lt;p&gt;Sure, at boundaries between teams, you need to specify the data in some way. That could be a type, but for me, often the other team is using a different language than me, so it needs to be a language agnostic type, and it can&amp;#x27;t include unsigned numbers because Java can&amp;#x27;t cope, and it can&amp;#x27;t include large integers because Javascript can&amp;#x27;t cope, etc. Protobufs are popular, json is too.&lt;p&gt;I have a lot of unpopular opinions though, and that&amp;#x27;s fine. It&amp;#x27;s just tiresome that everyone wants to come in and add types to things that don&amp;#x27;t need them. Also, I agree with dllthomas, most developers and teams are capable of creating dumpster fires in all sorts of environments, with all sorts of tooling. :)</text></comment>
<story><title>Elixir and Rust is a good mix</title><url>https://fly.io/phoenix-files/elixir-and-rust-is-a-good-mix/</url></story><parent_chain><item><author>RhodesianHunter</author><text>&amp;gt;Also, some of us are as anti-typing as you are pro-typing.&lt;p&gt;Assuming ample experience with both, how does one reach this conclusion?&lt;p&gt;I have yet to see a project of any size that needs to be worked on by multiple teams and is written in an untyped language not descend into dumpster fire.</text></item><item><author>toast0</author><text>Rust doesn&amp;#x27;t have a lot of good runtime introspection tools (or they&amp;#x27;re very not obvious). If you&amp;#x27;re running a system with a lot of concurrency, it&amp;#x27;s nice to be able to attach a debugger and find out exactly what&amp;#x27;s going on with each of your tasks.&lt;p&gt;I haven&amp;#x27;t seen hot loading for Rust (but a quick search shows there&amp;#x27;s some out there), and I&amp;#x27;m not sure how amenable Rust is to dlopen and friends to force the issue.&lt;p&gt;Erlang (and Elixir) have a constrained language that allows for BEAM to be effectively premptive in a way that a Rust concurrent runtime can&amp;#x27;t be. At every function call, BEAM checks if the process should be preempted, and because the only way to loop is recursion, a process &lt;i&gt;must&lt;/i&gt; call a function in a finite amount of time. A Rust runtime cannot preempt, if you need preemption, you&amp;#x27;ve got to use OS threads, which limits capacity, or you need to accept cooperative task switching.&lt;p&gt;Also, some of us are as anti-typing as you are pro-typing. :)</text></item><item><author>satvikpendem</author><text>I used to use Elixir, but the lack of static types got to me (especially since I prefer the type-driven development methodology). Using Rust afterwards was great, plus it was faster than the BEAM. I guess, why not use Rust entirely instead of as a FFI into Elixir or other backend language? I&amp;#x27;ve been using Axum and it works pretty well. The only time I had to do FFI with Rust was with Flutter via flutter_rust_bridge, for running a CRDT library (automerge) that was implemented in Rust, for offline app functionality.</text></item></parent_chain><comment><author>fiddlerwoaroof</author><text>I tried Haskell for a while and switched to Common Lisp (although I still follow Haskell from a distance).  My experience just doesn&amp;#x27;t match up with the claim that a project of any size written in an untyped inevitably descends into a dumpster fire.  I&amp;#x27;ve worked on largish systems in several dynamically-typed languages and several statically-typed and I personally haven&amp;#x27;t noticed any major difference in overall productivity suggesting that static types are better: they just have different friction points and different ways of working work better in each paradigm.</text></comment>