Earlier quoted context omitted.
...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.
not the OP, but I've had a side project in Elixir and often I wanted to browse/play with some of the last saved models in repl. When I get the collection using `ecto`'s `Repo.all..` I can't just `bets[4]` or `bets[-2]`, I have to do weird gymnastics like `hd(tl(bets |> Enum.reverse))`
Rails 5.0: Action Cable, API mode, and more
171–180 of 225 posts
Re: Rails 5.0: Action Cable, API mode, and more
#172Earlier quoted context omitted.
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.
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.
And not just elixir/Phoenix, but the whole ecosystem around it.
I am relatively new to rails and have been astonished at the number of high quality gems that I can drop in and accelerate development. If I need to build something, my first step is always to google for a gem and see if some kind soul has already solved my problem.
Drupal had some of the same rich libraries, but in my short time working with it, I felt less like a software engineer and more like a software mechanic, piecing together pre built parts. For whatever reason, perhaps rhe emphasis on TDD,rails doesn't make me feel like that (which makes work more enjoyable for me).
All this is to say, I don't have any idea what the elixir/Phoenix ecosystem is like, but until it is sizable, rails has an edge in my book.
Re: Rails 5.0: Action Cable, API mode, and more
#173Earlier 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.
Converting? Absolutely not. A greenfield project? Sure why not, it's a great choice.
Depends on who is building it, who is supporting it after it is built, etc. I have seen companies with "technology sprawl" where project after project was done in the shiny new thing. No thanks, it's an ops and maintenance nightmare.
Not to say you shouldn't choose this solution, just do it with an eye to the future.
Re: Rails 5.0: Action Cable, API mode, and more
#174Earlier quoted context omitted.
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 a…
With ecto you tend to write less n+1 queries(if any ;)) if you use the from: query syntax, thus you can also save db time, there you have it.
You can also write less n+1 queries if you think or god forbid, benchmark and refactor your code.
Re: Rails 5.0: Action Cable, API mode, and more
#175Earlier 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
And here is a Ruby vs Java meme from 2006 or so: http://i.imgur.com/1V6rdWV.jpg . This too shall pass.
What's old is new again!
Re: Rails 5.0: Action Cable, API mode, and more
#176 don't like the use of the same cartoon style on the Rails site that Basecamp uses for it site.
Re: Rails 5.0: Action Cable, API mode, and more
#177Earlier quoted context omitted.
I normally see things like caching as an attempt to overcome poor architecture.
It is, sometimes. But a cache hit in 50-150ns beats the pants off of a round trip to the backing database or microservice, which might take tens of milliseconds. That's 100,000-1,000,000x faster. It's the same reason you'd never find a modern CPU without multiple layers of caching.
That's not the kind of caching GP was referring to, at least not to my reading. I think you'd be hard pressed to find any application level caching that could serve up a cache in the nanosecond range. At best you're looking at sub millisecond range, and that's when the cache lives in memory on the same hardware. Application caching on any modern cloud provider is almost always going to be a network call and best case you're looking at sub-10ms response time. And yes, while I definitely agree that it beats hundreds of ms by a wide margin, it can very easily bite you in the ass if you're not very careful about what gets cached. Caching is a performance hack, pure and simple.
Re: Rails 5.0: Action Cable, API mode, and more
#178Earlier 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…
I would love to see someone take a deep dive into why their Phoenix thing is "so much faster" than with Rails. I mean really look at the whole stack from the VM, to different pieces of the framework like views and DB interaction. Erlang definitely does concurrency well, but it is not that much faster than Ruby in terms of "raw speed". I'd be fascinated to see someone actually do the work and look at where Phoenix is…
[deleted]
Re: Rails 5.0: Action Cable, API mode, and more
#179Earlier quoted context omitted.
Seriously, .or() always felt like a glaring omission.
I wrote it in SQL when I needed it, after all I knew SQL before AR came around. An OR is very rare and probably that's why it landed only in version 5. Another implementation is Post.where(id: [1, 2]) which is SELECT * FROM posts WHERE id IN (1, 2). I guess a db would compile it into exactly the same code (dbs use different terms but that's what it is) but the performances could be different inside AR/Arel.
Post.find([1,2])
Works in Rails 4
Re: Rails 5.0: Action Cable, API mode, and more
#180I 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…
> 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. You're right basically, but the migration wave from rails to phoenix has noticeably started, and it shows. > Interestingly, I wanted to find out what's the real reason behind these pushes towards Erl…
I really like Elixir and Erlang, but haven't found he time to play with Phoenix. But...
> You're right basically, but the migration wave from
> rails to phoenix has noticeably started, and
> it shows.
* Clojure
* Node
* Go