Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elixir and Rust is a good mix

fly.io

Post reply on HN
Print view View original

111–120 of 165 posts

Re: Elixir and Rust is a good mix

#111

Post by bcrosby95 »

ReflectedImage wrote: post #82
RhodesianHunter wrote: post #54

Earlier quoted context omitted.

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.

Untyped code bases with microservices are the best code bases out there by far. They are exceptionally easy to refactor, add-in new parts, etc. The keyword is microservices, you need to know how to do proper microservices if you are using untyped code.

I dunno. Something like spec, dialyzer, or "assertive" typing (in the case of Elixir) on the boundary works just fine for me.

Re: Elixir and Rust is a good mix

#112

Post by sodapopcan »

josephg wrote: post #108
freedomben wrote: post #92

Earlier quoted context omitted.

Test coverage is, in my experience, much more important factor than typing. A codebase with great testing is much easier to aggressively refactor/change whether typed or not. That said, a dumpster fire usually has no or little tests, so maybe we're arguing non-existent hypotheticals :|

I’ve gone back and forth over the years on whether tests are a good enough replacement for types. A few thoughts: - Types and tests find different bugs . I’ve found new bugs by converting a project from javascript to typescript. The project in question had a 2:1 test:code ratio but as soon as the typescript compiler could read it, it spotted a couple obvious errors. - Large test suites often make refactoring harder,…

> If you have a clear, fixed API boundary and your tests test that boundary, then testing helps.

A clear, fixed API boundary is exactly what Phoenix tries to encourage with contexts. Unfortunately, a lot of developers find them hard to understand. They're simple if you read up on DDD but again, a whole host of developers won't, or don't, do that either. LiveView in particular has a really a really great testing library [0] where you can write what are essentially end-to-ends that never touch even a headless browser. Since I'm always writing LiveViews, I pretty much only write LiveView tests and contexts tests which gives me large coverage (also some unit tests for the odd utility function). Otherwise, it's really important when writing non-typed functions to make it really obvious what is coming in and out, which is arguably a nice forcing factor.

The number one thing people bring up when shilling types is large codebases (it's been brought up in these comments). My opinion there I have found is quite unpopular and that is that pair programming should be far more prevalent than it is. I think the whole notion of "just stick a junior on that" is broken and I don't understand how types make that situation _that_ much better.

All said and done, I'm not actually anti-type. I mostly just find them to be incredibly noisy compared to a well-written function. I really like Ocaml where it's statically typed without needing to actually specify them.

Re: Elixir and Rust is a good mix

#113

Post by bPspGiJT8Y »

OkayPhysicist wrote: post #88
vlunkr wrote: post #48

Earlier quoted context omitted.

I'm in the same boat with Elixir. I love many aspects of the language, but it borrows the fast-and-loose type ecosystem of ruby. nil is an especially big problem. Any value could be nil, and this will absolutely bite you over and over. nil even allows you to use square brackets for some reason (some_nil_value[:some_key]) which is a great way to disguise the actual issue. There is optional type checking with Dialyzer,…

I disagree. Any value could be nil, but any value could be 5, too. In fact, nil is just like any other atom. Elixir shines when you lean on pattern matching as much as possible. Your functions should unpack as much as possible within the function definition, frankly the "if" macro is completely superfluous to case and in rare cases cond. You'll find that you match the data you want, and thus reject anything else. Squ…

Any errors these techniques could catch would have to happen during runtime, not at compile time, and this is a huge and key difference. In my experience having the type errors being caught at compile time is an incredible boost to productivity. I just write code then hit Ctrl+S and the compiler tells me what I got wrong, instead of all the hassle of having to write functions a line at a time, flip to IEx, run, inspect some intermediary value to make sure it works as intended, while trying to keep so many things in my head at once, which at times can be just overwhelming and highly frustrating.

Re: Elixir and Rust is a good mix

#114

Post by giancarlostoro »

dxhdr wrote: post #45
satvikpendem wrote: post #7

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…

Implementing all of that, without using a significant amount of memory for every step of the way to boot. It's impressive how little memory an Erlang process needs.

Re: Elixir and Rust is a good mix

#115

Post by MuffinFlavored »

mrmincent wrote: post #79

I made the ‘risky’ decision to learn Elixir & Phoenix for a 6 week University project that I delivered earlier this week. It could have turned out to be a terrible decision but honestly once I got my head around it, it’s probably some of the most productive coding sessions I’ve ever had. Deploying to Fly.io was also amazing, I think it was 3-5 commands from signup to deployed with a database. Very happy with it all.

terraform init && terraform apply is 2 commands!

slightly /s

kubectl apply is 1 command!

ansible-playbook is 1 command!

sh ./do-the-thing.sh

you get it

Re: Elixir and Rust is a good mix

#116

Post by calo_star »

dist1ll wrote: post #106
dxhdr wrote: 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…

> light-weight threading with preemptive scheduling prioritizing latency over throughput Tasks for backend systems are usually pretty homogeneous. I'm not sure how in such cases the overhead of preemption is in any way better than cooperative multitasking.

Erlang processes indeed do cooperative multitasking under the hood, something like yielding control to the scheduler roughly every 1000 function calls.

Re: Elixir and Rust is a good mix

#117

Post by dllthomas »

3836293648 wrote: post #107
dllthomas wrote: post #39

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.

Sure, but they don't turn into dumpster fires because of the types, as untyped projects tend to do

I don't know that that's true. When the types in a program are designed in a way that's sufficiently out of sync with what a program needs to do, you can get a lot of mess working around them.

Can we say that's misuse of the tools? Sure. Is it less likely than things becoming a mess without types? Probably? Even more so as the tools improve and as the people involved know better how to use them.

Re: Elixir and Rust is a good mix

#118

Post by travisgriggs »

fiddlerwoaroof wrote: post #51
RhodesianHunter wrote: post #32

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…

This is exactly my experience as well. Code architecture, metaphors, tests, etc have had larger impacts on both initial development as well as long term maintenance and malleability.

Some times, some type systems actually make people jump through hoops to accommodate their design and then it can actually have a negative effect. Other times, the typing helps.

It’s kind of like really good grammar and punctuation. They can make a story you write better and clearer. But they far from guarantee it. You can write a very good story with subpar grammar/punctuation. And you can write a really lame story that is grammar perfect.

One thing that I haven’t seen much in the discussion, is any discussion about Elixir’s matching abilities. Does Rust have that as well? I love what Elixir matching does for my code.

(Edited spelling)

Re: Elixir and Rust is a good mix

#119

Post by valenterry »

dxhdr wrote: post #45
satvikpendem wrote: post #7

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…

I'm not a Rust programmer, but:

> light-weight threading with preemptive scheduling prioritizing latency over throughput

Rust has Tokio for light-weight threading which might well be sufficient for the majority of use-cases.

> extremely robust fault tolerance with a supervision hierarchy

One could argue that Rusts compile-time guarantees together with something like the Result-type make it so that such a supervision hierarchy isn't quite necessary and a few "manually implemented" error-boundaries are sufficient. This is also true for errors like network-hickups.

> runtime introspection with code hotloading capabilities. Maybe you could add frictionless distributed system support as well

Fair enough points.

I don't think your attitude against the OP is justified though.

Re: Elixir and Rust is a good mix

#120

Post by valenterry »

toast0 wrote: post #44
RhodesianHunter wrote: post #32

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…

I think that glue-issues are especially well captured by languages with good static type-system. Moreso than in languages without static types, because when it comes to glueing, there are many things, especially errors, to consider that can easily be forgotten without the help of a compiler.

However, a language with an insufficient type-system indeed makes things harder than they are without it. I would count all the languages you listed into this category.

As another poster mentioned, typescript is fairly expressive. There are other (production) languages too, such as Scala or maybe D. And there are lots of academic/very-niche languages.

> It's just tiresome that everyone wants to come in and add types to things that don't need them

Well, types are there, if you like them or not. There's a reason that you have e.g. typeof in javascript, gettype in PHP. The question is rather if you explicitly annotate them or not. But yeah, sometimes it's not helpful to annotate types, especially if the language is incapable of expressing the correct type anyways, which is true for most programming languages.

Post reply on HN