Hacker News Reader

Comment by lawn | Hacker News Reader

> Elixir has drastically improved my productivity, and you get to find errors in compile time, leading to much, much better quality, reliable code.

Interesting, I haven't seen that as a strong point for Elixir.

Granted I'm comparing it to Haskell and Rust which really give you errors in compile time. They aren't very popular for web dev though and compared to the other languages you list I guess I can see where you're coming from.

View on HN

Relative to Ruby it's a lot better without sacrificing the rapid prototyping. If you need real correctness then Haskell and Rust are in a class of their own, but they'll never be as fast for hacking (although admittedly Rust has a high ceiling). I think the magic of Elixir is the happy middle ground where you get more correctness than a multi-paradigm highly dynamic language like Ruby with minimal overhead, and then you strengthen the operational story with a deeply embedded crash-and-restart tooling from Erlang/OTP encouraging less statefulness and easier recovery by design across the board.

Relative to Ruby it has more upfront checking of some things. In Elixir, calling a function that doesn't exist or with the wrong number of arguments is something that will error out at compile-time; with Ruby, you don't find out until you run the code with the bad call.

I agree, though, that compared to Haskell and Rust it doesn't give you much. Dialyzer is (intentionally) a fail-open checker that doesn't allow expressing generics; I've had a rough time getting it to tell me my code is wrong. Credo is (intentionally) just a style linter. "Just let it crash" isn't useful when you're talking about code that is going to break because of its structural incoherence (a class of errors type-checker are good at catching), and not because of transient errors in external dependencies.

Elixir doesn't do type-checking by default, but you can rather easily get it to enforce that records must specify certain fields on creation. Other things, like setting up the optional typechecker (Dialyzer) and writing type specifications for your code, take a bit more effort but do help find problems.

Im new (1yr or so) to elixir, never really believed in dialyzer, but a few weeks ago I noticed my vscode started dialyzing my code in real time and it's caught several errors that would have been hard to catch, and whatever vscode plugin I'm using makes it hard to not write typespecs.

Dialyzer really gives you what you put into it. It never false-positives (by design), even while working with limited information, so if you're not writing typespecs, there's only so much it can do.

If, though, you make a habit of writing typespecs for everything, and defining domain-specific types rather than relying just on the primitives, it can get you surprisingly far.

It'll never be as powerful as Haskell or Idris, but it's absolutely a tool all Elixir (and Erlang) developers should be using.

Also, if anyone ever wants an easy way to contribute to open-source Elixir, just start running Dialyzer on popular projects. Every warning that pops up will be a bug, and often they'll be easy to fix.

Ah, you're probably using the ElixirLS extension, IIRC it has an auto-setup process for Dialyzer when it first gets installed. After that one-time setup it continuously typechecks open projects.

I think Rust will get there if you look at say Rocket app and compare to say express app it's about the same amount of code and equally readable but with obvious benefits that Rust has.

Rust is a really fantastic language but trivial examples can be misleading. We run a Rust app in production at ChartMogul.

Real life Rust business logic is much, much gnarlier than in a GCed language like JS. You need to manage memory so you need to deal with references and deref, lifetimes, Box, Cell, ARC etc.

For an open source example of what kind of complexity arises in real life check out crates.io: https://github.com/rust-lang/crates.io/blob/363b9e036b2ba5d8...

Wow. Coming from a C++ background, why is it necessary to first dereference, then reference again? That is, `&foo`? And why is triple dereferencing needed? There are some `&foo`. I thought I had read somewhere that Rust does auto-ref/auto-deref...

> why is it necessary to first dereference, then reference again?

This is a conversion; * calls the Deref trait. This is used by smart pointers to return the type inside the smart pointer, so for example, Box<T> is kinda like uniq_ptr<T>. So if foo is a Box<T>, then * foo is a T, and & * foo is a &T. Does that make sense?

> And why is triple dereferencing needed?

This can happen in generic contexts, sometimes, you end up with a &&String, so if foo is one of those, * foo is a &String, * * foo is a String, * * * foo is a str, and & * * * foo is a &str. (HN formatting does not like this, haha)

That's what's happening here.

> I thought I had read somewhere that Rust does auto-ref/auto-deref...

Only for method calls, that is, foo.bar() will attempt to auto ref/deref foo.

It's not really using web framework right ? For many web apps the business logic is pretty much manipulating DB state.

Getting data from the request to the DB requires dealing with all those memory management issues. The Rust compiler is amazingly helpful but the complexity is still there.

Reply on news.ycombinator.com