4 ms·

Flame mode on. Can anybody explain to me why people seem to prefer using unsafe and interpreted/slow languages (Python, Ruby, Javascript... which is only fast

Flame mode on. Can anybody explain to me why people seem to prefer using unsafe and interpreted/slow languages (Python, Ruby, Javascript... which is only fast now because companies have invested millions on it) and then spend a ton of resources writing "type checkers" for these inherently unsafe languages (Typescript, Pyre, Pyright) Why don't they simply use languages that are already safe and fast by design? (Rust, OCaml...)

joatmon-snoo 8y ago
There are many, many libraries that I work with that are written in Python. Things for which a single script was once sufficient, then a few of them, and eventually multiple thousands of lines of code. I'm not going to spend years reimplementing that same logic in some other language. I'm going to build on top of it. Maybe I'll need to make changes to some of the underlying code. Better tooling - which is exactly what type checkers are - makes my life much, much easier and makes me much more productive. Besides, all these languages exist for a reason - you choose the tool appropriate for the problem. "safe and fast" does not make a language automatically better for a problem.
jaabe 8y ago
The most important aspect of development in most companies is the developer him/herself. It’s typically also the most expensive resource tied to development. At least if you look at it from a management perspective. This means that it’s extremely risky to build things in hipster languages because the pool from which you can hire is extremely small. It also means you’ll have to spend a lot of money building tools and libraries that are “just” available in more popular languages. On top of that, most companies don’t need to scale things to the point that Netflix does, and even if you do, PHP was good enough to run Facebook before PHP got fast, Python was good enough to run Reddit, Node is good enough to run Netflix and Ruby was good enough to run Github. I mean, why would you ever chose Rust for your project from a business/management perspective? To save a few bucks on iron while increasing your development costs by hundreds of thousands and making vacant positions impossible to be filled? On the flip side, why would you bother joining a hipster language as a developer? Right now 35% of the jobs in my country are for C#, another 35% is for JAVA, 25% of them are for PHP or Python, the remaining 5% is for every other language but typically c/c++ for robotics. JavaScript/typescript is involved in quite a lot of the positions, but almost no one is doing a JS backend. There isn’t a single OCalm or Rust position available in my entire country. I’m not sure there has ever been a Rust related position. Management doesn’t care about technical reasons, and it never will. Developers tend to go where the jobs are, even if they have hobby projects somewhere else. Maybe Rust will somehow manage to break through, Python did after all. But I think Python had a huge amount of help from being the replacement for JAVA at many universities. I don’t see that happening for Rust.
- quickthrower2 8y ago
  You say 70% of jobs are C#/Java. These are statically typed languages. And they are not hipster. So I guess you kind of agree with the parent comment?
  - jaabe 8y ago
    Maybe, I’m not personally opinionated in either direction. We use more and more JS and Python in our shop, and we have had no issues with dynamic types. On the other hand, that’s very likely because every one of us had been doing either JAVA or C# for 15+ years before we started doing anything serious in dynamic languages. So from a technical perspective I think dynamic languages are equal, maybe even better. From a management perspective though, you have to consider what happens when you hire a developer who didn’t grow up with static types.
tomhoward 8y ago
Each time a discussion on the question "Is Ruby/Rails still relevant in [this year]" comes up around here, an answer to the effect of "Ruby/Rails is still the fastest way to go from zero to working prototype/product" ranks highly. Python and Javascript have different standout attributes but it comes back to the same key point: most people building regular apps/sites/products care primarily about building something functional as fast as possible. It would make sense that productivity would be a primary concern in the earlier stages when it's not yet known whether a product idea is viable. But type safety might become a consideration later as the development team becomes bigger, the codebase becomes more complex, and production reliability becomes an important consideration.
- StaticRedux 8y ago
  Ruby on Rails - fastest from zero to working prototype, fastest from working prototype to unmaintainable nightmare. No one should be surprised when the "language/framework for non-programmers" results in a codebase that was clearly made by non-programmers.
  - tomhoward 8y ago
    I see from another comment that you’re struggling with a difficult-to-maintain Rails codebase, but this comment is needlessly contemptuous and risks making you seem arrogant. It also sounds like the kind of thing that some smug, newly-converted Ruby/Python programmers would say about PHP (I plead guilty on behalf of my 10-ish-years-ago self). I haven’t seen anyone call Ruby/Rails a "language/framework for non-programmers". Nobody asserts that someone can or should try to build a professional-grade app or site without having a solid understanding of programming fundamentals. It’s just a matter of what you optimise for. Rails makes sense in startup land, where it’s more likely that not that what you’re building won’t turn out to be popular, so it’s best to test the concept as fast as possible to avoid wasting any more time than you need to. You can easily rebuild in other languages if you’re lucky enough that scale, performance and maintainability become major problems. I’ve seen that happen at several companies including Twitter and Airbnb, and it makes perfect sense.
namelosw 8y ago
Rust is not fast by design. OCaml is kind of but still not as fast as Ruby for me at least. I spent a lot of time learning Haskell and Scala and I'm still learning. And they never caught up with ruby on rails in terms of velocity for me. One big thing is about the feedback loop. Typesafe so what? Type is type, it's not either value or business invariant. I'm not convinced as long as you're not writing proofs in dependent-type languages like Idris. So, I still prefer REPL that I can sure about in no time, and watching tests every 0.1s after I change the code. One can say interpreted languages are optimized for developing because when you change the code, it can be just run once -- there's no point of compiling it because in the next second you'll be changing it. And compiled languages are optimized for the runtime, because it's compiled it's ready to be run many times. Of course, there are JIT for interpreted languages and interpreted static-typed languages, but Haskell REPL is still pretty slow compared to Slime. And for Rails, you can actually touch anything runtime entity in the console.
- ernst_klim 8y ago
  >it's not either value or business invariant. I'm not convinced as long as you're not writing proofs in dependent-type languages like Idris. Types are proofs in OCaml as well, you don't need dependent types to have Curry-Howard correspondence. You could even prove stuff in Java. And you can ensure invariants with types in OCaml well enough.

joatmon-snoo 8y ago

There are many, many libraries that I work with that are written in Python. Things for which a single script was once sufficient, then a few of them, and eventually multiple thousands of lines of code. I'm not going to spend years reimplementing that same logic in some other language. I'm going to build on top of it. Maybe I'll need to make changes to some of the underlying code. Better tooling - which is exactly what type checkers are - makes my life much, much easier and makes me much more productive. Besides, all these languages exist for a reason - you choose the tool appropriate for the problem. "safe and fast" does not make a language automatically better for a problem.

jaabe 8y ago

The most important aspect of development in most companies is the developer him/herself. It’s typically also the most expensive resource tied to development. At least if you look at it from a management perspective. This means that it’s extremely risky to build things in hipster languages because the pool from which you can hire is extremely small. It also means you’ll have to spend a lot of money building tools and libraries that are “just” available in more popular languages. On top of that, most companies don’t need to scale things to the point that Netflix does, and even if you do, PHP was good enough to run Facebook before PHP got fast, Python was good enough to run Reddit, Node is good enough to run Netflix and Ruby was good enough to run Github. I mean, why would you ever chose Rust for your project from a business/management perspective? To save a few bucks on iron while increasing your development costs by hundreds of thousands and making vacant positions impossible to be filled? On the flip side, why would you bother joining a hipster language as a developer? Right now 35% of the jobs in my country are for C#, another 35% is for JAVA, 25% of them are for PHP or Python, the remaining 5% is for every other language but typically c/c++ for robotics. JavaScript/typescript is involved in quite a lot of the positions, but almost no one is doing a JS backend. There isn’t a single OCalm or Rust position available in my entire country. I’m not sure there has ever been a Rust related position. Management doesn’t care about technical reasons, and it never will. Developers tend to go where the jobs are, even if they have hobby projects somewhere else. Maybe Rust will somehow manage to break through, Python did after all. But I think Python had a huge amount of help from being the replacement for JAVA at many universities. I don’t see that happening for Rust.

quickthrower2 8y ago
You say 70% of jobs are C#/Java. These are statically typed languages. And they are not hipster. So I guess you kind of agree with the parent comment?
- jaabe 8y ago
  Maybe, I’m not personally opinionated in either direction. We use more and more JS and Python in our shop, and we have had no issues with dynamic types. On the other hand, that’s very likely because every one of us had been doing either JAVA or C# for 15+ years before we started doing anything serious in dynamic languages. So from a technical perspective I think dynamic languages are equal, maybe even better. From a management perspective though, you have to consider what happens when you hire a developer who didn’t grow up with static types.

tomhoward 8y ago

Each time a discussion on the question "Is Ruby/Rails still relevant in [this year]" comes up around here, an answer to the effect of "Ruby/Rails is still the fastest way to go from zero to working prototype/product" ranks highly. Python and Javascript have different standout attributes but it comes back to the same key point: most people building regular apps/sites/products care primarily about building something functional as fast as possible. It would make sense that productivity would be a primary concern in the earlier stages when it's not yet known whether a product idea is viable. But type safety might become a consideration later as the development team becomes bigger, the codebase becomes more complex, and production reliability becomes an important consideration.

StaticRedux 8y ago
Ruby on Rails - fastest from zero to working prototype, fastest from working prototype to unmaintainable nightmare. No one should be surprised when the "language/framework for non-programmers" results in a codebase that was clearly made by non-programmers.
- tomhoward 8y ago
  I see from another comment that you’re struggling with a difficult-to-maintain Rails codebase, but this comment is needlessly contemptuous and risks making you seem arrogant. It also sounds like the kind of thing that some smug, newly-converted Ruby/Python programmers would say about PHP (I plead guilty on behalf of my 10-ish-years-ago self). I haven’t seen anyone call Ruby/Rails a "language/framework for non-programmers". Nobody asserts that someone can or should try to build a professional-grade app or site without having a solid understanding of programming fundamentals. It’s just a matter of what you optimise for. Rails makes sense in startup land, where it’s more likely that not that what you’re building won’t turn out to be popular, so it’s best to test the concept as fast as possible to avoid wasting any more time than you need to. You can easily rebuild in other languages if you’re lucky enough that scale, performance and maintainability become major problems. I’ve seen that happen at several companies including Twitter and Airbnb, and it makes perfect sense.

namelosw 8y ago

Rust is not fast by design. OCaml is kind of but still not as fast as Ruby for me at least. I spent a lot of time learning Haskell and Scala and I'm still learning. And they never caught up with ruby on rails in terms of velocity for me. One big thing is about the feedback loop. Typesafe so what? Type is type, it's not either value or business invariant. I'm not convinced as long as you're not writing proofs in dependent-type languages like Idris. So, I still prefer REPL that I can sure about in no time, and watching tests every 0.1s after I change the code. One can say interpreted languages are optimized for developing because when you change the code, it can be just run once -- there's no point of compiling it because in the next second you'll be changing it. And compiled languages are optimized for the runtime, because it's compiled it's ready to be run many times. Of course, there are JIT for interpreted languages and interpreted static-typed languages, but Haskell REPL is still pretty slow compared to Slime. And for Rails, you can actually touch anything runtime entity in the console.

ernst_klim 8y ago
>it's not either value or business invariant. I'm not convinced as long as you're not writing proofs in dependent-type languages like Idris. Types are proofs in OCaml as well, you don't need dependent types to have Curry-Howard correspondence. You could even prove stuff in Java. And you can ensure invariants with types in OCaml well enough.