Live data from Hacker News

Rails 5.0: Action Cable, API mode, and more

weblog.rubyonrails.org

111–120 of 225 posts

Re: Rails 5.0: Action Cable, API mode, and more

#111
post #85

Concurrency aside, why is Elixir preferred over Ruby when it doesn't even have a native array implementation? No, lists and tuples are no substitute nor are maps with numeric keys as Jose has suggested. If you want an array in Elixir your only option is Erlang's implementation which ain't pretty - http://erlang.org/doc/man/array.html . When I raised this issue in the mailing list and on IRC the response was invariabl…

In all your replies, you haven't given concrete example of "I need arrays because tuples or lists can't do X".

Complaining in the abstract isn't helpful.

If Elixir had arrays, why would that be better than using other enumerables like lists or tuples?

Re: Rails 5.0: Action Cable, API mode, and more

#112
post #94

Earlier quoted context omitted.

That saving of $150 is equivalent to one hour of pro dev work time. It's hardly worth converting unless Elxir / Phoenix is much more productive and maintainable.

> That saving of $150 is equivalent to one hour of pro dev work time. Fair point, unless you have more customers. Then it can start to add up quickly. And by customers it means requests as well. Being able to handle large traffic spikes and continous connections is a game change from what I found. Moreover. A huge benefit is using the BEAM VM, I use Erlang (but same VM) and I have seen major advantages being able to…

> Being able to handle large traffic spikes and continous connections is a game change from what I found

This isn't specific to Elixir/Phoenix/Beam.

> Some parts of the cluster would be crashing and restarting for a while, and there would be no need to wake everyone up

Like any well-designed system that separates concerns. Again, this isn't language or framwork-specific.

This stuff is what frustrates me most about the vocal early adopting crowd. If it makes your team vastly more productive, that sounds like a great win for you. If you subjectively like it better, that's also perfectly valid. But citing resilience, efficiency, scalability, and handling traffic spikes seems thin -- these are all things that can easily be attained with just about any well-factored system on any number of languages/frameworks.

Get off my lawn.

Re: Rails 5.0: Action Cable, API mode, and more

#113
post #86

I am very jealous as a Django developer. They decided to keep Channels as a third-party package after all, maintained by a single guy :(

It seems to be taking more of a South approach, and I really like this. Shake out conceptual issues, find an API that works well, iterate a bunch. Django release cadence is pretty slow, so having it simmer outside of it makes a ton of sense.

If it's a big hit like South was, it'll get rolled in and we won't have to immediately start deprecating things due to an un-tried design.

Re: Rails 5.0: Action Cable, API mode, and more

#114
I know that lots of other languages / frameworks compete these days for the title of "most-cutting-edge", but I love working with Rails. There's a lot to be said for the "stability without stagnation" approach. I come from a design background, did not study computer science, and am usually working as a team of one. Rails lets me leverage very finite amounts of time and theoretical knowledge into working software that is elegant, testable, and comprehensible. It is an amazing piece of technology, and I'm happy to see it's still going strong!

Re: Rails 5.0: Action Cable, API mode, and more

#115
post #75
post #54

Earlier quoted context omitted.

Exactly this. It's easy to do 'rails new' and push to Heroku, but when you've got redis, memcache, the worker process & scheduler etc etc you're really maintaining your own ecosystem. It's a lot of where time gets spent on production Rails apps. Here's that slide, I believe: http://i.imgur.com/QzTCJS8.png

So NIH is the appealing factor of Elixir according to this slide?

No.

In a Rails system you've got Rails running, maybe across X number of instances with Unicorn or whatever, sitting behind nginx. If you want to have a long-running request or websocket you've typically used Go or Node or Elixir. If you need to store state between requests you may be using Redis. For background jobs and general async things you've probably got something like Sidekiq.

Erlang already has an http server that Elixir apps are using now, it's called Cowboy. It's not that Elixir is creating their own just because. One of the reasons nginx is often used for Rails apps is to handle static assets, because Rails just isn't as well-equipped to handle those. Cowboy seems to be fine with handling static assets, so a lot of people just take nginx out of the equation for an Elixir app.

Typically Rails apps have used something else like Node or Go or Elixir for long-running requests or websockets. Maybe that will change with ActionCable, maybe not. Either way, Elixir/Phoenix happen to be quite good at this already. Phoenix's equivalent to ActionCable is called Phoenix Channels and it's able to handle 2 million+ websocket connections on a single server, which is pretty cool I think.

Rails apps use redis to manage state between requests. Elixir apps just don't need something like this. Elixir doesn't have something different, it just happens to be easy to store state between requests already.

Rails apps may use Sidekiq or something to deal with background jobs or async operations. This is another case where Elixir doesn't have anything special to occupy that role in the stack, it just happens to be good at that already.

Most of these properties are things that Elixir inherited from Erlang, which has been around for years. I wish I had started learning Erlang a long time ago but unfortunately it just wasn't really on my radar. But really the only thing on this list which is a relatively recent thing is Phoenix Channels, and I don't think that's really a NIH thing. At least, certainly not any more than ActionCable is.

Re: Rails 5.0: Action Cable, API mode, and more

#116
post #10
post #7

Looks like a solid and and relatively straightforward upgrade from Rails 4.2. It's hard not to feel Rails has become a bit of a slow-moving behemoth though, with this release four years after 4.0. I've still got a couple clients using 3.2 from 2012 and things aren't that different. Smart money at this point seems like a significant portion of the Rails community could begin moving to Elixir/Phoenix over the coming ye…

Unless they're able to pull off 3x3 in the next year, I expect Ruby/Rails will start to lose a lot of mind-share. *edit: For clarification, I use Ruby every day and I think its awesome! However, I don't want to see it lose popularity the way Pearl did. I'm concerned that if the language doesn't continue to innovate and improve, that I will lose ground. Lots of new languages have similarly great ergonomics, but get co…

Not sure why you're being downvoted for having an opinion. I think Ruby and Rails became the Java of the late 2000's. There's going to be lots of jobs and work for it for many decades to come. But I feel that slowly newer technologies are supplanting it. Such is the way of all technology, though.

Re: Rails 5.0: Action Cable, API mode, and more

#117
post #86

I am very jealous as a Django developer. They decided to keep Channels as a third-party package after all, maintained by a single guy :(

Channels will eventually be part of Django core; it just didn't make the 1.10 release.

https://groups.google.com/forum/#!topic/django-developers/QR...

Re: Rails 5.0: Action Cable, API mode, and more

#118
post #92
post #88

Earlier quoted context omitted.

I've just started learning Elixir out of interest so I can't quite answer your question. However, I'd like to ask: what have you found to be difficult to do using the Elixir types such as tuples, list, keyword lists, and maps that would otherwise be easy to do using arrays? I'm asking out of genuine curiosity because I've specifically noticed a lack of arrays when learning Elixir and I'm quite used to using them in o…

Elixir has no native array syntax nor any array functions in the stlib so arrays are basically second class citizens rather than completely absent. Ask not why I need them but why anyone might need them if the Elixir is supposed to be a general purpose language. Why does Clojure need them or Ruby or Python (lists)? If I want to process data as a large indexed array Elixir isn't going to help me and some Elixir devs h…

> Elixir has no native array syntax nor any array functions in the stlib

There is no native array syntax, but there are array functions in the stdlib:

http://erlang.org/doc/man/array.html

Re: Rails 5.0: Action Cable, API mode, and more

#119
post #67

By looking at the comments you'd assume a new version of Phoenix got released.

Agreed. It's getting pretty annoying. Every Rails post that hits the front page now feels like it's getting hijacked/side-tracked by Elixir/Phoenix evangelists.

Well a few years back it was hijacked by the Node evangelists. People always have to advocate for their newest toy(s).
Post reply on HN