181–190 of 225 posts
Is anyone aware of a site that the memory footprints of default Rails apps? I know that this may not be the greatest indication of the memory footprint in an actual running app, but I feel it'd still be interesting data. It'd have the be segmented by ruby version, of course.
Earlier quoted context omitted.
> 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. People have previously said this about: * Clojure * Node * Go And lots of things before that.
This will be great for, eg, creating reports or receipts in background jobs.
Earlier quoted context omitted.
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. People have previously said this about: * Clojure * Node * Go And lots of things before that.
There is a difference this time. Phoenix and Elixir was created specifically with an eye towards Ruby developers. Jose is working for a Ruby shop from what I understand. Go was C++ ++ or Java++ or Python++, Node was front-end brought to the backend kinds deal (or "you only need to know only language" deal). Clojure is an interesting one, but I haven't gotten much to play with it, so don't have much to say about it.
Earlier quoted context omitted.
> 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. People have previously said this about: * Clojure * Node * Go And lots of things before that.
While you're around: Elixir/Erlang in itself is a rather slow language when it comes to number crunching performance. The canonical way currently is to write NIFs in C for these parts. But if this native code crashes, the reliability promise of BEAM goes out the window. For me it would make much more sense to write native extensions in Rust. Have you ever considered to include a plugin to "mix", Elixir's build tool, that allows one to ship Rust source files alongside the Elixir application, which then at compile time fetch a Rust compiler, compiles the code on the current platform and generates a NIF? This would be so huge.
Earlier quoted context omitted.
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…
Some bigger details why phoenix is so fast despite erlang being a "slow" language: - macros: fancy syntax and "magic" can be resolved at compile-time. Less work to do on runtime. - templates: they get handled at compile-time, too, resulting in functions with blobs of binaries. This matters a lot, since a specific template-binary exists only once throughout the application and gets re-used whenever needed. This way yo…
All well and good, but Erlang/beam code is not that fast.
> templates
Ruby's templates are parsed into code that stays in memory, too, so it's not like they're re-parsed each and every time.
> routing
Perhaps clever use of pattern matching helps here. But my point is: someone should dissect these things in a real-world-ish application to see what's actually true.
> concurrency
Yes, but let's be precise. Everyone knows Erlang's concurrency is way better than Ruby's. The claim was 'fast' though. As well as maintainable, which seems curious given that there are no really old Phoenix apps out there.
I feel bad for Sean Griffin. He spent over a year overhauling the internals of ActiveRecord to add this attributes API. His work dramatically improves coercion and type enforcement for ActiveRecord users. Seems weird for this to only get a non-descriptive bullet point in "other highlights." Here are the docs if anyone is interested: http://edgeapi.rubyonrails.org/classes/ActiveRecord/Attribut...
Earlier quoted context omitted.
Every time I've explored alternatives to try to get those kinds of numbers, it seem the bottleneck is more in the database than the application server.
How granular are your measurements? I'm certainly not calling your experience into question. But I wanted to relay a cautionary tale of my own. On one project my team was convinced that Redis was our bottleneck. Profiling was showing that Redis calls were where the most time was spent. I spent some time looking at the redis-rb source and it does a lot of block nesting (4 or 5 levels for every call, IIRC). So, I tried…
Earlier quoted context omitted.
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. People have previously said this about: * Clojure * Node * Go And lots of things before that.
Sure! But this time (tm) it's different. Phoenix is a direct drop-in replacement for rails, with a bunch of strong benefits on top. Getting productive for a rails developer should be 1-2 weeks max, since one already knows how the framework works conceptually. The truly cool stuff happens when one learns how stuff works beneath the surface. While you're around: Elixir/Erlang in itself is a rather slow language when it…
Uh...
"Drop-in replacement is a term used in computer science and other fields. It refers to the ability to replace one hardware (or software) component with another one without any other code or configuration changes being required and resulting in no negative impacts."
That's not the case at all with Phoenix, nice as it may be.