New to elixir, need some directions input

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?

2 Likes

Something is off by a huge margin :slight_smile: prob some incorrect setup they have PHP5 running faster than node almost on par with Go :slight_smile:. For something resembling real world app Phoneix +/- about the speed of Gin (Go).

4 Likes

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 :slight_smile: 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.

3 Likes

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.

3 Likes

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.

8 Likes

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. :slight_smile:

2 Likes

Go is better Node.js. Rust is better C++. I think everybody will find something for them self :slight_smile:
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/

2 Likes

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.