Looks like elixir is gaining more and more traction :)
Lovely Week with Elixir
121–130 of 139 posts
Re: Lovely Week with Elixir
#122Earlier quoted context omitted.
I like Kotlin but I'd say a strength of BEAM is that it doesn't allow for infinite loops, which means coroutines can't block others. This is a fundamental strength. 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.
This is the kind of thing I was referring to by higher level runtime features in Erlang. If you really need this sort of thing then you should probably be looking at an Erlang stack but I think for a lot of projects a less exotic and also much more rigorously typed language is going to be more productive.
What do you mean "more productive"? You'll get your code out to prod way faster in a BEAM language and in my experience the only remaining errors are relatively minor and easy to "wait to fix", because the BEAM will keep on keeping on and there's no user facing effect (maybe your error logs are a bit polluted with them). Whole classes of errors are not even possible because of "copy-on-write" function passing. I recently fixed a code bug that tripped during a race condition entangleing with a blocking call across two datacenters 1000 miles apart in about one hour, because you can introspect literally everything in the vm with very little hassle, and IO writes are atomic (if you call an IO write to screen it will never be interrupted by another IO write to screen).
I call that productivity.
Re: Lovely Week with Elixir
#123Earlier quoted context omitted.
> 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.
Having worked for years with both Ecto and Ruby's ActiveRecord I really prefer ActiveRecord. It's less flexible but so much easier to use. Ecto is somewhat closer to SQL and still suffers from the "I have to relearn how to do SQL in yet another language" syndrome and it's a particularly difficult case of it. A lot of boilerplate to represent database tables and a lot of not obvious code to do easy queries. Definitely…
I have a huge dislike to ActiveRecord because its high abuse rate.
Beginners will most certainly will have highly inefficient start with it.
There are others in Ruby world which needs more praise such as Sequel and ROM(which is what Hanami uses also).
With Rails having the monopoly and most gems having AR as dependency, it's hard to see where we will go regarding ORMs in Ruby world.
Re: Lovely Week with Elixir
#124I got really excited about discovering a new progamming language, Phyton, for a second... but after some searching, I think that's just a typo
thanks!
Re: Lovely Week with Elixir
#125Earlier quoted context omitted.
All data is immutable on the BEAM with a few exceptions, so no mutation within actors.
No, that's not true. Actors in elixir/erlang mutate their state through tail call recursion through the loop function.
I said data is immutable on the BEAM, actors can update their state.
Re: Lovely Week with Elixir
#126Elixir 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 want to echo Gleam [0] as a project to watch out for. It's still very early, but it's evolving quickly, and has a big focus on providing ergonomic tooling. It's an ML inspired, statically typed language that compiles down to Erlang, and supports interop with the existing ecosystem. This means that you get access to ADTs, type inference, etc, while still being able to lean on OTP for your concurrency primitives. The…
[deleted]
Re: Lovely Week with Elixir
#127Earlier 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 think there's a sweet spot for a language that accepts mutability inside of actors, but only allows immutable objects to be sent as messages" Absolutely agree. I had great hopes an "Actor" type would be created in Swift, where every public function would be thread-safe, accept only "pure" structs / value objects, and which would automatically run on its own coroutine. Unfortunately the concurrency story seems comp…
We may get our wish when multicore finally drops for OCaml.
Re: Lovely Week with Elixir
#128Earlier quoted context omitted.
Controversial opinion: the "magic" is why I'm staying away. It's the same reason I stopped coding in Ruby/Rails: too much magic. 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.
LiveView is a nightmare from a deployment point of view. LiveView stores state on the server associated with the web socket connection. If the web socket connection disappears which is what will happen during a deployment then the user's state will disappear. The value of LiveView is not having to write javascript but the only way to preserve any non-complicated state in LiveView when the web socket disappears is to…
You are right that state is transient but JavaScript is not the only option. For transitions and screens, you can use live navigation. For forms there is automatic recovery (as you mentioned). Another option is to persist the state on the server.
For example, go back to the Twitter timeline example. Imagine that you want to do a banner that says "N tweets unread - click here to expand them". You could keep this counter in the LiveView but if you reconnect the counter will be lost. But you can also solve this by storing a pointer to the last shown tweet on the DB. Then if you reconnect, you can compute how many tweets are pending.
If you are doing a multi-step wizard you can persist each step on the DB too, etc. Depending on the use case, this could even yield further benefits, such as automatic synchronization between devices. I.e. if you read some tweets on your phone, you can automatically bump the "last shown index" on all devices. Or start the wizard in one place and finish it elsewhere.
That's the point of LiveView, you can build interactive applications that are more server-centric. Some of those features are new but that should be no surprise, it is still pre-1.0 software. Even as we add new features, you may still have to (or want to) rely on JS on many scenarios, and that's totally fine.
Re: Lovely Week with Elixir
#129I had an excellent week with Elixir building a really silly game: https://hn.lddstudios.com/ MIT Licensed. Source: https://github.com/ldd/hn_comments_game
Awesome! If you are up for reviewing each other's code, ping me!
Re: Lovely Week with Elixir
#130Earlier quoted context omitted.
> A message is an OOP concept (and Erlang is an OOP language, where processes are the "objects.") Yes. If only GenServer had an OOP syntax instead of a handle this / handle that list of functions which obfuscate what the process actually does. Elixir in particular lost a chance to make it easier to deal with.
It's not too late. You can write your own wrapper around the :gen module, and if it's really good maybe people will adopt it. I will say one thing:. If you are thinking of BEAM processes as actors/(Kay objects), you're missing the real meat of what makes BEAM processes special; what they really are are atomic units of failure domains . The other stuff is just a useful analogy that lets people grok the code structure…
We have very few GenServers in our system, with their supervisors to keep them alive and read back the initial status from the db in case of failure. They're not object in the Ruby or Python or Java way. They really are servers that take care of a specific action. The vast majority of code is function calls in the main process of the system. Still I'd like to be able to program the GenServer in a more understandable way.