Rails 5.0: Action Cable, API mode, and more • Hacker News Board

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

#151

Post by sams99 » Fri, Jul 01, 2016, 7:44 AM UTC

sergiotapia wrote: post #80

drchiu wrote: post #79

I personally really love using Rails. It's been very productive for me over the past several years I've been able to make a living off of this. I see a lot of comments here about Elixir/Phoenix. Is the performance gain really that big? I currently serve 2-3 mil requests on Rails per day on around $200 worth of servers with at least one database call per request. In defense of Rails, there are so many libraries out th…

It's around 12 times faster in the general sense. Your mileage may vary. If you spend $200 you could theoretically hosting the same product on $50 worth of hardware.

jeez where are those numbers coming from :)

For Discourse which we host in general we spend HALF the time in database calls and say 20-30% of the time in ActiveRecord bullshit.

Lets say we erased all of the app cost using some magic, we would still only be saving 50%, so twice as fast, now erase some ORM bullshit, say another 50% faster, so at a super ambitious totally unrealistic setting we could be 4x faster.

For applications that spend most of the time in the DB I am not sure how switching languages would give you 12x improvement.

For non-dynamic stuff what is behind rendering don't matter anyway cause you can cache before it even hits the app.

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

#152

Post by RobertKerans » Fri, Jul 01, 2016, 7:45 AM UTC

fchopin wrote: post #78

bratsche wrote: post #51

Earlier quoted context omitted.

I'm still fairly new with Elixir/Phoenix (as I think most of us still are), but so far I feel intuitively that it's more maintainable and I admit that I don't have the experience or numbers to back that up yet. There are some things that you simply must use other tools for in Rails, because it can't maintain state like Erlang can. Once you start adding in these other things, you're no longer just a "Rails app" but yo…

What I use Rails for these days is (1) as a backend to our SPAs, so ActiveRecord, Rails controllers, and a view to serve JS assets and CSS via the Asset Pipeline, and (2) to serve Active Admin. I see there is Ecto, Brunch, and ExAdmin for Phoenix, to cover our primary bases I spoke of, in Elixir/Phoenix. For those that have switched to Phoenix, and have experience with these three- was it as smooth transition? What a…

A Devise equivalent. There are a number of alternatives, but I've found them all a little raw: with many Rails projects, I know I can just add Devise, and be confident it'll Just Work with minimal work. Valim said he wasn't interested in building a Devise equivalent for Phoenix - I think the reasoning was that each context is different enough in its own way that a monolithic one-size-fits-all solution like Devise isn't preferable, which is fair enough. But authentication is a pain, and carefully wiring up slightly immature solutions is a little hairy.

I've found this only really applies to CRUD-like, Rails-like projects, so about half of the projects I've built, so YMMV: it's maybe just me making the jump from Rails and expecting things to be more similar than they are.

Ecto is good; it's not quite an ORM, so there were a few WTFs when I tried to do things the same way, but on balance I prefer the Ecto approach; a Linq-like query language I like better than a [somewhat magic] ORM, the way it seperates concerns is good, and (in common with most of Phoenix) the way it works is pretty transparent. Not quite mature yet, though Ecto 2 seems to cover most of the functionality I found to be missing in 1.x.

I work primarily front-end,and I always had issues with the asset pipeline. I've found Brunch to be fantastic - there are always going to be a few issues when dealing with NPM, but other than that, I think they picked the absolute simplest JS-based task runner, and having direct access to the JS ecosystem is great. Brunch has been almost zero-config for me, has Just Worked with only a few `rm -rf node_modules`

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

#153

Post by IanCal » Fri, Jul 01, 2016, 7:50 AM UTC

cutler wrote: post #92

jswny wrote: 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…

It definitely doesn't fit as a hardcore number crunching language. People do regularly just setup their number-y code in C or similar and call out to it so you can handle the distributed stuff with a language that works well there and the low level stuff with a different one. Similar to numpy/etc. calling to C or FORTRAN libs.

> making it too much of a niche language.

No language will be the "one true language" that excels at everything.

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

#154

Post by kccqzy » Fri, Jul 01, 2016, 7:53 AM UTC

cutler wrote: post #108

KallDrexx wrote: post #104

Earlier quoted context omitted.

How are you planning on accessing it though? If it's iterated over sequentially then a list works perfectly. If it's random access then a map works.

What if I want to push/pop it and also access it randomly by index? PHP gets a lot of stick for making arrays serve double purpose but the Elixir advocates of using maps for array purposes are basically arguing for the same thing, no?

Looks like you want a finger tree.

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

#155

Post by di4na » Fri, Jul 01, 2016, 8:07 AM UTC

cutler wrote: post #108

KallDrexx wrote: post #104

Earlier quoted context omitted.

How are you planning on accessing it though? If it's iterated over sequentially then a list works perfectly. If it's random access then a map works.

What if I want to push/pop it and also access it randomly by index? PHP gets a lot of stick for making arrays serve double purpose but the Elixir advocates of using maps for array purposes are basically arguing for the same thing, no?

Then you are not in functional programming place anymore, and you may want to use an imperative language.

I think it is John Hughes that said "The real question is not 'when should i use functional programming?' but 'when should i use imperative programming?' And the answer is 'When you need random access and complete control of your memory'"

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

#156

Post by neya » Fri, Jul 01, 2016, 8:11 AM UTC

I see a lot of pro-Erlang/Phoenix pushing in here, which is (as a polite reminder) an announcement about the rails framework. Not to say that one shouldn't, just that I think it's deviating from the main topic in hand. Interestingly, I wanted to find out what's the real reason behind these pushes towards Erlang/Phoenix and I realised the discussion is mostly around how you can save a few bucks worth $20-50 by opting for a faster programming language.

Any framework can be tuned to do anything. Rails right now is the only truly comprehensive framework with tight integrations to Coffee, LESS, CSS, etc. As someone who is writing his own framework in Scala, I learned this the hard way after under-estimating how much of work is already done for you in Rails.

If you run a business, then all this small talk shouldn't matter as much as how profitable you are. In the end, if your business failed because of your choice of framework (which usually reflects your philosophy), then you need to fix your business model and not the framework.

As a polite reminder, I'd like to link to an old comment of mine I made at the time of Rails 4.2:

https://news.ycombinator.com/item?id=8201244

Have a great weekend everyone!

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

#157

Post by FooBarWidget » Fri, Jul 01, 2016, 8:15 AM UTC

Passenger author here. Phusion is excited about the Rails 5.0 release! Rails is one of the most productive web frameworks out there, and 5.0 just makes it even better.

We have release various Passenger updates to ensure that Passenger plays well with Rails 5, Action Cable etc:

https://blog.phusion.nl/2016/02/18/passenger-5-0-25/

https://www.phusionpassenger.com/library/config/nginx/action...

However we found a bug in Action Cable yesterday which may cause issues with app servers such as Passenger and Puma. Unfortunately the fix didn't make it into 1.0. I recommend anybody who uses Action Cable to apply our patch locally for now: https://github.com/rails/rails/pull/25615

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

#158

Post by frigo_1337 » Fri, Jul 01, 2016, 8:18 AM UTC

cutler wrote: post #133

tbrooks wrote: post #111

Earlier quoted context omitted.

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?

It would be better because lists are not accessible by index and tuples are only designed for small amounts of data.

...but why do you want to access it by index?

Since you refuse to be more specific, it sounds like you're just not willing to learn the language and the way problems are solved with it.

Expecting mutable C-type arrays in elixir/erlang is like expecting classes and lambdas in an assembly language. It's just not a good fit for what the language was designed to do.

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

#159

Post by mfo » Fri, Jul 01, 2016, 8:26 AM UTC

To my mind the big news is Turbolink, A simple tech to build SPA with the following roots : - the robustness & ecosystem of the rails server side (great testing stack & battle tested backend) - the lightweight approach of rails/javascript, which is opting out of jquery : meaning that SPAs won't have to include jQuery and the whole JS world (client side speed will be greatly enhanced) - the overall simplicity (no huge javascript stack pilling angular, react, redux, flux, webpack etc...).

That's rad.

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

#160

Post by pekk » Fri, Jul 01, 2016, 8:42 AM UTC

iamleppert wrote: post #61

All my new development these days centers around node + browserify/webpack with a react frontend, or just plain javascript for small projects. WebSockets would have been a cool addition four years ago. There is little compelling case for new development. Sorry to be so harsh.

That's fine, and I don't use Rails either - but this post was about Rails. People who use or want to use Rails are likely to benefit from the new features. Even if that number has declined somewhat, it's still a lot of people, that still merits development, it's still a topic of interest to others on HN, and it's easy to avoid if you find that you aren't personally interested.

Besides which, I can't see that a switch from Rails to Node is going to have any strong advantage if you are equally proficient in each. If they're really about the same, this would boil down to "I like JS more than Ruby," which is not about the technology so much as personal feelings.