6 ms·

So what? A company is trying to streamline their process and save costs? Is there any large company at all that hasn't invested in making their tool chain bett

So what? A company is trying to streamline their process and save costs? Is there any large company at all that hasn't invested in making their tool chain better? You talk about it like they are a failure. Lol

pjmlp 3y ago
Costs that wouldn't have happened in first place if a scripting language hadn't been chosen in first place.
- balder1991 3y ago
  What we can’t know is whether they would have been fast enough to tweak their product to their current market without using a scripting language. Companies who do that aren’t sacrificing performance for nothing, scripting languages make a lot of things simpler and closer to the business domain, which cannot be ignored (anybody who’s in a huge project that requires a 30 min. compilation often enough to kill productivity knows what I’m talking about). Besides, you can even use optimized C and get none of the benefits (but still all the drawbacks) because of the algorithms you’re using or your database or something else entirely such as microsservices etc. making differences in language speed negligible. I guess the point is the language speed on backends don’t matter as much as many other things (network, database, architecture setup etc.) and usually the gains you get with your language being faster aren’t high unless you’re in a tight loop or you’re like Amazon where even a few milliseconds gain is more money.
  - pdimitar 3y ago
    > What we can’t know is whether they would have been fast enough to tweak their product to their current market without using a scripting language. Exactly. And I am saying the following as a fan of dynamic languages but let's be realistic: this is practically their ONLY true benefit -- quicker time to market. They lose out on pretty much any other metric, with the exception of also slightly quicker iteration in the day-to-day work.
    - ReflectedImage 3y ago
      In a startup, time to market is everything.
      - pdimitar 3y ago
        True, though I've measured my time to prototype with different languages some months ago and the advantages of PHP / Ruby / Python are oversold. - Ruby on Rails prototype: 2.5 days. - Golang's Gofiber: 4.5 days. - Elixir's Phoenix: 7. - Rust: don't ask (too long lol). - Python's Django (made by a friend): 3.5 days. Not to split hairs here but if you are in a situation where 5 days more for a prototype matter then I am not very sure you would have succeeded even short-term after. Putting your foot in the door can be extremely important, absolutely, but after whipping out a quick MVP you'd likely immediately stumble upon the next obstacle which is not guaranteed to be overcome. As mentioned in my previous comment, the only argument in favor of the fastest-to-prototype languages could be that they allow slightly higher velocity day-to-day as well. But I've worked with PHP and Ruby for a long time, and I've worked with Elixir, Golang and Rust for quite a while now as well and again, that particular advantage of PHP / Ruby / Python (a) does exist, yes, but (b) is not as big as people make it out to be.
        DoesntMatter22 3y ago
        So, wait, all apps are trivial in nature and can be built in less than a week? By your own admission here GO takes nearly twice as long (which is about what I've seen). So if you aren't building a trivial app but instead building something that takes 6 months in Ruby you'd be spending nearly 12 months in go. Sounds like a real significant amount of time if you are rushing to get to market.
- DoesntMatter22 3y ago
  Please tell me what language they should have written it in then? They have a incredibly successful company. What did ruby do to hurt you personally. This whole line is co oketely irrational. You want thier webapp written in assembly?
  - pdimitar 3y ago
    Why resort to a straw man? There are plenty of options between "a language that does not even have strong types" and "machine code"? E.g. Elixir is strongly but dynamically typed and you can take it quite far while reaping most of the benefits of typing and not losing velocity as you would with many statically strongly typed languages. Nuance matters. I wouldn't pick Ruby for anything except scripts nowadays. You get absolutely zero guarantees and being able to whip out an MVP in 2 days is not as important as people make it out to be. Extremely often being able to have an MVP in 10-20 days is just as viable but then you will have to write less tests and have more guarantees from your compiler.
    - DoesntMatter22 3y ago
      It's not a straw man, I'm asking him where he stands. How far does he want to take it? You mentioned Elixir. You literally suggested a language that was created 6 years after Shopify began. You wouldn't pick Ruby, thats your choice. People are still making billions of dollars with it. So, since you took up the mantle, what language should they have used 17 years ago when they started the company?
      - pdimitar 3y ago
        > You wouldn't pick Ruby, thats your choice. People are still making billions of dollars with it. Not arguing with their results here. I am saying that they made it work despite how terrible it is. You have no guarantees about anything and you have to have much more tests than you would have in other languages just so you have basic stuff ensured. Not cool at all and I am saying this as a guy who made good money with Rails for 6.5 years. Not impressed to this day and I am happy I left it behind. It's good for scripting I'll admit, though nowadays I just learned bash/zsh better and use Golang for the same task occasionally. > what language should they have used 17 years ago when they started the company? Whoops, you are 100% correct that I ignored the historical timeline (Elixir didn't exist back then, yes), sorry about that, I derped big time. That being said, all of PHP, Ruby, Python, Java and C# were indeed valid choices back then. But I've been part of successful rewriting efforts (biggest one was about 270k coding lines which I'll admit is much smaller than what Facebook and other big corps are dealing with) and to me the downsides of rewriting are overplayed: - You need extensive tests? Well, you need them even if you never rewrite. - You will now have two systems? So what, you already have a load balancer, you will just put a few more rules in it. - Hard to find engineers for $new_language? That's true if you do it in its first 5 years of life but I've been part of growing ecosystems twice (Elixir and Rust) and it only gets easier with time. Solution: don't be a super early adopter, that's obviously too risky. E.g. both Elixir and Rust are beyond 10 years old at this point and are now a safer choice. - Have to duplicate the old system's bugs? Tough nut to crack and I partially agree with this one but what my previous teams did was write down these bugs in the docs and made sure to start fixing them after the rewrite was completed. And in all cases fixing the bugs in the original language was planned anyway but was eternally kicked down the road. -- My main point here is that it's OK to admit at one point that the tech you used for a while has outgrown its usefulness. I understand and recognize some of the downsides but to me they are overblown.

pjmlp 3y ago

Costs that wouldn't have happened in first place if a scripting language hadn't been chosen in first place.

balder1991 3y ago
What we can’t know is whether they would have been fast enough to tweak their product to their current market without using a scripting language. Companies who do that aren’t sacrificing performance for nothing, scripting languages make a lot of things simpler and closer to the business domain, which cannot be ignored (anybody who’s in a huge project that requires a 30 min. compilation often enough to kill productivity knows what I’m talking about). Besides, you can even use optimized C and get none of the benefits (but still all the drawbacks) because of the algorithms you’re using or your database or something else entirely such as microsservices etc. making differences in language speed negligible. I guess the point is the language speed on backends don’t matter as much as many other things (network, database, architecture setup etc.) and usually the gains you get with your language being faster aren’t high unless you’re in a tight loop or you’re like Amazon where even a few milliseconds gain is more money.
- pdimitar 3y ago
  > What we can’t know is whether they would have been fast enough to tweak their product to their current market without using a scripting language. Exactly. And I am saying the following as a fan of dynamic languages but let's be realistic: this is practically their ONLY true benefit -- quicker time to market. They lose out on pretty much any other metric, with the exception of also slightly quicker iteration in the day-to-day work.
  - ReflectedImage 3y ago
    In a startup, time to market is everything.
    - pdimitar 3y ago
      True, though I've measured my time to prototype with different languages some months ago and the advantages of PHP / Ruby / Python are oversold. - Ruby on Rails prototype: 2.5 days. - Golang's Gofiber: 4.5 days. - Elixir's Phoenix: 7. - Rust: don't ask (too long lol). - Python's Django (made by a friend): 3.5 days. Not to split hairs here but if you are in a situation where 5 days more for a prototype matter then I am not very sure you would have succeeded even short-term after. Putting your foot in the door can be extremely important, absolutely, but after whipping out a quick MVP you'd likely immediately stumble upon the next obstacle which is not guaranteed to be overcome. As mentioned in my previous comment, the only argument in favor of the fastest-to-prototype languages could be that they allow slightly higher velocity day-to-day as well. But I've worked with PHP and Ruby for a long time, and I've worked with Elixir, Golang and Rust for quite a while now as well and again, that particular advantage of PHP / Ruby / Python (a) does exist, yes, but (b) is not as big as people make it out to be.
      - DoesntMatter22 3y ago
        So, wait, all apps are trivial in nature and can be built in less than a week? By your own admission here GO takes nearly twice as long (which is about what I've seen). So if you aren't building a trivial app but instead building something that takes 6 months in Ruby you'd be spending nearly 12 months in go. Sounds like a real significant amount of time if you are rushing to get to market.
DoesntMatter22 3y ago
Please tell me what language they should have written it in then? They have a incredibly successful company. What did ruby do to hurt you personally. This whole line is co oketely irrational. You want thier webapp written in assembly?
- pdimitar 3y ago
  Why resort to a straw man? There are plenty of options between "a language that does not even have strong types" and "machine code"? E.g. Elixir is strongly but dynamically typed and you can take it quite far while reaping most of the benefits of typing and not losing velocity as you would with many statically strongly typed languages. Nuance matters. I wouldn't pick Ruby for anything except scripts nowadays. You get absolutely zero guarantees and being able to whip out an MVP in 2 days is not as important as people make it out to be. Extremely often being able to have an MVP in 10-20 days is just as viable but then you will have to write less tests and have more guarantees from your compiler.
  - DoesntMatter22 3y ago
    It's not a straw man, I'm asking him where he stands. How far does he want to take it? You mentioned Elixir. You literally suggested a language that was created 6 years after Shopify began. You wouldn't pick Ruby, thats your choice. People are still making billions of dollars with it. So, since you took up the mantle, what language should they have used 17 years ago when they started the company?
    - pdimitar 3y ago
      > You wouldn't pick Ruby, thats your choice. People are still making billions of dollars with it. Not arguing with their results here. I am saying that they made it work despite how terrible it is. You have no guarantees about anything and you have to have much more tests than you would have in other languages just so you have basic stuff ensured. Not cool at all and I am saying this as a guy who made good money with Rails for 6.5 years. Not impressed to this day and I am happy I left it behind. It's good for scripting I'll admit, though nowadays I just learned bash/zsh better and use Golang for the same task occasionally. > what language should they have used 17 years ago when they started the company? Whoops, you are 100% correct that I ignored the historical timeline (Elixir didn't exist back then, yes), sorry about that, I derped big time. That being said, all of PHP, Ruby, Python, Java and C# were indeed valid choices back then. But I've been part of successful rewriting efforts (biggest one was about 270k coding lines which I'll admit is much smaller than what Facebook and other big corps are dealing with) and to me the downsides of rewriting are overplayed: - You need extensive tests? Well, you need them even if you never rewrite. - You will now have two systems? So what, you already have a load balancer, you will just put a few more rules in it. - Hard to find engineers for $new_language? That's true if you do it in its first 5 years of life but I've been part of growing ecosystems twice (Elixir and Rust) and it only gets easier with time. Solution: don't be a super early adopter, that's obviously too risky. E.g. both Elixir and Rust are beyond 10 years old at this point and are now a safer choice. - Have to duplicate the old system's bugs? Tough nut to crack and I partially agree with this one but what my previous teams did was write down these bugs in the docs and made sure to start fixing them after the rewrite was completed. And in all cases fixing the bugs in the original language was planned anyway but was eternally kicked down the road. -- My main point here is that it's OK to admit at one point that the tech you used for a while has outgrown its usefulness. I understand and recognize some of the downsides but to me they are overblown.