Go from PHP engineer's perspective
1–10 of 12 posts
Re: Go from PHP engineer's perspective
#2[deleted]
Re: Go from PHP engineer's perspective
#3Another poster riding the Go unicorn. You'll enjoy the ride until you realize your ugly as hell chimera monstrosity got you from A to B a lot faster.
Re: Go from PHP engineer's perspective
#4Another poster riding the Go unicorn. You'll enjoy the ride until you realize your ugly as hell chimera monstrosity got you from A to B a lot faster.
"It was never recommended to decompose a system into microservices while it is not mature enough. While small, a business has to be flexible and react quickly to the opportunities in the market. This is not an ideal environment for building microservices, and more benefits can be achieved by having a monolith instead. PHP with its ecosystem perfectly fits into this strategy."
Re: Go from PHP engineer's perspective
#5Another poster riding the Go unicorn. You'll enjoy the ride until you realize your ugly as hell chimera monstrosity got you from A to B a lot faster.
^ nominated for most confusing comment.
Re: Go from PHP engineer's perspective
#6Java, Python, and even Ruby [1] can get you under 10ms for service responses that actually hit a database, in my experience. But why improve performance by switching to a language that's well suited to the task at hand when you can do it by switching to a language that's hip?
[1] My company ran into a problem where one of our Ruby service responses was taking something about 100ms. We ruled out the database, and the ruby code, and finally discovered that the problem was jumping back and forth between Ruby and C while generating the JSON response from model classes with customized `to_json` behavior. We solved it by traversing the structure in Ruby and turning it into Arrays and Hashes. Back down under 10ms!
Re: Go from PHP engineer's perspective
#7Java, Python, and even Ruby [1] can get you under 10ms for service responses that actually hit a database, in my experience. But why improve performance by switching to a language that's well suited to the task at hand when you can do it by switching to a language that's hip? [1] My company ran into a problem where one of our Ruby service responses was taking something about 100ms. We ruled out the database, and the…
With some work you can write some Java that will easily take a message, parse it, do logic, and reply in under .1ms. Not that useful for a webapp though, databases are kinda cool.
Re: Go from PHP engineer's perspective
#8On the criticisms of PHP on swap, those are way out of date. Swap in php:
list(a, b) = [b, a]
Multiple return values:
[a, b] = function(){ return ["one value", "another"];};
Re: Go from PHP engineer's perspective
#9On the criticisms of PHP on swap, those are way out of date. Swap in php: list(a, b) = [b, a] Multiple return values: [a, b] = function(){ return ["one value", "another"];};
Er, that should be:
list($a, $b) = [$b, $a];
list($a, $b) = (function(){ return ["one value", "another"];})();
Re: Go from PHP engineer's perspective
#10Java, Python, and even Ruby [1] can get you under 10ms for service responses that actually hit a database, in my experience. But why improve performance by switching to a language that's well suited to the task at hand when you can do it by switching to a language that's hip? [1] My company ran into a problem where one of our Ruby service responses was taking something about 100ms. We ruled out the database, and the…
> But why improve performance by switching to a language that's well suited to the task at hand when you can do it by switching to a language that's hip?
Because your question is loaded?