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

151–160 of 165 posts

Re: Elixir and Rust is a good mix

#151

Post by packetlost »

halostatue wrote: post #146
packetlost wrote: post #69

Earlier quoted context omitted.

You never actually get away from types, they are a core requirement of using any data beyond raw bytes. The guarantees that a strong type system provide mean you can be certain about certain things before your program even runs. If that's a problem for you, you're likely just leaving bugs on the table to be discovered at runtime.

I’d modify your statement to say "strong, static type system". Strong and weak typing are orthogonal to dynamic and static typing. JavaScript has weak dynamic typing; TypeScript has strong-ish static typing sitting on weak dynamic typing. Ruby and Erlang/Elixir have strong dynamic typing. Rust and Go strong static typing (Go’s is weakened by interface{}, IMO, but it’s a valid choice). With the way that Erlang and Eli…

I'll admit, I do not know Elixir very well. As long as it's checked at compile-time or checked across an entire application at startup/import/init, I think it serves the purpose well. The problems I want to avoid is discovery at (production) runtime the shape of data doesn't match what my functions expected.

Re: Elixir and Rust is a good mix

#152

Post by medo-bear »

shrimp_emoji wrote: post #141
medo-bear wrote: post #139

Earlier quoted context omitted.

sure but not in a sense that rust is. my point is that it is entirely possible to build good software with substantial code bases in dynamically typed languges and i used common lisp as an example. in fact i dont know of one common lisp code base that turned to a dumpster fire because of typing problems. instead i find the opposite true: old forgotten code can often be resurrected because the language promotes clear…

Lisp is not Python or JS. People use Python and JS, not Lisp. Dynamic typing in Python and JS + medium-sized project = dumpster fire.

there are plenty of disaster code bases in both dynamic and static typed languages. my cause for mentioning common lisp was use of an example i personally know of where a dynamic language (albeit one with strong and static typing support available) produces some really high quality code that can stand the test of time

Re: Elixir and Rust is a good mix

#153

Post by zinclozenge »

sph wrote: post #77
zinclozenge wrote: post #66

Earlier quoted context omitted.

> That's very common when you don't know DBs. I'm not a 20 year DBA greybeard veteran, but I'm comfortable enough to write schemas and queries by hand without any issue, and the entire time I wished I could do just that instead of using Ecto.

No one stops you from writing raw SQL with Ecto. But good luck creating composable SQL with raw string interpolation, which Ecto excels at.

PR reviewers stopped me from writing raw SQL.

Re: Elixir and Rust is a good mix

#154

Post by malkosta »

zinclozenge wrote: post #66
malkosta wrote: post #31

Earlier quoted context omitted.

> Ecto as the main way of interacting with the database was a miserable experience That's very common when you don't know DBs. But DB savy developers usually claim the opposite, because the syntax is more familiar.

> That's very common when you don't know DBs. I'm not a 20 year DBA greybeard veteran, but I'm comfortable enough to write schemas and queries by hand without any issue, and the entire time I wished I could do just that instead of using Ecto.

Ecto queries are much closer to DB queries, when you use the macro syntax.

But if you come from an ORM perspective and expect the same experience on Ecto, yes I agree it won't please you.

Re: Elixir and Rust is a good mix

#155

Post by sodapopcan »

josephg wrote: post #128
sodapopcan wrote: post #112

Earlier quoted context omitted.

> 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 libra…

> 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. Yeah; I haven't worked with ocaml but I've done some haskell (where you think about types so much more ). Personally I don't mind rust / typescript's approach of needing types at the function boundary (function input & output types must be spec…

> I've done some haskell (where you think about types so much more)

You definitely still think about types in Ocaml, you just don't need to annotate due to the language design. A big part of what makes it possible is that there are no overloaded operators, eg, you can't add an int and a float without casting as the mathematical operators are different: `1 + 1` v. `1.0 +. 1.0`. While I've dabbled in both, I'm no expert in either Ocaml or Haskell, though.

Really for me it's just that I've never felt the pain as I haven't worked in a big enough project, I guess. There is something that just kind of annoys me about (pseudocode): `(name : string) :: string -> "Hi, #{name}"` because, like, no shit it takes a string and returns a string! It's a death by a thousand cuts thing where I don't want to read that stuff and the compiler doesn't need to be explicitly told that in order to do static analysis.

Anyway, again it's really not the end of the world as I'm not anti-type. I just don't yearn for them in Elixir or anything. If it had a solid typing system I even might use it, but I don't yearn for them or anything.

You have some really interesting projects on your github, though! I mostly build glorified CRUD web apps! I do always get a sense that a lot of the type-talk is centred around organization disorganization.

Re: Elixir and Rust is a good mix

#156

Post by lispm »

medo-bear wrote: post #139
lispm wrote: post #123

Earlier quoted context omitted.

Maybe because the language is not untyped? It has both dynamic typing and optional static typing.

sure but not in a sense that rust is. my point is that it is entirely possible to build good software with substantial code bases in dynamically typed languges and i used common lisp as an example. in fact i dont know of one common lisp code base that turned to a dumpster fire because of typing problems. instead i find the opposite true: old forgotten code can often be resurrected because the language promotes clear…

This interactive introspection is usually facilitated by dynamic types and actual types in the software. For example large parts of the Lisp software in the 80s were already written in an object-oriented way, where the code was structured around explicit classes. Means: one sees the classes/methods both in the source code and in the running code. The source is far from 'untyped'.

For example the Filesystem Browser (FSEdit) from 1980 was written in Flavors. It actually uses an explicit OOP system with hierarchical classes.

https://tumbleweed.nu/r/attic/sys78/file?name=lmfs/fsedit.li...

Re: Elixir and Rust is a good mix

#157

Post by valenterry »

halostatue wrote: post #145
valenterry wrote: post #135

Earlier quoted context omitted.

> it’s not like Haskell programs are suddenly without fault I never said that. But would you claim that Haskell programs are generally more faulty / less stable than Erlang programs? > Just because you have a Result type doesn’t mean you actually properly/meaningfully handle the error at all Okay, but the same is true for Erlang and the BEAM. > it may just happen that “restart” is the correct solution Yeah, but is ve…

> > Also, Rust is not safe from dead/live locks and many other concurrency issues, only data race free. > How is Erlang safe from those things in a way that cannot or only with a lot of effort be replicated when using Rust? Each BEAM process (other runtimes would call them preemptable green threads) has its own heap, communicates with other processes by messages, and only works on immutable data without the involveme…

> Each BEAM process (other runtimes would call them preemptable green threads) has its own heap, communicates with other processes by messages, and only works on immutable data without the involvement of Native Interface Functions (NIFs). There’s no shared memory at all.

Is this related to my question?

I can see that this helps to prevent (or ease) out-of-memory errors. Other than that, what's the difference to using Rust's green threads, given that the developer knows what they are doing (but are still human and can make mistakes of course)?

Maybe a concrete example would help me (and others) to understand the difference.

Re: Elixir and Rust is a good mix

#158

Post by valenterry »

Fire-Dragon-DoL wrote: post #143
valenterry wrote: post #131

Earlier quoted context omitted.

> Fault tolerance and supervision hierarchy might be unnecessary as mentioned. It's not like there is suddenly no fault tolerance though. Erlang has a certain way of handling/dealing with errors/faults and so does Rust and other languages. I would not by default assume that Erlang's errorhandling is superior. > That leaves us with runtime introspection, which is pretty cool indeed. But that has to compete with Rust p…

The reason why I haven't brought it up is because they are not the same thing, so they can't compare. Of course rust type system is great, but at the same time the memory management is not something necessary to most software. Elixir could teach some really good practices to people writing code, which is why I'm somewhat sad that other languages can supersede it (go, rust).

> Elixir could teach some really good practices to people writing code, which is why I'm somewhat sad that other languages can supersede it (go, rust).

My problem with this statement is, that it emphasizes the language (Elixir) but what you really mean is the paradigm of using the BEAM no? As in, using Erlang or Elixir doesn't really matter for those good practices, even if Elixir is nicer in some regards.

In that case, it should be written like that, otherwise it will confuse people and prompt them to disagree, like I did.

Re: Elixir and Rust is a good mix

#159

Post by dxhdr »

valenterry wrote: post #157
halostatue wrote: post #145

Earlier quoted context omitted.

> > Also, Rust is not safe from dead/live locks and many other concurrency issues, only data race free. > How is Erlang safe from those things in a way that cannot or only with a lot of effort be replicated when using Rust? Each BEAM process (other runtimes would call them preemptable green threads) has its own heap, communicates with other processes by messages, and only works on immutable data without the involveme…

> Each BEAM process (other runtimes would call them preemptable green threads) has its own heap, communicates with other processes by messages, and only works on immutable data without the involvement of Native Interface Functions (NIFs). There’s no shared memory at all. Is this related to my question? I can see that this helps to prevent (or ease) out-of-memory errors. Other than that, what's the difference to using…

> Other than that, what's the difference to using Rust's green threads, given that the developer knows what they are doing (but are still human and can make mistakes of course)?

An analogy: The BEAM process model is to "developers know what they are doing" as the Rust borrow checker is to "C developers know how to write memory safe code."

In other words, your program will have bugs. Your program will not correctly handle every failure mode. Your program will fail. The BEAM process model makes it so that a failure in one process won't take down all processes. And furthermore, after a process fails, there's always a deterministic way to recover from that failure without you the programmer having to think about it too hard.

The system is so robust that having processes fail on error conditions is encouraged. Once you really internalize this "let it crash" way of thinking and writing code, you only program for the happy path and let the process system handle the rest. The code ends up being much shorter and easier to understand. It's the complete opposite of writing code in something like Go, or I imagine Rust, where you explicitly handle or punt every error you can think of at every step.

And interestingly enough, despite not handling errors at every step, the share-nothing process model ends up being much more resilient in the face of errors.

Re: Elixir and Rust is a good mix

#160

Post by Fire-Dragon-DoL »

valenterry wrote: post #158
Fire-Dragon-DoL wrote: post #143

Earlier quoted context omitted.

The reason why I haven't brought it up is because they are not the same thing, so they can't compare. Of course rust type system is great, but at the same time the memory management is not something necessary to most software. Elixir could teach some really good practices to people writing code, which is why I'm somewhat sad that other languages can supersede it (go, rust).

> Elixir could teach some really good practices to people writing code, which is why I'm somewhat sad that other languages can supersede it (go, rust). My problem with this statement is, that it emphasizes the language (Elixir) but what you really mean is the paradigm of using the BEAM no? As in, using Erlang or Elixir doesn't really matter for those good practices, even if Elixir is nicer in some regards. In that ca…

No, I don't think so. Sure the language is structured to work with beam, so the line is somewhat blurry, but in my mind I was referring to practices that the language itself promotes:

    - no state, unless when you really need it
    - avoid mocks unless you really need
    - pipeline-style approach where writes happen only at the end (io at the edge of the system)
    - prefer integration tests
Just things you figure out as you write elixir code
Post reply on HN