Just curious.
How come phoenix is even slower than php5 and go?
Is it because of BEAM aka virtual machine? interpreted and native code always faster?
Just curious.
How come phoenix is even slower than php5 and go?
Is it because of BEAM aka virtual machine? interpreted and native code always faster?
Something is off by a huge margin prob some incorrect setup they have PHP5 running faster than node almost on par with Go . For something resembling real world app Phoneix +/- about the speed of Gin (Go).
I actually think Go is interesting, but more for all-or-nothing kind of programs which take some input, chew on it, and spit out the result in some finite time. In such cases, properties such as fault-tolerance or high-availability are not needed, so it makes more sense to focus on say raw processing speed. If I had such needs, Iād certainly consider Go, since it could help me boost performance, easily take advantage of all CPU cores, and still keep my sanity in the process In fact, I can even see some valid scenarios for integrating Go programs into the main BEAM system.
But I wouldnāt recommend it as the main tool for building software systems (i.e. backends), since it has no support for fault-tolerance, soft real-time, stable latency, distributed systems, and high-availability. IMO itās simply not built for that job.
Very true but Google is using it in a lot of cases for precisely the scenarios you wouldnāt recommend it for, they obviously have the resources to allocate to solve those issues but it seams using Erlang/Elixir for control layer would have been easier and NIH played a major role in making that decision. We can see a much less successful version unfolding with NG2 where they allocated ungodly amount of resources and couldnāt deliver anything stable so they just rebranded what should not have even being called an RC into a final release.
Rust.
I am well known to be against Go, but i have reasons. I really think that Go is on the wrong side of most decision for these type of āfast, single threaded with few need for fault tolerance thingsā. It takes the approach of āif it can be wrong in a way, make it awfuyl for everyone, because programming have to be hard.ā
I really think Go tools and programs are gonna leave the same memory than Perl (or ColdFusion ā¦) did.
Rust is far closer to what i think would be the path toward what C++ should have been.
I have the same thoughts by looking at it. Its channels seem to have a bit of inverted handling compared to single mailboxes. Plus its Cāisms are still showing too much.
I really like rust. Sure it is still low level and a bit verbose due to the lifetime tracking, but if it compiles and you do not use āunsafeā then you can be sure that you will not crash at least unless you explicitly throw an exception or something, which it does have be very explicit.
Go is better Node.js. Rust is better C++. I think everybody will find something for them self
If you need something close to bare metal with full control of memory management you will go with Rust.
Drobox are using both languages http://techstacks.io/dropbox
If Google needs distributed fault tolerant service with Go it will put it in some container orchestration service like kubernetes. So it doesnāt need to put this functionality into language itself.
And there is also one me ma language I can bet on it http://julialang.org/
I just skim thru hashnode tech stacks ā¦ combinations of few things
I just wonderā¦ if i use elixir/phoenix ā¦ do i need to any 3rd party stuff (e.g. socket.io, redis, bull, nginx). Obviously, I still need the database, CDN, front end js e.g. react and the cloud servers.