5 ms·

Yes, I’m always shocked by just how much performance overhead most languages have compared to C and similar lower level languages. It is a price worth paying fo

by ummonk 7y ago

Yes, I’m always shocked by just how much performance overhead most languages have compared to C and similar lower level languages. It is a price worth paying for better language ergonomics, but I do wonder whether Rust might be able to give us the best of both worlds here.

_bxg1 7y ago
He did say that Java/C# are also up there, and Go is in that family, so it probably remains the best balance for lots of cases. I do think there's also territory to be explored writing hot paths in Rust and interoping from Python/JS.
twic 7y ago
I semi-seriously think the entire modern shape of the cloud is a result of Ruby being really slow. Back when people were writing their backend business apps in C++, COBOL, Java, etc, if there was ever a performance problem, you could usually just get a slightly bigger machine and grow your thread pools a bit. But once the web took off and Ruby exploded onto it, you couldn't do that, because it's an order of magnitude slower, and doesn't really do multithreading. But, as long as you follow twelve-factor discipline, it scales horizontally like a champ. So, we took to horizontal scaling over multiple VMs (and caching things in Redis instead of local memory or Hazelcast or whatever), and that's been the unquestioned way to do scaling ever since.
- celticmusic 7y ago
  I don't necessarily think you're right here, but I do know the number of horror stories that have come out of Heroku over the years certainly validates the opinion. I remember reading about their routing debacle and realizing just how much work went into trying to get ruby to scale.
- ww520 7y ago
  The push for the need of scaling out started with Ruby and Python's lack of performance. The reason being pushed at the time was, "developer time was more expensive than hardware." Well, that didn't count the amortization of developer time over the lifetime of the product once the product was developed.
  - Silhouette 7y ago
    If hardware speeds and capacities had continued to increase as rapidly as they used to, there might have been some truth in that. Buying a computer with a faster CPU or a bigger disk or more RAM was a relatively cheap solution to a lot of performance problems for a long time, in no small part because it typically required zero changes to the software itself. However, once you're talking about qualitatively different hardware architecture (scaling out instead of up) and therefore also qualitatively different software architecture, it's far from obvious that the premise still holds or that we should even expect it to.
  - shrimpx 7y ago
    It's mostly a fallacy that a demanded product becomes "developed". Maybe a game that gains cult status and therefore a long tail end of life. But popular web services are in constant churn and in that space it's valid to trade hardware for programmer productivity.
    - ww520 7y ago
      Backend web development doesn't change much once developed. How many ways can one do CRUD on the backend?
      - filleduchaos 7y ago
        Out of curiosity, have you ever actually been employed as a backend web developer?
        ww520 7y ago
        Not specifically just backend but full stack projects that included backend.
      - filleokus 7y ago
        In my experience this is only true iff the system never gets any more user facing features. Every new non-insignificant feature requires a new REST-API route, or database table or modification of the GraphQL schema. And depending on how you designed the backend, even small redesigns of the frontend might require changes on the backend. Consider a simple app showing car rentals, where you initially have something like /car/[id], then the frontend guys realise that we need to show cars rented by each customer and it's necessary to have /customer/[id]/rentals. (Of course it's possible to design a system without any schemas or normalisations, which would make your statement truer, but that's rarely attractive for other reasons.)
- trimbo 7y ago
  Never forget "It's boring to scale with Ruby on Rails" (2005) http://web.archive.org/web/20111108170021/http://david.heinemeierhansson.com/arc/000479.html http://web.archive.org/web/20111108170021/http://david.heine...
- watt 7y ago
  Your points are all valid, but I don't think it's the "unquestioned" way. It simply happens to be great way to scale, and also to isolate complexity etc. You can scale to monster loads this way, they way that in-process caches don't.
lmm 7y ago
The idea that GCed languages in general have Python-like performance is a dangerous myth. Languages that are managed but not interpreted (e.g. Java, OCaml, Haskell, C#, Swift) have performance characteristics that are much closer to C than to Python.
- Const-me 7y ago
  This. Modern C# in net-core 3 can even match C++ at manually vectorized numeric code: https://github.com/dotnet/coreclr/issues/27909#issuecomment-557792031 https://github.com/dotnet/coreclr/issues/27909#issuecomment-...
  - pkolaczk 7y ago
    While I agree they can sometimes compete in numerically heavy tasks, the place where they fall behind is memory management. Systems like databases need very careful memory management and GC is not always your friend there. I'm still hoping some day we'll be allowed both GC and Rust-like manual memory management in a single language, although I'm not sure it is at all possible.
    - Const-me 7y ago
      > the place where they fall behind is memory management It's sometimes possible to design C# code in a way that doesn't stress GC too much, so the majority of bandwidth bypasses the GC. For instance, here's my old .NET project which plays streaming media for hours without interrupts, with a hard limit of 15MB RAM for the whole process: https://github.com/Const-me/SkyFM https://github.com/Const-me/SkyFM Doing so became easier in modern .NET, with these value tuples and spans. > still hoping some day we'll be allowed both GC and Rust-like manual memory management in a single language Microsoft tried, managed C++, then C++/CLI. The CLI is still supported if you want to try, but IMO they both were way too complex: 2 types of pointers, two runtimes with weird interaction between them, worst of both sides on safely and ease of use. AFAIK most people only used these languages for a thin layer of glue to integrate native C++ with C#. And even for that limited use case, COM interop or C interop often worked better. Even MS switched to COM interop in the next iteration, C++/CX.
commandlinefan 7y ago
> It is a price worth paying for better language ergonomics Back around 2001 or so, I was hired at an online travel agency to assist in porting their entire system from C++ to Java. Management at the time was frustrated at how long it took to add new features in the C++ codebase - it could take months to get something working in some cases, and they blamed the programming language. Once we got everything working in Java, we found that we could, in fact, turn around feature requests much faster than they could in C++. The trade-off was performance problems: they (we) found that in the old C++ codebase, if you fucked something up, the whole thing crashed, and you had to fix it before you could get it to run. In Java, programmers could paper over their fuck-ups pretty easily so that they wouldn’t be noticed until they had created a snowball effect that caused everything to slow down. Since management was pushing for more features faster, they were incentivizing developers to do as little testing as possible and kick the can down the road. For the most part, management was OK with this: they just bought more, and more, and more servers to make up for the performance problems we were having from the quick-turnaround features they wanted.

by ummonk 7y ago

_bxg1 7y ago

He did say that Java/C# are also up there, and Go is in that family, so it probably remains the best balance for lots of cases. I do think there's also territory to be explored writing hot paths in Rust and interoping from Python/JS.

twic 7y ago

I semi-seriously think the entire modern shape of the cloud is a result of Ruby being really slow. Back when people were writing their backend business apps in C++, COBOL, Java, etc, if there was ever a performance problem, you could usually just get a slightly bigger machine and grow your thread pools a bit. But once the web took off and Ruby exploded onto it, you couldn't do that, because it's an order of magnitude slower, and doesn't really do multithreading. But, as long as you follow twelve-factor discipline, it scales horizontally like a champ. So, we took to horizontal scaling over multiple VMs (and caching things in Redis instead of local memory or Hazelcast or whatever), and that's been the unquestioned way to do scaling ever since.

celticmusic 7y ago
I don't necessarily think you're right here, but I do know the number of horror stories that have come out of Heroku over the years certainly validates the opinion. I remember reading about their routing debacle and realizing just how much work went into trying to get ruby to scale.
ww520 7y ago
The push for the need of scaling out started with Ruby and Python's lack of performance. The reason being pushed at the time was, "developer time was more expensive than hardware." Well, that didn't count the amortization of developer time over the lifetime of the product once the product was developed.
- Silhouette 7y ago
  If hardware speeds and capacities had continued to increase as rapidly as they used to, there might have been some truth in that. Buying a computer with a faster CPU or a bigger disk or more RAM was a relatively cheap solution to a lot of performance problems for a long time, in no small part because it typically required zero changes to the software itself. However, once you're talking about qualitatively different hardware architecture (scaling out instead of up) and therefore also qualitatively different software architecture, it's far from obvious that the premise still holds or that we should even expect it to.
- shrimpx 7y ago
  It's mostly a fallacy that a demanded product becomes "developed". Maybe a game that gains cult status and therefore a long tail end of life. But popular web services are in constant churn and in that space it's valid to trade hardware for programmer productivity.
  - ww520 7y ago
    Backend web development doesn't change much once developed. How many ways can one do CRUD on the backend?
    - filleduchaos 7y ago
      Out of curiosity, have you ever actually been employed as a backend web developer?
      - ww520 7y ago
        Not specifically just backend but full stack projects that included backend.
    - filleokus 7y ago
      In my experience this is only true iff the system never gets any more user facing features. Every new non-insignificant feature requires a new REST-API route, or database table or modification of the GraphQL schema. And depending on how you designed the backend, even small redesigns of the frontend might require changes on the backend. Consider a simple app showing car rentals, where you initially have something like /car/[id], then the frontend guys realise that we need to show cars rented by each customer and it's necessary to have /customer/[id]/rentals. (Of course it's possible to design a system without any schemas or normalisations, which would make your statement truer, but that's rarely attractive for other reasons.)
trimbo 7y ago
Never forget "It's boring to scale with Ruby on Rails" (2005) http://web.archive.org/web/20111108170021/http://david.heinemeierhansson.com/arc/000479.html http://web.archive.org/web/20111108170021/http://david.heine...
watt 7y ago
Your points are all valid, but I don't think it's the "unquestioned" way. It simply happens to be great way to scale, and also to isolate complexity etc. You can scale to monster loads this way, they way that in-process caches don't.

lmm 7y ago

The idea that GCed languages in general have Python-like performance is a dangerous myth. Languages that are managed but not interpreted (e.g. Java, OCaml, Haskell, C#, Swift) have performance characteristics that are much closer to C than to Python.

Const-me 7y ago
This. Modern C# in net-core 3 can even match C++ at manually vectorized numeric code: https://github.com/dotnet/coreclr/issues/27909#issuecomment-557792031 https://github.com/dotnet/coreclr/issues/27909#issuecomment-...
- pkolaczk 7y ago
  While I agree they can sometimes compete in numerically heavy tasks, the place where they fall behind is memory management. Systems like databases need very careful memory management and GC is not always your friend there. I'm still hoping some day we'll be allowed both GC and Rust-like manual memory management in a single language, although I'm not sure it is at all possible.
  - Const-me 7y ago
    > the place where they fall behind is memory management It's sometimes possible to design C# code in a way that doesn't stress GC too much, so the majority of bandwidth bypasses the GC. For instance, here's my old .NET project which plays streaming media for hours without interrupts, with a hard limit of 15MB RAM for the whole process: https://github.com/Const-me/SkyFM https://github.com/Const-me/SkyFM Doing so became easier in modern .NET, with these value tuples and spans. > still hoping some day we'll be allowed both GC and Rust-like manual memory management in a single language Microsoft tried, managed C++, then C++/CLI. The CLI is still supported if you want to try, but IMO they both were way too complex: 2 types of pointers, two runtimes with weird interaction between them, worst of both sides on safely and ease of use. AFAIK most people only used these languages for a thin layer of glue to integrate native C++ with C#. And even for that limited use case, COM interop or C interop often worked better. Even MS switched to COM interop in the next iteration, C++/CX.

commandlinefan 7y ago

> It is a price worth paying for better language ergonomics Back around 2001 or so, I was hired at an online travel agency to assist in porting their entire system from C++ to Java. Management at the time was frustrated at how long it took to add new features in the C++ codebase - it could take months to get something working in some cases, and they blamed the programming language. Once we got everything working in Java, we found that we could, in fact, turn around feature requests much faster than they could in C++. The trade-off was performance problems: they (we) found that in the old C++ codebase, if you fucked something up, the whole thing crashed, and you had to fix it before you could get it to run. In Java, programmers could paper over their fuck-ups pretty easily so that they wouldn’t be noticed until they had created a snowball effect that caused everything to slow down. Since management was pushing for more features faster, they were incentivizing developers to do as little testing as possible and kick the can down the road. For the most part, management was OK with this: they just bought more, and more, and more servers to make up for the performance problems we were having from the quick-turnaround features they wanted.