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

Lovely Week with Elixir

ramblingcode.dev

Post reply on HN
Print view View original

51–60 of 139 posts

Re: Lovely Week with Elixir

#51

Post by dpeck »

ch4s3 wrote: post #24
biggestlou wrote: post #17

I learned Elixir a few weeks ago as a quarantine self-improvement project and pretty much loved it. There are some warts, as in any language. As someone who's primarily worked in Go and Java in the past and has also been learning Rust I don't super love the optional typing thing, and I end up missing higher-level data constructs like interfaces and traits. But there are some great language features, like guards and p…

> 1. Ecto is simply the best DB library I've encountered in any language. I'd almost recommend learning Elixir just to be able to use Ecto. It's interesting, people always talk about Phoenix, which is nice, but Ecto is really special. I often recommend it to anyone who is feeling burned by Active Record implementations.

Changesets are beautiful. And they're great for general structure validation outside of databases as well.

Re: Lovely Week with Elixir

#52

Post by Scramblejams »

renox wrote: post #40
Scramblejams wrote: post #20

Earlier quoted context omitted.

The older I get the grumpier runtime errors make me. I want ReasonML (language!) and Erlang (OTP!) to have a baby, and I want it birthed by the Go runtime. (Go? Yeah, Go. I don't love the language, but I am a lover of low latency and garbage collection, what can I say?) Yes, there's Gleam, but if something's based on BEAM, the throughput generally won't impress. :-( Would seem a shame to do all that static typing, an…

I would be very surprised that Go had lower latency than BEAM based languages, higher throughput/better CPU utilisation OK, lower latency?? Do you have a benchmark showing this? As for Pony, in theory it should be great but it looks very complex..

Not sure where I implied Go would beat BEAM on latency, didn't intend to. On the contrary, BEAM's had decades poured into keeping the long tail under control, while with Go it's a work in progress.

I singled out Go because it's the only reasonably mainstream multithreaded (need this for actors), statically typed (need this for CPU throughput), garbage collected (need this for ergonomics) language out there with an emphasis on keeping latency under control, and as such would be the only sensible target I know of to host the language I proposed.

Re: Lovely Week with Elixir

#53

Post by derefr »

brokencode wrote: post #47
derefr wrote: post #29

Earlier quoted context omitted.

> I don't super love the optional typing thing It might not be a plus if you're writing a web-app, or some other kind of easily-restarted "shared-nothing business layer" system. But get deep-enough into absorbing the Zen of Erlang (i.e. by trying to write a big-deal telecom system; or by working on a distributable Erlang DBMS like CouchDB), and you'll come to appreciate it. Specifically, you'll realize that it'd actu…

That’s all true, but I think a Typescript-like system would work really well here. Typescript is very tolerant of the data being different than the type definition, and it doesn’t know or care if your data actually matches the type definition at runtime. It would be up to the developer to account for different versions of the data when writing out type definitions, and the worst case is that you try to access a prope…

I mean, that's already what Erlang/Elixir has, in the form of Dialyzer, a runtime "type linter" (which is what the typespecs in the article feed into.)

It's static typing that Erlang can't complete-the-triangle on; not typing generally.

The only problem is that "offline" type-checking like this does nothing to solve one of the main use-cases/pain-points where Erlangers want types (or, at least, think they want types): in the messages that actors receive. You can't make any sort of a type assertion about what other actors in the system are allowed to send this actor, and get that validated; because "other actors" in a distributed system necessarily include ones that aren't even part of your present codebase!

I have a philosophy about this—not sure where I picked it up, but I think it hews to the Zen of Erlang quite well:

If you already know the type of a message, then by definition, it's not a message any more, but just a regular data value. A message is an OOP concept (and Erlang is an OOP language, where processes are the "objects.") An OOP "message" is a piece of data the meaning of which is up to the interpretation of the recipient; where that interpretation can change as the recipient's internal state changes. The whole point of the "receiving a message" code that you write in an Erlang actor-process, is to allow you to do custom logic for that interpreting part. To use the value itself, in making the decision of what the value is.

In fact, I would extend that: the whole point of Erlang as a language is to do that "interpreting" part. Once you know what something is and have put it into a canonical validated structure, you may as well hand it off to native code (using e.g. https://github.com/rusterlium/rustler). If you think of native code as being a pure domain of strongly-typed values, then picture Erlang as the glue that lives in the ugly world of "not yet typed" values, making decisions under partial-information conditions on what types to try to conform received messages into, before they can enter that pure strongly-typed domain. That's Erlang's idiomatic use-case! (You can tell, because using it for that produces absolutely beautiful code; whereas using it to do e.g. crypto math, produces an abomination.)

Which is all to say: the interpretation (or, if you like, constraint) of a message into a typed value is a Turing-complete operation; and the logic for doing so is best represented as an Erlang program. Erlang doesn't need a type system for messages; Erlang is a type system for messages. :)

Re: Lovely Week with Elixir

#54

Post by cageface »

Scramblejams wrote: post #20
ninjakeyboard wrote: post #7

Elixir is decent and I've worked with it a fair amount in production systems... Mostly Rubyists seem to really click with it. And ruby idioms are all over it - you can taste its history and proximity to ruby's ecosystem. As a scala dev that ended up working with elixir for a couple years, my opinion is that a typesafe elixir-like language would really bring BEAM back into the mainstream. Akka is alright but it's shoe…

The older I get the grumpier runtime errors make me. I want ReasonML (language!) and Erlang (OTP!) to have a baby, and I want it birthed by the Go runtime. (Go? Yeah, Go. I don't love the language, but I am a lover of low latency and garbage collection, what can I say?) Yes, there's Gleam, but if something's based on BEAM, the throughput generally won't impress. :-( Would seem a shame to do all that static typing, an…

The Kotlin KTOR framework is the most promising new web stack I’ve seen. It doesn’t have the higher level runtime features of Erlang but it checks most of your other boxes.

Re: Lovely Week with Elixir

#55

Post by sjm »

I built the API for a side project in Elixir/Phoenix a couple years ago making use of Phoenix WebSockets, and it was truly mindblowing how much you could get done with such a little amount of code.

Re: Lovely Week with Elixir

#56

Post by acdibble »

winrid wrote: post #46
ashton314 wrote: post #22

The BEAM is a huge win: having lightweight threads means you can often do away with things like Redis for job queues and PubSub stuff. I love this answer on StackOverflow by Elixir's creator: https://stackoverflow.com/questions/32085258/how-can-i-sched... So simple. Something that would require a job queue and a job runner fades away into a piece of the OTP application tree. When it crashes, it will even come right b…

Wait, how does that answer prevent only one instance of the job across the whole system? That's what I'd use Redis or something for - for locking.

If there is only one process running this GenServer, there will only be one instance of the job in the system.

An BEAM process, and therefore a GenServer, has an atomic message queue built in. Only the process itself can pop messages out of its queue, so there is no need for locking. It is not possible to get messages out of the queue concurrently. Messages can be processed concurrently, but that's after they've already been removed from the queue.

Re: Lovely Week with Elixir

#57

Post by skeletal88 »

biggestlou wrote: post #17

I learned Elixir a few weeks ago as a quarantine self-improvement project and pretty much loved it. There are some warts, as in any language. As someone who's primarily worked in Go and Java in the past and has also been learning Rust I don't super love the optional typing thing, and I end up missing higher-level data constructs like interfaces and traits. But there are some great language features, like guards and p…

Interesting. I really like Python and SqlAlchemy. Changing objects in the database via changesets and applying them on top of eachother feels kinda alien, when I can't do object.property = something.

The thing that confuses me most about Phoenix and Elixir is how do I actually deploy the application to production? I have my own server where I can run whatever I want (running Ubuntu), so what do I have to do to get my Phoenix application working there? How do I get my code running as a systemd service?

Re: Lovely Week with Elixir

#58

Post by dnautics »

52-6F-62 wrote: post #45
biggestlou wrote: post #17

I learned Elixir a few weeks ago as a quarantine self-improvement project and pretty much loved it. There are some warts, as in any language. As someone who's primarily worked in Go and Java in the past and has also been learning Rust I don't super love the optional typing thing, and I end up missing higher-level data constructs like interfaces and traits. But there are some great language features, like guards and p…

I've been meaning to do this for so long and I've started at least twice but other work or life have gotten in the way. And I haven't gotten any "quarantine-time" as my industry has been busy! It's good to hear this, though. I might have to try and re-prioritize learning it again. Do you have any good resources on hand that you used and would recommend?

Actually I think the one place where elixir community is relatively lacking is online long form tutorials. There is some fantastic content on YouTube. I quite like plangora for intro stuff and knowthen for more advanced content.

Re: Lovely Week with Elixir

#59

Post by dnautics »

winrid wrote: post #46
ashton314 wrote: post #22

The BEAM is a huge win: having lightweight threads means you can often do away with things like Redis for job queues and PubSub stuff. I love this answer on StackOverflow by Elixir's creator: https://stackoverflow.com/questions/32085258/how-can-i-sched... So simple. Something that would require a job queue and a job runner fades away into a piece of the OTP application tree. When it crashes, it will even come right b…

Wait, how does that answer prevent only one instance of the job across the whole system? That's what I'd use Redis or something for - for locking.

You can use tricks like the global spawn option to make processes globally unique. Doesn't scale infinitely, but for a 2->low double digits HA/load balanced system it should be fine.

Re: Lovely Week with Elixir

#60

Post by dnautics »

Scramblejams wrote: post #52
renox wrote: post #40

Earlier quoted context omitted.

I would be very surprised that Go had lower latency than BEAM based languages, higher throughput/better CPU utilisation OK, lower latency?? Do you have a benchmark showing this? As for Pony, in theory it should be great but it looks very complex..

Not sure where I implied Go would beat BEAM on latency, didn't intend to. On the contrary, BEAM's had decades poured into keeping the long tail under control, while with Go it's a work in progress. I singled out Go because it's the only reasonably mainstream multithreaded (need this for actors), statically typed (need this for CPU throughput), garbage collected (need this for ergonomics) language out there with an em…

I'll say one thing. I accidentally forkbombed my running elixir system in prod (miscontacting an error reporting service triggered two more error reports, and the error reporting service 500'd during an outage), and it kept servicing user requests without much of a sweat.
Post reply on HN