8 ms·

Apps and sites are pushed out fast, crammed with the everything including the kitchen sink and monetised to the hilt. This is more the reason why they suck thes

Apps and sites are pushed out fast, crammed with the everything including the kitchen sink and monetised to the hilt. This is more the reason why they suck these days, rather than because programmers are modelling abstractions from the human end rather than the machine end.

cercatrova 6y ago
And yet Ruby has a global interpreter lock and is an interpreted language. Ruby, I assume as a language, has had all the time in the world to develop well. Why don't we fully utilize our hardware while still allowing for high usability such as with Rust with algebraic data types or (if you don't want to deal with a borrow checker) recent C++ with auto pointers, or Haskell which is garbage collected but is still quite fast and of course highly expressive?
- pmontra 6y ago
  IMHO the answer is that Rust, C++ and Haskell are out there and anybody can use them to build a web site. Maybe the real question is why there are developers the prefer coding in Ruby. In my case, I barely used C++ in the mid 90s and only read some examples of Rust and Haskell. I can't really tell anything about Haskell. Rust and C++ look too hard to use, I don't want to care anymore about all that micromanagement stuff. I'm really with Matz on this. I'm not with him on making types more prominent in Ruby. They are also micromanagement and I don't plan to use those new features. There are plenty of languages with that kind of typing, there is no need to have another one. Actually I'm doing most of my money with Elixir and Python now. Elixir is nice except for deployment, like all the compiled languages I know. Python is much like Ruby but with weird design choices. Oh well, I guess that people coming from Python could say that the weird one is Ruby.
  - pjmlp 6y ago
    So are JVM and .NET languages. Want Ruby with Java like performance? Pick Groovy.
    - Rochus 6y ago
      Or Crystal (http://crystal-lang.org http://crystal-lang.org). It's about factor 20 faster than JIT MRI Ruby 3.0, see http://software.rochus-keller.ch/are-we-fast-yet_crystal_ruby_2_3_lua_node_i386_results_2020-12-23.pdf http://software.rochus-keller.ch/are-we-fast-yet_crystal_rub....
      - vips7L 6y ago
        Except it has no ecosystem or jobs
        Rochus 6y ago
        This will change over time. There are already several companies using Crystal in projects. As they say, typically, it doesn't take many changes to migrate Ruby code to Crystal.
        eropple 6y ago
        "It doesn't take many changes" unless you're using Ruby for the things Ruby is good at: dynamic generation and metaprogramming. If you're not, you can port to anything and it'll be roughly equivalent and having a static language in Ruby's clothes doesn't scratch much of an itch. TBH, having evaluated it, I don't see a great argument for using Crystal in 2020 unless the criterion is "I want to use Crystal." Which is defensible, if that's how you want to roll, but it doesn't make for a good porting argument.
        Rochus 6y ago
        > If you're not, you can port to anything and it'll be roughly equivalent and having a static language in Ruby's clothes doesn't scratch much of an itch. There are a couple of reports about successful ports, e.g. https://forum.crystal-lang.org/t/experience-porting-a-ruby-web-app-to-crystal/2223 https://forum.crystal-lang.org/t/experience-porting-a-ruby-w.... > I don't see a great argument for using Crystal in 2020 There is still the Ruby-like syntax appreciated by many developers and Crystal has also some other interesting aspects not present in Ruby or imperative OO languages in general, e.g. union types, powerful macros (see e.g. https://github.com/sam0x17/mongo_orm/blob/master/src/mongo_orm/fields.cr https://github.com/sam0x17/mongo_orm/blob/master/src/mongo_o...).
  - cercatrova 6y ago
    So you haven't used the languages I listed but you want to judge them? No shame in that but if you want to ask why people use Ruby, I'd say you answered your own question, it's due to inertia, and if you actually want to compare these other languages, you have to actually use them to some non-trivial extent. And I'd also say a big one is Rails, I'm not sure of many people who use Ruby outside of Rails. But that is because they're using Rails despite it being in Ruby, not necessarily because of it, because again, they're more interested in the features that Rails provides rather than being enamored with any language feature per se.
    - pmontra 6y ago
      No way, I learned Ruby after 20 years of programming. Languages that earned me money before Ruby: C, Perl, Delphi (or something on DOS similar to it), Visual Basic, a little Visual C++, PHP, Java, JavaScript, even some Cobol plus a number of other languages for fun (hello to Postscript, Tcl, Forth, Pascal, BCPL, several assemblys and too many others to remember). Ruby was so much better. Garbage collection as in all interpreted languages, no types to write and a number of niceties that made me happy. As you wrote, I started with Ruby because of Rails and I slowly migrated all my scripts from Perl to Ruby. Ruby is the language I use for my projects, plus some Node when I have to. Everything else is too hard, life is too short to waste it wrestling with those other languages. If I had to write something very parallel I'd go with Elixir. We'll see what Ruby's Ractors will bring to us.
      - cercatrova 6y ago
        The fact of the matter is, Ruby and Python are badly implemented, speed wise. The other commentor states more about this. JS is super fast with a JIT but Ruby and Python are still stuck with slow implementations.
        KronisLV 6y ago
        Seems about right. Luckily, if performance becomes an issue, you can probably scale out horizontally, or perhaps if you don't care much about sticking to the reference implementations, you can consider using alternative ones. For example, there are benchmarks of some of the Ruby implementations here: https://pragtob.wordpress.com/2020/08/24/the-great-rubykon-benchmark-2020-cruby-vs-jruby-vs-truffleruby/ https://pragtob.wordpress.com/2020/08/24/the-great-rubykon-b... And here's a paper from 2016 comparing some of the Python implementations: http://kth.diva-portal.org/smash/get/diva2:912464/FULLTEXT01 http://kth.diva-portal.org/smash/get/diva2:912464/FULLTEXT01 Of course, performance in real world scenarios and when using larger frameworks (such as Ruby on Rails or Django) may differ from synthetic benchmarks, but it's nice that at least there's work done in creating these alternative implementations. A bit like how we have Hotspot and OpenJ9 for Java as well or even how there's glibc and musl - that way you can choose which implementation is the most suited for your needs, be it for performance reasons or others...
  - pizza234 6y ago
    > I'm not with him on making types more prominent in Ruby. They are also micromanagement and I don't plan to use those new features I agree with the general argument, except this - keep in mind that typing in Ruby is optional (and will always be). So devs who choose not to use it, they won't suffer any downside. There are also middle grounds - typing can be added gradually or locally. Keep in mind though, that as projects grow large, handling dynamic languages becomes more and more challenging, and adding types is a good strategy to handle that.
  - pdimitar 6y ago
    Ironically I find the lack of static typing in Elixir (and thus Erlang) its greatest weakness. Dynamic typing only gets you so far. Once you get beyond a certain scale of your project (number of lines, files, modules etc.) then static typing a sanity saver. I still love Elixir to death but the lack of static typing isn't making it favours.
    - cercatrova 6y ago
      Have you seen Gleam Lang? It's like Haskell but on BEAM. I was looking into it but I decided that since there's next to no ecosystem for it, I might as well go with something like Rust. https://github.com/gleam-lang/gleam https://github.com/gleam-lang/gleam
      - pdimitar 6y ago
        Yep, I did. Wanted to make Phoenix projects with it but it turned out to be way too laborious, so gave up. Elixir has some problems but it's still much superior to Gleam.
        cercatrova 6y ago
        Yeah true. For me I couldn't stand Elixir's dynamic typing and switched to Rust. I just feel personally like I can't use dynamically typed languages anymore.
        pdimitar 6y ago
        I don't see them at odds. They are mutually complementary. You can go very far with a fantastic dynamic language like Elixir. The loosely shaped data that bombard your app from the net is a perfect fit for a dynamic language. And the OTP concurrency / parallelism approach as well: you can have an actor per connection (while languages like Python and Ruby and PHP have struggled with thread pools and dynamic limits for ages). I am starting to love Rust but again, I don't see it as a competition to Elixir.
        dnautics 6y ago
  - cavalcanti 6y ago
    I agree with you in the past Elixir deployment was a bit complicated, you needed to install packages and such, but today IMO it's well supported by the language and simple to do, `mix release` and voilà.
- pjmlp 6y ago
  Fully agree, using Tcl as Apache/IIS plugin in our own AOLServer inspired application server, while a pleasant experience, has taught me to never again use scripting languages for anything other than OS scripting tasks.
tachyonbeam 6y ago
Hm, it's also because we use dynamic languages with shitty implementations. JavaScript has been optimized to hell, it has a proper JIT compiler, and it's extremely fast, about half the speed of C in many cases. Python and Ruby are inexcusably slow in comparison. We have the technology to make them fast, but the language implementations were born in the 1990s, at a time where everybody thought single-core performance would always double every 18 months. It's this kind of "performance doesn't matter" mentality that lead to poor implementations and a huge waste of CPU cycles. IMO, those languages will inevitably be displaced for performance reasons. It will take time, but it's inevitable.
- pdimitar 6y ago
  It's already happening. On the C++ side we have Rust, Zig, maybe Nim, Haskell. On the dynamic side we have Elixir. Problem is the unwillingness of the market to move. But it's happening, I am witnessing it while I am contracting.
  - dunefox 6y ago
    On the dynamic side there was always Lisp. Very efficient, very dynamic, extremely cool.
    - pdimitar 6y ago
      I do like LISP, don't get me wrong, but the lack of speed and modern multicore support (actors and transparent parallelization like in Erlang/Elixir) has always put me off. Maybe I am getting old but I started to be skeptical about language features and power if at the end I can't make it max all CPU cores and use async I/O everywhere. I think we all could use a bit more pragmatism. I for one don't like Rust but I am relentlessly investing in mastering it because I do need low-level statically typed and compiled language and I still have PTSD from C/C++. F.ex. I loved Racket. It is an amazing language and extremely well-crafted and thought out. But, call me when they have Erlang/Elixir's processes (actors) and preemptive scheduling.
      - 6y ago
pdimitar 6y ago
Both are correct IMO: what you said plus the fact that most programmers won't ever write any sort of efficient code.

cercatrova 6y ago

And yet Ruby has a global interpreter lock and is an interpreted language. Ruby, I assume as a language, has had all the time in the world to develop well. Why don't we fully utilize our hardware while still allowing for high usability such as with Rust with algebraic data types or (if you don't want to deal with a borrow checker) recent C++ with auto pointers, or Haskell which is garbage collected but is still quite fast and of course highly expressive?

pmontra 6y ago
IMHO the answer is that Rust, C++ and Haskell are out there and anybody can use them to build a web site. Maybe the real question is why there are developers the prefer coding in Ruby. In my case, I barely used C++ in the mid 90s and only read some examples of Rust and Haskell. I can't really tell anything about Haskell. Rust and C++ look too hard to use, I don't want to care anymore about all that micromanagement stuff. I'm really with Matz on this. I'm not with him on making types more prominent in Ruby. They are also micromanagement and I don't plan to use those new features. There are plenty of languages with that kind of typing, there is no need to have another one. Actually I'm doing most of my money with Elixir and Python now. Elixir is nice except for deployment, like all the compiled languages I know. Python is much like Ruby but with weird design choices. Oh well, I guess that people coming from Python could say that the weird one is Ruby.
- pjmlp 6y ago
  So are JVM and .NET languages. Want Ruby with Java like performance? Pick Groovy.
  - Rochus 6y ago
    Or Crystal (http://crystal-lang.org http://crystal-lang.org). It's about factor 20 faster than JIT MRI Ruby 3.0, see http://software.rochus-keller.ch/are-we-fast-yet_crystal_ruby_2_3_lua_node_i386_results_2020-12-23.pdf http://software.rochus-keller.ch/are-we-fast-yet_crystal_rub....
    - vips7L 6y ago
      Except it has no ecosystem or jobs
      - Rochus 6y ago
        This will change over time. There are already several companies using Crystal in projects. As they say, typically, it doesn't take many changes to migrate Ruby code to Crystal.
        eropple 6y ago
        "It doesn't take many changes" unless you're using Ruby for the things Ruby is good at: dynamic generation and metaprogramming. If you're not, you can port to anything and it'll be roughly equivalent and having a static language in Ruby's clothes doesn't scratch much of an itch. TBH, having evaluated it, I don't see a great argument for using Crystal in 2020 unless the criterion is "I want to use Crystal." Which is defensible, if that's how you want to roll, but it doesn't make for a good porting argument.
        Rochus 6y ago
        > If you're not, you can port to anything and it'll be roughly equivalent and having a static language in Ruby's clothes doesn't scratch much of an itch. There are a couple of reports about successful ports, e.g. https://forum.crystal-lang.org/t/experience-porting-a-ruby-web-app-to-crystal/2223 https://forum.crystal-lang.org/t/experience-porting-a-ruby-w.... > I don't see a great argument for using Crystal in 2020 There is still the Ruby-like syntax appreciated by many developers and Crystal has also some other interesting aspects not present in Ruby or imperative OO languages in general, e.g. union types, powerful macros (see e.g. https://github.com/sam0x17/mongo_orm/blob/master/src/mongo_orm/fields.cr https://github.com/sam0x17/mongo_orm/blob/master/src/mongo_o...).
- cercatrova 6y ago
  So you haven't used the languages I listed but you want to judge them? No shame in that but if you want to ask why people use Ruby, I'd say you answered your own question, it's due to inertia, and if you actually want to compare these other languages, you have to actually use them to some non-trivial extent. And I'd also say a big one is Rails, I'm not sure of many people who use Ruby outside of Rails. But that is because they're using Rails despite it being in Ruby, not necessarily because of it, because again, they're more interested in the features that Rails provides rather than being enamored with any language feature per se.
  - pmontra 6y ago
    No way, I learned Ruby after 20 years of programming. Languages that earned me money before Ruby: C, Perl, Delphi (or something on DOS similar to it), Visual Basic, a little Visual C++, PHP, Java, JavaScript, even some Cobol plus a number of other languages for fun (hello to Postscript, Tcl, Forth, Pascal, BCPL, several assemblys and too many others to remember). Ruby was so much better. Garbage collection as in all interpreted languages, no types to write and a number of niceties that made me happy. As you wrote, I started with Ruby because of Rails and I slowly migrated all my scripts from Perl to Ruby. Ruby is the language I use for my projects, plus some Node when I have to. Everything else is too hard, life is too short to waste it wrestling with those other languages. If I had to write something very parallel I'd go with Elixir. We'll see what Ruby's Ractors will bring to us.
    - cercatrova 6y ago
      The fact of the matter is, Ruby and Python are badly implemented, speed wise. The other commentor states more about this. JS is super fast with a JIT but Ruby and Python are still stuck with slow implementations.
      - KronisLV 6y ago
        Seems about right. Luckily, if performance becomes an issue, you can probably scale out horizontally, or perhaps if you don't care much about sticking to the reference implementations, you can consider using alternative ones. For example, there are benchmarks of some of the Ruby implementations here: https://pragtob.wordpress.com/2020/08/24/the-great-rubykon-benchmark-2020-cruby-vs-jruby-vs-truffleruby/ https://pragtob.wordpress.com/2020/08/24/the-great-rubykon-b... And here's a paper from 2016 comparing some of the Python implementations: http://kth.diva-portal.org/smash/get/diva2:912464/FULLTEXT01 http://kth.diva-portal.org/smash/get/diva2:912464/FULLTEXT01 Of course, performance in real world scenarios and when using larger frameworks (such as Ruby on Rails or Django) may differ from synthetic benchmarks, but it's nice that at least there's work done in creating these alternative implementations. A bit like how we have Hotspot and OpenJ9 for Java as well or even how there's glibc and musl - that way you can choose which implementation is the most suited for your needs, be it for performance reasons or others...
- pizza234 6y ago
  > I'm not with him on making types more prominent in Ruby. They are also micromanagement and I don't plan to use those new features I agree with the general argument, except this - keep in mind that typing in Ruby is optional (and will always be). So devs who choose not to use it, they won't suffer any downside. There are also middle grounds - typing can be added gradually or locally. Keep in mind though, that as projects grow large, handling dynamic languages becomes more and more challenging, and adding types is a good strategy to handle that.
- pdimitar 6y ago
  Ironically I find the lack of static typing in Elixir (and thus Erlang) its greatest weakness. Dynamic typing only gets you so far. Once you get beyond a certain scale of your project (number of lines, files, modules etc.) then static typing a sanity saver. I still love Elixir to death but the lack of static typing isn't making it favours.
  - cercatrova 6y ago
    Have you seen Gleam Lang? It's like Haskell but on BEAM. I was looking into it but I decided that since there's next to no ecosystem for it, I might as well go with something like Rust. https://github.com/gleam-lang/gleam https://github.com/gleam-lang/gleam
    - pdimitar 6y ago
      Yep, I did. Wanted to make Phoenix projects with it but it turned out to be way too laborious, so gave up. Elixir has some problems but it's still much superior to Gleam.
      - cercatrova 6y ago
        Yeah true. For me I couldn't stand Elixir's dynamic typing and switched to Rust. I just feel personally like I can't use dynamically typed languages anymore.
        pdimitar 6y ago
        I don't see them at odds. They are mutually complementary. You can go very far with a fantastic dynamic language like Elixir. The loosely shaped data that bombard your app from the net is a perfect fit for a dynamic language. And the OTP concurrency / parallelism approach as well: you can have an actor per connection (while languages like Python and Ruby and PHP have struggled with thread pools and dynamic limits for ages). I am starting to love Rust but again, I don't see it as a competition to Elixir.
        dnautics 6y ago
- cavalcanti 6y ago
  I agree with you in the past Elixir deployment was a bit complicated, you needed to install packages and such, but today IMO it's well supported by the language and simple to do, `mix release` and voilà.
pjmlp 6y ago
Fully agree, using Tcl as Apache/IIS plugin in our own AOLServer inspired application server, while a pleasant experience, has taught me to never again use scripting languages for anything other than OS scripting tasks.

tachyonbeam 6y ago

Hm, it's also because we use dynamic languages with shitty implementations. JavaScript has been optimized to hell, it has a proper JIT compiler, and it's extremely fast, about half the speed of C in many cases. Python and Ruby are inexcusably slow in comparison. We have the technology to make them fast, but the language implementations were born in the 1990s, at a time where everybody thought single-core performance would always double every 18 months. It's this kind of "performance doesn't matter" mentality that lead to poor implementations and a huge waste of CPU cycles. IMO, those languages will inevitably be displaced for performance reasons. It will take time, but it's inevitable.

pdimitar 6y ago
It's already happening. On the C++ side we have Rust, Zig, maybe Nim, Haskell. On the dynamic side we have Elixir. Problem is the unwillingness of the market to move. But it's happening, I am witnessing it while I am contracting.
- dunefox 6y ago
  On the dynamic side there was always Lisp. Very efficient, very dynamic, extremely cool.
  - pdimitar 6y ago
    I do like LISP, don't get me wrong, but the lack of speed and modern multicore support (actors and transparent parallelization like in Erlang/Elixir) has always put me off. Maybe I am getting old but I started to be skeptical about language features and power if at the end I can't make it max all CPU cores and use async I/O everywhere. I think we all could use a bit more pragmatism. I for one don't like Rust but I am relentlessly investing in mastering it because I do need low-level statically typed and compiled language and I still have PTSD from C/C++. F.ex. I loved Racket. It is an amazing language and extremely well-crafted and thought out. But, call me when they have Erlang/Elixir's processes (actors) and preemptive scheduling.
    - 6y ago

pdimitar 6y ago

Both are correct IMO: what you said plus the fact that most programmers won't ever write any sort of efficient code.