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

Why am I interested in Elixir?

underjord.io

Post reply on HN
Print view View original

171–180 of 183 posts

Re: Why am I interested in Elixir?

#171

Post by TylerE »

didibus wrote: post #162
true_religion wrote: post #94

Earlier quoted context omitted.

Java is an interpreted language because you always need a JVM to run it. I even if you distribute the runtime with your code as one package, that’s just an artificial distinction. Regardless, interpreted does not mean bad, or poor performance for your task. It’s a technical notion. Most people would say Python is interpreted, even if you are only running compile python bytecode on a JIT like PyPy. That’s exactly the…

Java is compiled to Java byte code. It cannot be interpreted in its source form. There's nothing preventing it to be, but as far as I know, there are no interpreters for it. Python on the other hand can be interpreted from source, and that's the default behavior, making Python an interpreted language. This makes Java a compiled language, even though it is compiled to machine code for a machine that doesn't exist. Jav…

That is incorrect. I don't know of any mainstream Python implementation that has ever interpreted the code directly, except perhaps in a context like evasl(). CPython has all ways compiled to byte-code first.

Actual sourced-based interpretation is _very_ slow, and pretty rare in anything that sees meaningful real world use. Ruby was, back when it was an order of magnitude slower than Python, but no other example jumps readily to mind, and Ruby went bytecode with the release of 1.9 in 2007.

Re: Why am I interested in Elixir?

#172

Post by mercer »

pmontra wrote: post #135
sb8244 wrote: post #74

Earlier quoted context omitted.

I think one of the big points about being a true OO language is that the only way to talk to a process is via message passing. To me, the handle concept makes sense when you consider that it's handling a message in its mailbox.

Yes, I see that but it's an unnecessary complication. All I want to do client side is calling Module.func() and GenServer side I wish I could only def func() instead of all those incantations. Furthermore GenServers mix client side and server side code in the same module. It's very confusing even after years. It's one of the most unpleasant coding experience of the decade for me. On the other side I'd steal Elixir's…

I think Dave Thomas has a bunch of comments on the elixir forums, and perhaps blog articles and videos too that express a similar problem with GenServers. might be interesting to look those up.

IIRC, one approach he encourages is to at the very least keep most of your logic in a separate module rather than have just a GenServer module that contains a bunch of regular functions and a bunch of handle_ functions (which is kind of idiomatic, or at least what I've always been taught).

That said, it's been a while since I followed this discussion so I'd be happy to be corrected.

EDIT: calling a 'public' function in a GenServer and having a handle_ function actually deal with it does seem to have an explicitness about it that I think I like. Learning about processes and how they work, I imagine I might've gotten confused if a seemingly normal functional call somehow magically handed things off to a different process.

Re: Why am I interested in Elixir?

#173

Post by mercer »

1_player wrote: post #78
benmmurphy wrote: post #10

coming from erlang elixir is much nicer than that. exunit is miles ahead of eunit and i feel like that would be enough to convince me to switch. the with syntax is nice and helps to deal with early exit on errors but still feels a bit awkward compared to imperative control flow. like you can do something like this in an imperative language: foo, err = func() if err != nil { return nil, Err("bad") } bah, err = func2(f…

You also have to consider that the whole BEAM philosophy is "let it crash". On a "normal" language you have to deal with all error paths or your app goes down. On the BEAM you handle the happy case and common and unexceptional errors. Otherwise, let it crash. Example: if your app depends on a database that once in a blue moon is unreachable, don't test for connection errors. Just assume the connection was successful,…

I'm a big fan of the 'let it crash' approach. A lot of code I write is hacker-ish stuff where I just want to get something done and I don't need it to be pretty. I've been amazed at how many of my projects in Elixir just kind of keep chugging along despite the fact that I mostly bothered coding only the 'happy path'.

A while ago I wrote some code that retrieves data from various online sources (cryptocurrency exchanges) at regular intervals. A friend of mine wrote essentially the same code in Python. His code was littered with try/catch statements and even with those the app would often crash because these API's sucked ass. As a result, there'd be gaps in the data, or he'd have to restart the app or set up whatever restart mechanism one uses in the python ecosystem.

Meanwhile my elixir project just kind of kept running and retrieving data, and barring permanent changes in the various API's, it would keep collecting data even in every once in a while the endpoints would misbehave.

My typical approach to projects is to tinker and cobble things together but then also overly worry about all the things that can go wrong. I know I'm not alone in being this way; I've met plenty of developers who seem to be a combination of just wanting to get results but then worrying excessively about everything that could go wrong.

Elixir is singular in how it allows me to approach projects in this manner while still feeling confident that it'll work well enough. And while that might not be the most common use-case, it's really helped reinvigorate my enjoyment of programming.

Re: Why am I interested in Elixir?

#174

Post by inferiorhuman »

wolf4earth wrote: post #131
inferiorhuman wrote: post #43

Earlier quoted context omitted.

Deployments are a mess and as it is interpreted, performance is closer to Ruby than Go. I found the community to be pretty disappointing (but YMMV obviously) — it seemed more alternative oriented than the Rust community (which seems more solutions oriented).

Performance is definitely not close to Ruby, this is just blatantly incorrect. Elixir and Erlang can easily hold their ground vs Go. The BEAM was originally designed to run software for telephone switches. It's often referred to as soft realtime because it is so responsive. It has been battle-tested for now over 3 decades. Where the BEAM falls flat is pure number crunching but it's blazing fast with binary processing…

A fresh phoenix project where you render a nontrivial template easily reaches sub millisecond response times, without any kind of optimization.

Going from Phoenix to Rocket.rs I saw a pretty dramatic speedup on even simple pages. Phoenix was faster than the Rails version of the app, but still slower than a compiled language.

Re: Why am I interested in Elixir?

#175

Post by inferiorhuman »

Existenceblinks wrote: post #49
inferiorhuman wrote: post #43

Earlier quoted context omitted.

Deployments are a mess and as it is interpreted, performance is closer to Ruby than Go. I found the community to be pretty disappointing (but YMMV obviously) — it seemed more alternative oriented than the Rust community (which seems more solutions oriented).

It's not a mess. Mostly It was just unclear mixed of runtime and compile time configuration that contribute the inconvenience. Elixir 1.9 just comes up with a simple built-in release mechanism with more clear on how you put configuration.

It's not a mess. Mostly It was just unclear mixed of runtime and compile time configuration that contribute the inconvenience. Elixir 1.9 just comes up with a simple built-in release mechanism with more clear on how you put configuration.

From the sound of it things have gotten better (by throwing out oft-touted features), but Elixir deployments are inherently far too complicated. With Go and Rust you get a single binary and a single program to run. With Java (and other languages targeting the JVM) you get a single jar archive. With Elixir you get to bundle the whole runtime and spawn a few separate supervisor processes to run even a hello world app. Lord help you if the only maintainer for the deployment tooling takes an unannounced vacation or if the various BEAM processes stop talking to each other because the stars are misaligned (and the deployment tools are minimally tested) and you can't even run an Elixir based database migration as a result.

When I started toying around with Elixir and Phoenix I'd just come off of a Clojure kick. You can get most, if not all, of the syntactical sugar that Elixir promises with other languages that all offer infinitely simpler deployments with more mature tooling. In the case of Clojure you get whatever JVM tooling you'd like.

Re: Why am I interested in Elixir?

#176

Post by GordonS »

enraged_camel wrote: post #7

My startup uses Phoenix, along with a Vue front-end. The combo is an absolute joy to use. The benefit that has had the most business impact for us so far is developer productivity. A couple of months ago we met with a prospective client to discuss their use cases and conduct requirements gathering. They really liked what we showed them, but the CFO wanted a dashboard that displayed the data in the app in a specific w…

FWIW, I feel like I he this kind of productivity with server-side rendered ASP.NET Core web apps.

Something that is great about .NET is the available tooling - the debuggers in both Visual Studio and Rider are amazing, and it's difficult to imagine living without them.

AFAIK, you're relegated to rather primitive "println debugging" with Elixir - has this been an issue for you in practice?

Re: Why am I interested in Elixir?

#177

Post by didibus »

TylerE wrote: post #171
didibus wrote: post #162

Earlier quoted context omitted.

Java is compiled to Java byte code. It cannot be interpreted in its source form. There's nothing preventing it to be, but as far as I know, there are no interpreters for it. Python on the other hand can be interpreted from source, and that's the default behavior, making Python an interpreted language. This makes Java a compiled language, even though it is compiled to machine code for a machine that doesn't exist. Jav…

That is incorrect. I don't know of any mainstream Python implementation that has ever interpreted the code directly, except perhaps in a context like evasl(). CPython has all ways compiled to byte-code first. Actual sourced-based interpretation is _very_ slow, and pretty rare in anything that sees meaningful real world use. Ruby was, back when it was an order of magnitude slower than Python, but no other example jump…

Ah you are right, I didn't know that about Python. Since it can compile to IR on the fly though, I think it gets more tricky as well. Probably fair to consider that interpreted or compiled both. Like they say in their doc:

> Python is an interpreted language, as opposed to a compiled one, though the distinction can be blurry because of the presence of the bytecode compiler. This means that source files can be run directly without explicitly creating an executable which is then run.

OpenJDK can't do that. You need to pre-compile the source to byte code first.

Re: Why am I interested in Elixir?

#178

Post by OvermindDL1 »

GordonS wrote: post #176
enraged_camel wrote: post #7

My startup uses Phoenix, along with a Vue front-end. The combo is an absolute joy to use. The benefit that has had the most business impact for us so far is developer productivity. A couple of months ago we met with a prospective client to discuss their use cases and conduct requirements gathering. They really liked what we showed them, but the CFO wanted a dashboard that displayed the data in the app in a specific w…

FWIW, I feel like I he this kind of productivity with server-side rendered ASP.NET Core web apps. Something that is great about .NET is the available tooling - the debuggers in both Visual Studio and Rider are amazing, and it's difficult to imagine living without them. AFAIK, you're relegated to rather primitive "println debugging" with Elixir - has this been an issue for you in practice?

> AFAIK, you're relegated to rather primitive "println debugging" with Elixir - has this been an issue for you in practice?

Not at all. The traditional BEAM way of debugging is the tracing modules. For little things an `IEx.pry()` is often good enough though.

Re: Why am I interested in Elixir?

#179

Post by GordonS »

OvermindDL1 wrote: post #178
GordonS wrote: post #176

Earlier quoted context omitted.

FWIW, I feel like I he this kind of productivity with server-side rendered ASP.NET Core web apps. Something that is great about .NET is the available tooling - the debuggers in both Visual Studio and Rider are amazing, and it's difficult to imagine living without them. AFAIK, you're relegated to rather primitive "println debugging" with Elixir - has this been an issue for you in practice?

> AFAIK, you're relegated to rather primitive "println debugging" with Elixir - has this been an issue for you in practice? Not at all. The traditional BEAM way of debugging is the tracing modules. For little things an `IEx.pry()` is often good enough though.

> The traditional BEAM way of debugging is the tracing modules

Excuse my ignorance, but by "tracing modules", do you mean "println debugging"?

I had a quick look at IEx.pry(), which at a glace I think gives you a repl at a given breakpoint? It looks like it also requires you to instrument your code with breakpoints, which TBH feels a bit ugly (but could presumably be solved with the right IDE)

Re: Why am I interested in Elixir?

#180

Post by thelazydogsback »

verttii wrote: post #37
thelazydogsback wrote: post #28

Earlier quoted context omitted.

Sounds like F# on dotnetcore or Reason may suite you

What makes you say that? I mean what would they do better than I could do with Elixir or Haskell? I use Elixir when typical APIs or stateful soft real-time stuff is needed and Haskell whenever I have some complex data structures and logic to work on. I'm unfamiliar with F# and .NET stuff. C# I don't like one bit, if that's anywhere near that avenue. I've tried Reason but didn't quite click with it. Ended up preferrin…

Not sure why you don't like C#, as to me it's the most sane and powerful of the Java-esque languages. I'm familiar and have used all the usual suspects, and IMHO I like the .net stack. I said F# because you said you liked both Haskell (ML-style languages) and ELM. (F# however of course eager-eval like OCaml/Reason and doesn't quite have higher-order types.) And you said, "Haskell is not as ideal for web development" - and you can't really beat asp.net core on the back-end side of things. With F# you get back-end code and front-end code - the SAFE stack, ELMish, transpilation of F# to front-end JS using Fable or Xamarin WebSharper (which creates transparent proxies to exec code client-side purely from a meta-data annotation on your fn), Electron on the client, mobile (droid, iOS...) using web-tech, bindings to ReactNative, or the new Fabulous, etc.
Post reply on HN