#rust #elixir So am creating a messenger with voice call capabilities app which the user signs up using phone number and so at first i wanted to use Actix so i learned Rust so i thought to myself because well its first i felt its a bit immature to use actix web even though some companies are using Rust but we cant really say the full potential of Rust in a full scale app for example in Discord both Elixir and Rust are used meaning there is equal need for them but for Elixir so many companies use it from Whatsapp, Wechat, etc and this means something for Rust is not ready to go full scale we cant assume all this possibilities when it come Rust. So i decided to go the Erlang way after alot of Thinking so Do you think i made the right decision?Am 19 year programmer so i assume am not experienced as you so your answer or comment would really valuable to me

Next.js is probably the most enjoyable React framework our team could have picked. The development is an extremely smooth process, the file structure is beautiful and organized, and the speed is no joke. Our work with Next.js comes out much faster than if it was built on pure React or frameworks alike. We were previously developing all of our projects in Meteor before making the switch. We left Meteor due to the slow compiler and website speed. We deploy all of our Next.js projects on Vercel.

This basically came down to two things: performance on compute-heavy tasks and a need for good tooling. We used to have a Meteor based Node.js application which worked great for RAD and getting a working prototype in a short time, but we felt pains trying to scale it, especially when doing anything involving crunching data, which Node sucks at. We also had bad experience with tooling support for doing large scale refactorings in Javascript compared to the best-in-class tools available for Java (IntelliJ). Given the heavy domain and very involved logic we wanted good tooling support to be able to do great refactorings that are just not possible in Javascript. Java is an old warhorse, but it performs fantastically and we have not regretted going down this route, avoiding "enterprise" smells and going as lightweight as we can, using Jdbi instead of Persistence API, a homegrown Actor Model library for massive concurrency, etc ...