Live data from Hacker News

Elixir and Rust is a good mix

fly.io

51–60 of 165 posts

Re: Elixir and Rust is a good mix

#51
post #25

Earlier quoted context omitted.

Rust doesn't have a lot of good runtime introspection tools (or they're very not obvious). If you're running a system with a lot of concurrency, it's nice to be able to attach a debugger and find out exactly what's going on with each of your tasks. I haven't seen hot loading for Rust (but a quick search shows there's some out there), and I'm not sure how amenable Rust is to dlopen and friends to force the issue. Erla…

>Also, some of us are as anti-typing as you are pro-typing. Assuming ample experience with both, how does one reach this conclusion? 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.

I tried Haskell for a while and switched to Common Lisp (although I still follow Haskell from a distance). My experience just doesn't match up with the claim that a project of any size written in an untyped inevitably descends into a dumpster fire. I've worked on largish systems in several dynamically-typed languages and several statically-typed and I personally haven'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.

Re: Elixir and Rust is a good mix

#52

Earlier quoted context omitted.

>Also, some of us are as anti-typing as you are pro-typing. Assuming ample experience with both, how does one reach this conclusion? 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.

While I'm pretty solidly in the "pro-typing" camp, it seems worth acknowledging that such projects often turn into dumpster fires in typed languages as well, even expressively typed languages.

Maybe, maybe not - but in my experience, a dumpster fire with static types is easier to read and understand and also easier to refactor.

Re: Elixir and Rust is a good mix

#53

Earlier quoted context omitted.

While I'm pretty solidly in the "pro-typing" camp, it seems worth acknowledging that such projects often turn into dumpster fires in typed languages as well, even expressively typed languages.

Maybe, maybe not - but in my experience, a dumpster fire with static types is easier to read and understand and also easier to refactor.

That matches my experience as well. I just think we need to be resistant to reading too much into "I've seen bad code that X", because that can easily be true of almost any X.

Re: Elixir and Rust is a good mix

#54

Earlier quoted context omitted.

>Also, some of us are as anti-typing as you are pro-typing. Assuming ample experience with both, how does one reach this conclusion? 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.

I tried Haskell for a while and switched to Common Lisp (although I still follow Haskell from a distance). My experience just doesn't match up with the claim that a project of any size written in an untyped inevitably descends into a dumpster fire. I've worked on largish systems in several dynamically-typed languages and several statically-typed and I personally haven't noticed any major difference in overall product…

The issue isn't productivity. As far as just slamming out code untyped languages are undeniably faster.

The issue is working on projects once they've reached a certain size where you have no idea what the intent of the original author was and you maybe need to refactor, add-in major pieces, or change anything with the expectation that it continues to work.

Re: Elixir and Rust is a good mix

#55

Earlier quoted context omitted.

>Also, some of us are as anti-typing as you are pro-typing. Assuming ample experience with both, how does one reach this conclusion? 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.

>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. Github? Dropbox? I mean they both eventually went to type hints in their respective languages or migrated to a typed language but for a long time I'm certain it wasn't.

And I can pretty much guarantee you that some form of dumpster, fire or other was the driving factor behind those moves.

Re: Elixir and Rust is a good mix

#56
post #45

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'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,…

> 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? Sure, you just need to reimplement light-weight threading with preemptive scheduling prioritizing latency over throughput, extremely robust fault tolerance with a supervision hierarchy, and runtime introspection with code hotloading capabilities. Maybe you…

Is any of this needed though? For some use cases yes, but for many no. It's possible the parent has no practical use for these capabilities.

Re: Elixir and Rust is a good mix

#57
post #45

Earlier quoted context omitted.

> 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? Sure, you just need to reimplement light-weight threading with preemptive scheduling prioritizing latency over throughput, extremely robust fault tolerance with a supervision hierarchy, and runtime introspection with code hotloading capabilities. Maybe you…

Is any of this needed though? For some use cases yes, but for many no. It's possible the parent has no practical use for these capabilities.

[deleted]

Re: Elixir and Rust is a good mix

#58
post #44

Earlier quoted context omitted.

>Also, some of us are as anti-typing as you are pro-typing. Assuming ample experience with both, how does one reach this conclusion? 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.

I work on a lot of 'glue' 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) Sure, at boundaries between teams, you need to specify the data in some way. That could be a type, but for me, often…

You can absolutely create a dumpster fire in any language.

Putting the fire out in an untyped language is a Herculean effort.

Re: Elixir and Rust is a good mix

#59
post #44

Earlier quoted context omitted.

I work on a lot of 'glue' 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) Sure, at boundaries between teams, you need to specify the data in some way. That could be a type, but for me, often…

You can absolutely create a dumpster fire in any language. Putting the fire out in an untyped language is a Herculean effort.

In my experience it is even harder in a typed one because now you have to deal with the type system nightmare they built. So the compiler fight your refactoring.

Re: Elixir and Rust is a good mix

#60
post #45

Earlier quoted context omitted.

> 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? Sure, you just need to reimplement light-weight threading with preemptive scheduling prioritizing latency over throughput, extremely robust fault tolerance with a supervision hierarchy, and runtime introspection with code hotloading capabilities. Maybe you…

Is any of this needed though? For some use cases yes, but for many no. It's possible the parent has no practical use for these capabilities.

[flagged]
Post reply on HN