9 ms·

I have to agree with the dead comment here. Focusing just on people is how we got to the stage of having extremely fast CPUs that can compute billions if not tr

I have to agree with the dead comment here. Focusing just on people is how we got to the stage of having extremely fast CPUs that can compute billions if not trillions of operations and yet websites and apps lag. We can run full fledged games at 240 FPS and yet, websites and apps lag. It truly is heresy to not fully utilize the hardware we create, such a waste, simply because people don't optimize at every step of the process, useless abstraction on top of useless abstraction. In game engines they do, to some extent, because they have to, and so should they in general purpose applications as well.

Santosh83 6y ago
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...).
  - 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.
dragonwriter 6y ago
> It truly is heresy to not fully utilize the hardware we create, Violation of irrational dogma? Certainly is. > simply because people don't optimize at every step of the process Sure they do. Processor efficiency isn't always the target of optimization, often for very good reasons. > In game engines they do, to some extent, because they have to, Yes, because optimizing market value to production cost in that market requires optimizing use of hardware. In lots of other markets it doesn't, and optimizing use of hardware would be an taking on a cost that isn't warranted by delivered value.
- cercatrova 6y ago
  Sure, but the pendulum has swung so far in the "I optimize for dev time not server time" that people are forgetting how to write fast, efficient programs, and we the end users have to put up with that garbage like Electron.
  - dunefox 6y ago
    Electron afaik wasn't created because "people forgot" but because it's by far the easiest way to create a platform independent UI that's heavily customisable.
  - mrgordon 6y ago
    There is this meme that Electron is so bad but as an end user I have much better experiences with Electron apps like Slack and Discord then I do with Microsoft Teams or other competitor apps that don’t use Electron. Is Microsoft Teams supposed to be the fast, efficient alternative because I don’t think so...
    - cercatrova 6y ago
      Teams also uses Electron FYI.
      - mrgordon 6y ago
        Haha guess it wasn’t such a good example then, I had no idea. But I do think Slack or Discord works as well as native Mac apps from the user perspective. I can’t really tell the difference between Atom and say the old Sublime Text or Textmate. If you told me they were all Electron I’d believe you other than Textmate being so old that it couldn’t have been when I used it
tutfbhuf 6y ago
Google might change this, because of ranking penalties for slow websites.
swsieber 6y ago
I think both are needed. I think we've been getting stuff like nim, rust and others because we've had both. They certainly seem to come in waves though. It seems like the equivalent of bulking and cutting.
nthj 6y ago
Web apps are usually slow because of (1) poor data modeling/unoptimized SQL/unindexed tables, (2) ad tracker bloat, and (3) single page applications that reinvent the DOM for $reasons. Swapping out ruby for golang won’t fix any of those. I’ve worked on multiple Rails apps over the past decade, responsible for hundreds of thousands of customers and hundreds of millions in revenue, that easily rendered every page in 150-300ms. This isn’t time-to-first-byte—this is fully rendered, images and all.
- cercatrova 6y ago
  However, fixing all of those, which costs less in server time (and potentially even dev time, debatable)? I've seen hundreds of Rust based sites on a single 5 dollar droplet while the same would take an order of magnitude more servers. At scale, this gets expensive. See Stripe, Shopify etc that have found this out.
  - kyledrake 6y ago
    I run a busy production ruby app on a $40/month droplet. My performance issues are almost never related to ruby. It's nearly 100% of the time some complex database query that needs to get indexed/cached. If coders write their backend in rust for "the ultimate performance", and it's shipping 20MB of javascript to query a poorly designed, poorly indexed database with no caching, they're going to get far worse performance than a ruby app querying a properly designed, cached database with indexing that doesn't have to spend 5 seconds domming the user's DOM first. Performance is a holistic problem, and anecdotally, web sites felt a lot faster during the rails era than they do right now during the JS era.
    - cercatrova 6y ago
      We can do both, I never said one should be prioritized over the other.
      - ryanbrunner 6y ago
        One abosolutely should be prioritized over the other. There's never going to be a situation where you can address every potential source of slowdowns, and make everything 100% efficient all of the time. Given that, in any somewhat realistic environment, you're going to need to prioritize where to spend your focus on making things more efficient. It's certainly possible that the answer is that the language you're using is fundamentally too slow - I personally have almost never experienced that - almost always I can get more out of a time investment by focusing on improving DB performance, or some problem with delivery, caching or optimizing bundles. You should look at your personal situation and use real data to decide where to focus, but you always have to focus. "Make everything 100% efficient at all times" is completely unrealistic.
smarx007 6y ago
Why? Why do we have to make apps run fast? I run a self-hosted install of ArchiveBox and it takes > 10s to archive a webpage. If I am saving the page to retrieve it in a few years, I can surely wait 10-20s. One can say that an optimised setup may load and render a page in under 2s but why? Apps need to fulfill our needs. Nothing more and nothing less. Just like you buy a Nissan Leaf to fulfill your need all while knowing that Bugatti Veyron is one of the fastest cars in the world pushing above 400 km/h. Just like I use ArchiveBox written in Python and SQLite while knowing that there is Rust and RocksDB out there that can outperform Python/SQLite. Side note: I do agree that in some cases product owners take over both user needs and developers' good judgement and turn a good product into a horrid mess but I would argue you can do that in any programming language. Go make yourself some drip coffee on this Christmas day and take it slow! Happy holidays everyone!
- cercatrova 6y ago
  Speed matters. As a matter of UX, it feels good. People can tell when things instantly open up and load versus being sluggish. And it's also a matter of beauty. I like and appreciate things that fully utilize their forms. In software, it's apps that fully utilize the hardware. I was playing Doom Eternal the other day and it was just amazing the fluidity I got.
  - smarx007 6y ago
    > Speed matters I fully agree! But not everywhere and not at all times. > feels good > matter of beauty Well, that's not "matters" as in "must have", rather "nice to have" or "should have". See https://www.librarything.com/ https://www.librarything.com/ for another example where a slow(er) app with high information density is preferred to a "nice" app (eg Apple Books "shelves" that are next to useless compared to this but sure enough, they are nice and fast). > playing Doom Eternal the other day and it was just amazing the fluidity I got. Well, this is where speed truly matters. The whole purpose of a game is to give you experience. Nice UX and fast graphics are a must because it's key to what the game shop is selling you.
    - 6y ago
thurn 6y ago
You would have a hard time naming a AAA game which doesn't have a huge chunk of its actual gameplay logic in a scripting language (or something like Unreal blueprints). There's a huge amount of value in using different tools for the performance-critical parts vs the rest.
blacklight 6y ago
The programming language is often only a (relatively small) part of this problem. The choice of the framework (or, I'd say, the pollution of frameworks, as well as 40 MB libraries only imported to do dependency injection), wrong abstractions, wrong data models (if I'd had a penny for every time I've seen some code do a full list scan when it could have indexed the objects into a map I'd be millionaire by now), over-engineering, frameworks that reinvent the wheel (often in a much less optimal way, all in order to provide the developer with a bit of syntactical sugar), they all play a much bigger role in performance degradation than the language itself. On top of it, projects are often lead by managers that are mostly interested in grabbing the low hanging fruits, pack the product with poorly tested features, set unrealistic deadlines and monetize as fast as possible, and they often don't provide developers time to breathe, take a step back and do any refactoring or optimization - those are too often labelled as purely technical tasks with no business impact and pushed down the priority line. Some of the code written two or three decades ago was much more efficient (especially given the hardware available at the time) than today's projects both because developers were aware of building software for machines with a limited amount of resources, and because the software delivery timelines were much more realistic - aggressive marketing, sales and product departments hadn't yet completely taken over the engineering departments, and while agile methodologies were supposed to mitigate these issues they've actually only shrunk even more the delivery windows and made software development more hectic and shortsighted. 30 years ago a program that would choke on a 386 would be refactored until each single but was optimized for the available resources. Today's approach is simply "just throw more RAM/CPU power" - and that's what I frankly find unacceptable.
- blacklight 6y ago
  Oh, one more reason I forgot in the case of webapps: 3rd-party scripts and trackers. I've been using NoScript for years now, and that forces me to explicitly whitelist any domain used for scripts on a website. Once you start looking at what major websites do, you start to understand the problem. Most of the newspapers on the web, for example, often employ 20 additional script domains on top of their own - for anything from analytics, to tracking, cookie banners, ads, adblock detectors, Hotjar, Taboola, and so on. We often (justifiably) argue that deep learning, as it's done today, is something unsustainable for the environment. I wonder if anyone has ever measured the impact of running tons of non-functional scripts on the web pages rendered every second by billions of devices around the world.
JohnBooty 6y ago
We can run full fledged games at 240 FPS and yet, websites and apps lag This problem is real, but addressing it in the context of Ruby is misguided. Slow websites? It's the overall system design of the web. Running a bunch of untrusted sandboxed code, retrieved asynchronously from potentially dozens of sources? Yeah, that's gonna be slow. Replace all the Rails sites with assembly code running on bare metal if you like, it's not going to change anything. Ruby on Rails is plenty fast. You can serve up static pages in a few milliseconds. If they take longer than that, it's because you're doing a bunch of work at the database layer or some other work outside of Ruby.
andrekandre 6y ago
i think this has less to do with "concentrating on humans" vs machines and more to do with "business requirements" that are ever-changing which causes insufficient time to work on optimization and siplification... all we get are piles of code upon piles of code... the other side of that is in the web, the tech stack was not at all designed for what we are trying to make it do... add those two things together, add a dash of network latency for all the loaded resources, and you easily get what we have today...

Santosh83 6y ago

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...).
- 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.

dragonwriter 6y ago

> It truly is heresy to not fully utilize the hardware we create, Violation of irrational dogma? Certainly is. > simply because people don't optimize at every step of the process Sure they do. Processor efficiency isn't always the target of optimization, often for very good reasons. > In game engines they do, to some extent, because they have to, Yes, because optimizing market value to production cost in that market requires optimizing use of hardware. In lots of other markets it doesn't, and optimizing use of hardware would be an taking on a cost that isn't warranted by delivered value.

cercatrova 6y ago
Sure, but the pendulum has swung so far in the "I optimize for dev time not server time" that people are forgetting how to write fast, efficient programs, and we the end users have to put up with that garbage like Electron.
- dunefox 6y ago
  Electron afaik wasn't created because "people forgot" but because it's by far the easiest way to create a platform independent UI that's heavily customisable.
- mrgordon 6y ago
  There is this meme that Electron is so bad but as an end user I have much better experiences with Electron apps like Slack and Discord then I do with Microsoft Teams or other competitor apps that don’t use Electron. Is Microsoft Teams supposed to be the fast, efficient alternative because I don’t think so...
  - cercatrova 6y ago
    Teams also uses Electron FYI.
    - mrgordon 6y ago
      Haha guess it wasn’t such a good example then, I had no idea. But I do think Slack or Discord works as well as native Mac apps from the user perspective. I can’t really tell the difference between Atom and say the old Sublime Text or Textmate. If you told me they were all Electron I’d believe you other than Textmate being so old that it couldn’t have been when I used it

tutfbhuf 6y ago

Google might change this, because of ranking penalties for slow websites.

swsieber 6y ago

I think both are needed. I think we've been getting stuff like nim, rust and others because we've had both. They certainly seem to come in waves though. It seems like the equivalent of bulking and cutting.

nthj 6y ago

Web apps are usually slow because of (1) poor data modeling/unoptimized SQL/unindexed tables, (2) ad tracker bloat, and (3) single page applications that reinvent the DOM for $reasons. Swapping out ruby for golang won’t fix any of those. I’ve worked on multiple Rails apps over the past decade, responsible for hundreds of thousands of customers and hundreds of millions in revenue, that easily rendered every page in 150-300ms. This isn’t time-to-first-byte—this is fully rendered, images and all.

cercatrova 6y ago
However, fixing all of those, which costs less in server time (and potentially even dev time, debatable)? I've seen hundreds of Rust based sites on a single 5 dollar droplet while the same would take an order of magnitude more servers. At scale, this gets expensive. See Stripe, Shopify etc that have found this out.
- kyledrake 6y ago
  I run a busy production ruby app on a $40/month droplet. My performance issues are almost never related to ruby. It's nearly 100% of the time some complex database query that needs to get indexed/cached. If coders write their backend in rust for "the ultimate performance", and it's shipping 20MB of javascript to query a poorly designed, poorly indexed database with no caching, they're going to get far worse performance than a ruby app querying a properly designed, cached database with indexing that doesn't have to spend 5 seconds domming the user's DOM first. Performance is a holistic problem, and anecdotally, web sites felt a lot faster during the rails era than they do right now during the JS era.
  - cercatrova 6y ago
    We can do both, I never said one should be prioritized over the other.
    - ryanbrunner 6y ago
      One abosolutely should be prioritized over the other. There's never going to be a situation where you can address every potential source of slowdowns, and make everything 100% efficient all of the time. Given that, in any somewhat realistic environment, you're going to need to prioritize where to spend your focus on making things more efficient. It's certainly possible that the answer is that the language you're using is fundamentally too slow - I personally have almost never experienced that - almost always I can get more out of a time investment by focusing on improving DB performance, or some problem with delivery, caching or optimizing bundles. You should look at your personal situation and use real data to decide where to focus, but you always have to focus. "Make everything 100% efficient at all times" is completely unrealistic.

smarx007 6y ago

Why? Why do we have to make apps run fast? I run a self-hosted install of ArchiveBox and it takes > 10s to archive a webpage. If I am saving the page to retrieve it in a few years, I can surely wait 10-20s. One can say that an optimised setup may load and render a page in under 2s but why? Apps need to fulfill our needs. Nothing more and nothing less. Just like you buy a Nissan Leaf to fulfill your need all while knowing that Bugatti Veyron is one of the fastest cars in the world pushing above 400 km/h. Just like I use ArchiveBox written in Python and SQLite while knowing that there is Rust and RocksDB out there that can outperform Python/SQLite. Side note: I do agree that in some cases product owners take over both user needs and developers' good judgement and turn a good product into a horrid mess but I would argue you can do that in any programming language. Go make yourself some drip coffee on this Christmas day and take it slow! Happy holidays everyone!

cercatrova 6y ago
Speed matters. As a matter of UX, it feels good. People can tell when things instantly open up and load versus being sluggish. And it's also a matter of beauty. I like and appreciate things that fully utilize their forms. In software, it's apps that fully utilize the hardware. I was playing Doom Eternal the other day and it was just amazing the fluidity I got.
- smarx007 6y ago
  > Speed matters I fully agree! But not everywhere and not at all times. > feels good > matter of beauty Well, that's not "matters" as in "must have", rather "nice to have" or "should have". See https://www.librarything.com/ https://www.librarything.com/ for another example where a slow(er) app with high information density is preferred to a "nice" app (eg Apple Books "shelves" that are next to useless compared to this but sure enough, they are nice and fast). > playing Doom Eternal the other day and it was just amazing the fluidity I got. Well, this is where speed truly matters. The whole purpose of a game is to give you experience. Nice UX and fast graphics are a must because it's key to what the game shop is selling you.
  - 6y ago

thurn 6y ago

You would have a hard time naming a AAA game which doesn't have a huge chunk of its actual gameplay logic in a scripting language (or something like Unreal blueprints). There's a huge amount of value in using different tools for the performance-critical parts vs the rest.

blacklight 6y ago

The programming language is often only a (relatively small) part of this problem. The choice of the framework (or, I'd say, the pollution of frameworks, as well as 40 MB libraries only imported to do dependency injection), wrong abstractions, wrong data models (if I'd had a penny for every time I've seen some code do a full list scan when it could have indexed the objects into a map I'd be millionaire by now), over-engineering, frameworks that reinvent the wheel (often in a much less optimal way, all in order to provide the developer with a bit of syntactical sugar), they all play a much bigger role in performance degradation than the language itself. On top of it, projects are often lead by managers that are mostly interested in grabbing the low hanging fruits, pack the product with poorly tested features, set unrealistic deadlines and monetize as fast as possible, and they often don't provide developers time to breathe, take a step back and do any refactoring or optimization - those are too often labelled as purely technical tasks with no business impact and pushed down the priority line. Some of the code written two or three decades ago was much more efficient (especially given the hardware available at the time) than today's projects both because developers were aware of building software for machines with a limited amount of resources, and because the software delivery timelines were much more realistic - aggressive marketing, sales and product departments hadn't yet completely taken over the engineering departments, and while agile methodologies were supposed to mitigate these issues they've actually only shrunk even more the delivery windows and made software development more hectic and shortsighted. 30 years ago a program that would choke on a 386 would be refactored until each single but was optimized for the available resources. Today's approach is simply "just throw more RAM/CPU power" - and that's what I frankly find unacceptable.

blacklight 6y ago
Oh, one more reason I forgot in the case of webapps: 3rd-party scripts and trackers. I've been using NoScript for years now, and that forces me to explicitly whitelist any domain used for scripts on a website. Once you start looking at what major websites do, you start to understand the problem. Most of the newspapers on the web, for example, often employ 20 additional script domains on top of their own - for anything from analytics, to tracking, cookie banners, ads, adblock detectors, Hotjar, Taboola, and so on. We often (justifiably) argue that deep learning, as it's done today, is something unsustainable for the environment. I wonder if anyone has ever measured the impact of running tons of non-functional scripts on the web pages rendered every second by billions of devices around the world.

JohnBooty 6y ago

We can run full fledged games at 240 FPS and yet, websites and apps lag This problem is real, but addressing it in the context of Ruby is misguided. Slow websites? It's the overall system design of the web. Running a bunch of untrusted sandboxed code, retrieved asynchronously from potentially dozens of sources? Yeah, that's gonna be slow. Replace all the Rails sites with assembly code running on bare metal if you like, it's not going to change anything. Ruby on Rails is plenty fast. You can serve up static pages in a few milliseconds. If they take longer than that, it's because you're doing a bunch of work at the database layer or some other work outside of Ruby.

andrekandre 6y ago

i think this has less to do with "concentrating on humans" vs machines and more to do with "business requirements" that are ever-changing which causes insufficient time to work on optimization and siplification... all we get are piles of code upon piles of code... the other side of that is in the web, the tech stack was not at all designed for what we are trying to make it do... add those two things together, add a dash of network latency for all the loaded resources, and you easily get what we have today...