71–80 of 97 posts
If you're doing development with a web socket layer, it's entirely worth it to try out Phoenix Channels before you commit to another stack. It makes your life so much easier. There are a lot of other great reasons to use Elixir though.
The difficulty is finding good Dev teams building Elixir as Elixir and not second rate Ruby on Rails refugees looking for a faster Rails a-la Phoenix.
I'm so excited about Elixir these days. I would love to see more cookbook examples of using Elixir but NOT as a Ruby/Rails replacement. While the concept is not new to me, I have recently become totally infatuated with the concept of green threads, actor models, etc... for dealing with concurrent processing. This is literally what Erlang was designed to do, and Elixir makes it user friendly. The real beauty of Elixir…
fwiw green/userspace threads are not a good thing[1]. They're only used because for the most part system level threads don't yet have the scaling properties applications need. Once that deficiency is fixed (yes...we're still waiting after 30 years) green threads can go away. [1]Because insight at the system level is required to do effective scheduling and because the transition between the userspace's concurrency mod…
One of the biggest strengths of Erlang (and Elixir by extension) is that they take the approach of finding practical solutions to real problems.
Sure, theoretically there might be a better solution than green threads, but like you said, we're still waiting for that better solution 30 years later. In the meantime, Erlang has been powering highly reliable and concurrent systems for ~30 years now.
Earlier quoted context omitted.
This is interesting when you want near realtime performances, as you don't have all the culprint of a http request : you basically just send a few octets (a json document, or even just a simple value), and you don't have to build a request and negotiate a connection. This is not something obvious because we have helpers to make http requests, but there are many things going on while issuing a http request (building h…
I've been out of front-line web development for a while. Are Websockets supported widely enough that a developer can reasonably assume they are available and not have to worry about workarounds such as comet/long polling?
[EDIT] I see another commenter in this thread mentions phoenix.js beating socket.io. Thanks, I will have to look into this!
I'm so excited about Elixir these days. I would love to see more cookbook examples of using Elixir but NOT as a Ruby/Rails replacement. While the concept is not new to me, I have recently become totally infatuated with the concept of green threads, actor models, etc... for dealing with concurrent processing. This is literally what Erlang was designed to do, and Elixir makes it user friendly. The real beauty of Elixir…
>I would love to see more cookbook examples of using Elixir but NOT as a Ruby/Rails replacement. I would love to see more examples that get away from web dev with Elixir. While it's great with the Phoenix framework there is so much more to Elixir than that. Trying to deploy an elixir daemon has been a pain and I haven't found much around that. There is escript and distillery and while I haven't tried distillery for n…
Earlier quoted context omitted.
Don't take this the wrong way, but it sounds like you're approaching this from the perspective that Rails' way is the "correct" way when in fact almost everything about Rails' doctrine will cause you problems over the life of a project. > We're calling them from controllers more or less as Model.get_something(args). I checked it now and we have zero occurrences of " from " in controller code. All the queries are conf…
First of all thanks for the detailed answer. It contains many interesting points. I don't think that AR is correct, I think that AR is more convenient than Ecto in many cases we run into in web development. With AR I don't have to write my own queries and encapsulate them into functions (but it's kind of what we do with scopes) and it has a more compact syntax. Ecto is more flexible, but that flexibility is not neede…
I wouldn't say it is to use more repositories in the future (I also hate future-proofing code) but rather to make it explicit what is happening on the database side. It aligns well with other ideas in Ecto, such as letting the database do uniqueness checks.
Most of the problematic Rails projects I worked with were because of this coupling between business logic and database that ActiveRecord encourages. But this is nothing new, it is one of the top 3 complaints about Rails.
Elixir is pure pleasure. Coming from a ruby background, I din't have huge difficulty in understanding the syntax, and unlike other functional languages like Clojure, it's not an abrupt change from procedural paradigm. You can still assign variables in functions etc.
In Clojure you can still stick something in an atom or volatile and easily update it in place... doing that is a lot more involved in Elixir.
I'm so excited about Elixir these days. I would love to see more cookbook examples of using Elixir but NOT as a Ruby/Rails replacement. While the concept is not new to me, I have recently become totally infatuated with the concept of green threads, actor models, etc... for dealing with concurrent processing. This is literally what Erlang was designed to do, and Elixir makes it user friendly. The real beauty of Elixir…
fwiw green/userspace threads are not a good thing[1]. They're only used because for the most part system level threads don't yet have the scaling properties applications need. Once that deficiency is fixed (yes...we're still waiting after 30 years) green threads can go away. [1]Because insight at the system level is required to do effective scheduling and because the transition between the userspace's concurrency mod…
BEAM VM does a very good jobs. It serves financial, large telecom, messaging, web and many other services. It is one of the marvels of software engineering. Not only does it provide this N:M scheduling well, it also provides process heap isolation between concurrency units (processes).
Heap isolation is very important, it increases safety, fault tolerance and provides guarantees that are just not there with shared memory model. Heap isolation is also other CSP/Erlang-like-clones ignore when they say they provide an Erlang-like environment. The only equivalent is really something like forking hundreds of thousands of OS processes [+]
> Once that deficiency is fixed (yes...we're still waiting after 30 years) green threads can go away.
I am not sure when it will be fixed. We'd need to be able to run one million OS processes effectively with the same latency and memory usage as what Erlang's processes currently have. We haven't gotten there in 30 years as you said, I don't think we are getting any closer. Sure there are machines that could probably run a lot more OS processes than before, but then putting an Erlang VM on the same hardware would allow running even more of its lightweight processes and so on.
[+] Another interesting exception could be Rust. If say threads were very cheap to create and could have millions of them, then could provide the same memory safety guarantees at compile time.
I'm so excited about Elixir these days. I would love to see more cookbook examples of using Elixir but NOT as a Ruby/Rails replacement. While the concept is not new to me, I have recently become totally infatuated with the concept of green threads, actor models, etc... for dealing with concurrent processing. This is literally what Erlang was designed to do, and Elixir makes it user friendly. The real beauty of Elixir…
>I would love to see more cookbook examples of using Elixir but NOT as a Ruby/Rails replacement. I would love to see more examples that get away from web dev with Elixir. While it's great with the Phoenix framework there is so much more to Elixir than that. Trying to deploy an elixir daemon has been a pain and I haven't found much around that. There is escript and distillery and while I haven't tried distillery for n…
We spent some time with friend doing research and trying to connect all pieces to make it work.
Earlier quoted context omitted.
Don't take this the wrong way, but it sounds like you're approaching this from the perspective that Rails' way is the "correct" way when in fact almost everything about Rails' doctrine will cause you problems over the life of a project. > We're calling them from controllers more or less as Model.get_something(args). I checked it now and we have zero occurrences of " from " in controller code. All the queries are conf…
First of all thanks for the detailed answer. It contains many interesting points. I don't think that AR is correct, I think that AR is more convenient than Ecto in many cases we run into in web development. With AR I don't have to write my own queries and encapsulate them into functions (but it's kind of what we do with scopes) and it has a more compact syntax. Ecto is more flexible, but that flexibility is not neede…
Repo.insert! %Post{title: "Awesome Post", slug: "awesome-post", category_id: 3}
%Post{user_id: current_user.id}
|> Post.changeset(attributes)
|> Repo.insert
Post.create(post_params.merge(user_id: current_user.id))
def post_params
params.require(:post).permit(:title, :slug, : category_id)
endI'm so excited about Elixir these days. I would love to see more cookbook examples of using Elixir but NOT as a Ruby/Rails replacement. While the concept is not new to me, I have recently become totally infatuated with the concept of green threads, actor models, etc... for dealing with concurrent processing. This is literally what Erlang was designed to do, and Elixir makes it user friendly. The real beauty of Elixir…
Erlang's units of concurrency are processes, not (green) threads. Unlike threads, they are completely isolated from each other.
> (co-operative in userspace, not OS-level).
Erlang's scheduler is preemptive, which means it has the ability to context switch between tasks without cooperation at any time.
> etc... for dealing with concurrent processing. This is literally what Erlang was designed to do, and Elixir makes it user friendly.
What exactly is user unfriendly in Erlang's concurrency model? You only need to understand 3 concepts, spawn, receive and send in order to perform any concurrent task. I'm not familiar with Elixir, what does it do differently?