Earlier quoted context omitted.
Why make a gif from this rather than a webm (seeing as you obviously know what you're doing with ffmpeg)?
What does webm support look like these days? Last I checked neither Safari nor IE had webm support.
[deleted]
Elixir web development 101: collaborative todolist with realtime updates
31–40 of 97 posts
Re: Elixir web development 101: collaborative todolist with realtime updates
#32Earlier quoted context omitted.
I've seen a few (as in 2 ;) ) examples of this myself. And this is what "scares" me the most for elixir's future/potential. I think it's a great language/tech but ruby enthusiasts rushing into it thinking that it's "just like ruby but faster" may have a very bad influence on where the language goes. They may bring a lot of ruby best practices that don't transpose at all in elixir/erlang world.
That was indeed my underlying point. I see elixir more as "erlang with easier syntax", than "ruby with a more powerful runtime". aka : you should get to understand erlang design decisions prior to jumping into the tech. Which probably means having more experience than building the typical low load website made with RoR.
We already had a ton of Rails devs who didn't know Ruby or OOP well. If Elixir becomes very popular, we will have Elixir devs that don't know OTP, functional programming (outside of pure functions/immutability), or Erlang. That's the way it goes.
Re: Elixir web development 101: collaborative todolist with realtime updates
#33Non-representative anecdote : i've recently heard of two teams that started using elixir, they both came from a ruby background, and in both case they weren't using OTP. They both justified using elixir because it was "closer to ruby" (???), and they both seemed to live a pretty difficult time with that language. Which makes me wonder : why would you ever want to use such a special language (purely functional isn't f…
I worked on a project that used elixir without OTP. There’s a lot of nice things that elixir gives you and I didn’t personally feel like there was a significant learning curve. OTP is used under the hood for lots of analytics and reporting things, but those pieces were built by other people. The project I was working on had very specific requirements for response times that simply weren’t realistic with Ruby. We could have squeezed Ruby a bit to get what we needed, but it would have introduced complexity. We also knew we’d need to add features in the future while maintaining the same performance, so siding with the simpler solution made more sense to us. At some point in the near future we’ll probably use OTP, and I’ve already got a few ideas of how we’ll be leveraging it for some of our upcoming features. OTP is the killer feature, but I find working with elixir in general to be a very pleasant experience even on projects that don’t use it.
Re: Elixir web development 101: collaborative todolist with realtime updates
#34If 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.
Re: Elixir web development 101: collaborative todolist with realtime updates
#35If 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.
Re: Elixir web development 101: collaborative todolist with realtime updates
#36If 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.
> and not second rate Ruby on Rails refugees looking for a faster Rails
That's pretty harsh, and not at all true in my experience. There's a growing community and I had no trouble hiring two remote people. I ended up with a lot of qualified candidates.
Moreover, a lot of great people came over from Rails. Jose and Chris McCord were both formerly Rails people.
Re: Elixir web development 101: collaborative todolist with realtime updates
#37> channel.on('update:todo' ... > channel.push('delete:todo' ... > Have a CRUD interface over websocket REST over websockets. What's the advantage over HTTP? I know websockets allow for pushing data to clients, but this is pull so apparently there should be no advantage, only more code to write. Edit: maybe you're sharing updates among all the users connected to the server. Still, for sending requests HTTP is enough.…
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…
> This is interesting when you want near realtime performances, as you don't have all the culprint of a http request
Excellent. How about raw TCP then?
Re: Elixir web development 101: collaborative todolist with realtime updates
#38Earlier 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…
HTTP/2 multiplexes requests over one socket connection, so it should solve most of problems you state.
Except browsers do not allow Push on http/2 so far
Re: Elixir web development 101: collaborative todolist with realtime updates
#39If 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.
The reason Elixir pulls people from Ruby is the language and community emphasis on developer productivity IMO.
It’s the one thing that Ruby excels at so well it justifies using Ruby in the face of plenty of other “fast” options. Dev time and time to market are still infinitely more important than hosting costs unless you are already at scale.
What Elixir brings to the table is the productivity and time to market with an architecture that scales for most every scenario experienced in server side dev aside from heavy math. And that architecture is designed in a way that makes maintainability a first class citizen because of the lack of long term dependency entanglement growth.
Re: Elixir web development 101: collaborative todolist with realtime updates
#40Earlier quoted context omitted.
I've seen a few (as in 2 ;) ) examples of this myself. And this is what "scares" me the most for elixir's future/potential. I think it's a great language/tech but ruby enthusiasts rushing into it thinking that it's "just like ruby but faster" may have a very bad influence on where the language goes. They may bring a lot of ruby best practices that don't transpose at all in elixir/erlang world.
That was indeed my underlying point. I see elixir more as "erlang with easier syntax", than "ruby with a more powerful runtime". aka : you should get to understand erlang design decisions prior to jumping into the tech. Which probably means having more experience than building the typical low load website made with RoR.
I'm in the fourth month of a Phoenix project, which shields me from almost all of OTP, and I agree with your point. Maybe even "Erlang with a Ruby syntax" would be too much. Similarities with Ruby don't go any further than "def" "do" "end" and many library modules and functions deliberately named to mimic corresponding modules and methods in Ruby. Everything else is different, both syntax and semantic.
After 10 years of Rails, all things considered Elixir and Phoenix are pretty good.
The best feature of the language so far is pattern matching. It can be used in the arguments of function definitions. It makes all the "if"s go away. It seems strange after 30 years of programming, but a program without conditionals is easier to read.
Not having to use an external background job framework is great news too. Just spawn your processes to send a mail, process something asynchronously and store the result in the database. No Sidekiq (or Celery if you're into Python.)
On the awful side, Ecto is too low level and it feels like a self inflicted pain. I understand the reasons behind its design decisions, but the typical web application or mobile backend don't need all of that. Actually the team working with me on this project wrote a lot of code to build queries and wrap them into another layer to return {:ok, result} / {:error, reason} tuples. 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 confined inside a model. If we were using Rails ActiveRecord would have written all that code for us. Instead we had to use a more verbose query syntax, write our functions and tests. This is a net loss of productivity.
There are some modules that can be mounted on the top of Ecto to make it look like ActiveRecord or other ORMs for other languages. I'm looking forward to using Ecto.Rut in my next project. I hope I'll never have to use Ecto directly.
https://github.com/sheharyarn/ecto_rut
We almost didn't use the supervisor layer of the language (somewhat like systemd/init for who's not familiar with it.) I used it in smaller projects and I feel like it's a little too complicated. Same for defining a GenServer, more complex and verbose than exposing the same functionality with methods from a object. I know we have to split the code between what runs in the client process and what runs on the server process, but I feel there should be a vanilla GenServer that handles the most straightfoward case inside the behavior, which is no code in the client with the exception of passing the arguments to the server. Maybe use the name, sigils or module attributes to declare if there will be a synchronous return value.
Anyway, Elixir is still young and there is time to smooth the rough edges. So far it's an acceptable contender and definitely better than the popular scripting languages when concurrency is important.