David, you are totally right. I couldn't say it better. I wasn't aiming to declare this is my stack and it's simply the best. I wanted to share my long experience of chasing one stack to another until I decided I've had enough and I need to "settle down". I thought other developers might benefit from this experience and can relate. I wanted to create discussion around the topic just like the one we're having and get other devs opinions.
I tried to use "I" and not "You" in the article to highlight that this is my personal experience and not a "golden rule" for anyone else. I guess I didn't make it clear enough. There is a use case for every technology!
@shaijut
yeah, the Tech Empower benchmarks is certainly a place to start if we're talking about near raw performance. You've got a lot of options if you're I/O rather than CPU-bound. I don't typically look at those benchmarks until someone points them out, because obviously there's more to technology choices than absolute raw performance -- there's ease of adaptability going into it from where you are and the aforementioned things that I mentioned originally.
I will note that I've never done .NET and I've heard a lot about .NET Core and it's phenomenal for people in that ecosystem.
And you also can't look purely at languages, especially higher level ones like Ruby on their own without also considering the runtime. Ruby can run on the JVM with Rubinius and JRuby, but both are on the JVM offering concurrency, but I've never tried it. The JVM has a plethora of offerings, but the ones I'm familiar with are Scala with Akka (actor-based) and Clojure (LISP) and (CSP/communicating sequential process).
Typically when we're I/O bound, concurrency is something we often reach for and every platform offers their own concurrency model and primitives/facilities to do it with varying degrees of difficulty. Async programming can be very very hard (i.e. debugging data races). I'm looking at Node and Go here.
I would also consider what sort of end-to-end service you're creating/making -- is it web-based? Is it confined to a single machine where you want non-blocking I/O like a CLI? But you did mention cut cost on a cloud provider, like Azure. I can't give you a definitive answer, because the type of I/O you're doing also matters. Right? Are you going over the network? Are you talking about the communication being I/O bound within a VPC (virtual private cloud) where you're doing RPC? Perhaps the bottle-neck (vary rarely) could be the way you're marshaling data, and maybe a switch to binary encoding away from JSON may help with MessagePack, etc.
I am a Full stack .NET Developer, I like to work with C#, Asp.Net Core, SQL, Mongo DB, Azure, JavaScript...
Always eager to learn new technologies. I am here to share, ask & eventually learn.
Curious as to what you perceive to be the thing that would run up costs the most... In e-comm which is a broad term (I've worked in e-comm), most things are just I/O-bound, in my experience, though, but this is NOT a recommendation, I've only been able to compare from going to Ruby (on Rails) to Elixir (Erlang VM). We could serve the same # of requests that we had typically auto-scaled to ~8 machines during peak (high traffic) down to a single machine/host. Your mileage may vary depending on the technologies that you end up selecting. This matters little if you don't build anything at all -- I'd consider it a pre-mature optimization. It's never about pure performance early on, that should only happen when you're at scale and the bottlenecks become glaring, then do they become tackled. It is impossible to solve and design for every use case and what your early consumers do on an e-comm site may be very different from what they do when your site has evolved. Look at Amazon -- it used to just be an online bookstore with no AWS, no platform for individual sellers, etc.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
David, you are totally right. I couldn't say it better. I wasn't aiming to declare this is my stack and it's simply the best. I wanted to share my long experience of chasing one stack to another until I decided I've had enough and I need to "settle down". I thought other developers might benefit from this experience and can relate. I wanted to create discussion around the topic just like the one we're having and get other devs opinions.
I tried to use "I" and not "You" in the article to highlight that this is my personal experience and not a "golden rule" for anyone else. I guess I didn't make it clear enough. There is a use case for every technology!
@shaijut yeah, the Tech Empower benchmarks is certainly a place to start if we're talking about near raw performance. You've got a lot of options if you're I/O rather than CPU-bound. I don't typically look at those benchmarks until someone points them out, because obviously there's more to technology choices than absolute raw performance -- there's ease of adaptability going into it from where you are and the aforementioned things that I mentioned originally.
I will note that I've never done .NET and I've heard a lot about .NET Core and it's phenomenal for people in that ecosystem.
And you also can't look purely at languages, especially higher level ones like Ruby on their own without also considering the runtime. Ruby can run on the JVM with Rubinius and JRuby, but both are on the JVM offering concurrency, but I've never tried it. The JVM has a plethora of offerings, but the ones I'm familiar with are Scala with Akka (actor-based) and Clojure (LISP) and (CSP/communicating sequential process).
Typically when we're I/O bound, concurrency is something we often reach for and every platform offers their own concurrency model and primitives/facilities to do it with varying degrees of difficulty. Async programming can be very very hard (i.e. debugging data races). I'm looking at Node and Go here.
I would also consider what sort of end-to-end service you're creating/making -- is it web-based? Is it confined to a single machine where you want non-blocking I/O like a CLI? But you did mention cut cost on a cloud provider, like Azure. I can't give you a definitive answer, because the type of I/O you're doing also matters. Right? Are you going over the network? Are you talking about the communication being I/O bound within a VPC (virtual private cloud) where you're doing RPC? Perhaps the bottle-neck (vary rarely) could be the way you're marshaling data, and maybe a switch to binary encoding away from JSON may help with MessagePack, etc.
Thanks, Suppose I want to make ecommerce website and host in cloud. Which web framework is best in terms if performance and can cut cloud cost.
Curious as to what you perceive to be the thing that would run up costs the most... In e-comm which is a broad term (I've worked in e-comm), most things are just I/O-bound, in my experience, though, but this is NOT a recommendation, I've only been able to compare from going to Ruby (on Rails) to Elixir (Erlang VM). We could serve the same # of requests that we had typically auto-scaled to ~8 machines during peak (high traffic) down to a single machine/host. Your mileage may vary depending on the technologies that you end up selecting. This matters little if you don't build anything at all -- I'd consider it a pre-mature optimization. It's never about pure performance early on, that should only happen when you're at scale and the bottlenecks become glaring, then do they become tackled. It is impossible to solve and design for every use case and what your early consumers do on an e-comm site may be very different from what they do when your site has evolved. Look at Amazon -- it used to just be an online bookstore with no AWS, no platform for individual sellers, etc.