81–90 of 139 posts
I love Elixir. Phoenix makes web development a pleasure and LiveView is even more exciting. I would love to find a job doing it.
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…
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.
It allows the runtime to schedule coroutines effectively - they can't block for more than a function call (recursion is how you do "infinite" loops).
I think a future competitor to BEAM languages would need this feature.
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…
I would argue that if you're looking for a simpler way to build CRUD apps, just skip the middleman and use postgREST. I've been playing with Elixir and Phoenix, and while they're pretty great I like postgREST much better. You eliminate an unnecessary (in most cases) abstraction and backing onto the grown up postgresql authorization and authentication is invaluable for securing your app. For non webapp stuff I've been…
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…
> but if something's based on BEAM, the throughput generally won't impress I'm not sure where you're getting that from- that's typically the area it does well. It's bad at number crunching, but you if the work is IO bound (say, like a web application backend) it offers consistently low latency with high throughput.
I love Elixir. Phoenix makes web development a pleasure and LiveView is even more exciting. I would love to find a job doing it.
Dude, LiveView is wild . It feels kind of magical, and I think people are gonna start adopting slowly, then all at once. There's an awesome blog post on their website. where Chris McCord, creator of Phoenix, builds a real-time Twitter clone in 15 minutes. https://www.phoenixframework.org/blog/build-a-real-time-twit...
I love Elixir. Phoenix makes web development a pleasure and LiveView is even more exciting. I would love to find a job doing it.
LiveView will take some time to really get general acceptance and will probably always be somewhat controversial. Both for server roundtrips and because it is so oddly specific and doesn't have a comparable solution in most other languages. But it is fantastic where it fits, truly.
I love Elixir. Phoenix makes web development a pleasure and LiveView is even more exciting. I would love to find a job doing it.
Dude, LiveView is wild . It feels kind of magical, and I think people are gonna start adopting slowly, then all at once. There's an awesome blog post on their website. where Chris McCord, creator of Phoenix, builds a real-time Twitter clone in 15 minutes. https://www.phoenixframework.org/blog/build-a-real-time-twit...
But I'm also a full-stack developer and I'm not afraid to write JavaScript. I realize not everyone is on the same boat, and LiveView might cater to them.
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 have assumed BEAM has similar latency to Go and is garbage collected? Here is some benchmarks where Erlang beats Go in throughput: https://timyang.net/programming/c-erlang-java-performance/ https://stressgrid.com/blog/benchmarking_go_vs_node_vs_elixi...
And maybe I missed something in the second link, but Go showed very similar I/O performance to Elixir, while consuming a boatload less CPU doing it. That's what I'm after. Open to being told I missed something, though.
Earlier quoted context omitted.
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 alre…
Just curious as to how the BEAM solves it as I imagine it can.