4 ms·

From security perspective I agree but what if you want to be rid of GC or just reduce your overall resource consumption?

by Ygg2 2y ago

steveklabnik 2y ago
Then you should use the language that’s memory safe without GC.
- Ygg2 2y ago
  Yes, I'm saying in those cases it does make some sense to rewrite it in Rust.
  - UncleMeat 2y ago
    If you have a codebase that has no security implication and won't receive significant benefit from improved productivity/stability from a more modern language, almost certainly not. Such projects exist. That's fine.
nine_k 2y ago
Your engineers are usually your most expensive resource. Developing software in Typescript or even Ruby is a way to get to the revenue faster, having spent less money on development. Development cost and time (that is, the opportunity cost) are usually the most important limitations for a project where the defect rate does not need to be extremely low (like in aircraft control firmware). Rust saves you development time because less of it is spent fixing bugs, but often would pick it not because it saves you RAM and CPU cycles; Haskell or, well, Ada/Spark may be comparably efficient if you can wield them.
- hyperman1 2y ago
  This is true, but there is a crossover point where engineers spend more time understanding existing code than writing new code. Crossing it is typically a point where more static languages with more built in checks become cheaper than more dynamic code. In my experience, it takes about a year to reach this point, less if you hire more people.
  - deleted 2y ago
    [deleted]
- Ygg2 2y ago
  To a point. Let's say you're optimizing a backend written in TS on Amazon, sure it's cheaper to hire guys to optimize it, but at some point it won't be. Either you need some really high class talent to start optimizing shit out of TS or you can't scale as fast as before. Didn't something similar happened at Discord. It was Go if I recall.
  - pjmlp 2y ago
    Indeed, however I would vouch those rewrites have been more a people issue than technical. Apparently there is unwillingness to have "high class talent", while starting from scratch in a completly different programming language stack where everyone is a junior, is suddenly ok. Clearly CV driven development decision. Secondly, in many cases, even if all optimization options on the specific language are exhausted, it is still easier to call into a native library in a lower level language, than a full rewrite from scratch.
    - geodel 2y ago
      My takeaway was if it is our server/cloud cost we will try to optimize the hell out of it. When it is user / client side cost, fuck the user, we will write the crappiest possible software in JS/TS/Electron whatever and ask user upgrade their machine if they whine too much. And totally agree about CV driven development. All these rewrite articles looks like they are trying to convince themselves instead if intelligent readers about rewrites.
  - nine_k 2y ago
    Indeed, the larger the scale, the more impact (including the costs of operation) a piece of software has. In a dozen^W^W OK, a thousand places where the scale is large, engineers shave off a percent or two of resource usage, and this saves company money. But most places are small, and engineers optimize the time to market while remaining at an acceptable levels of resource consumption and support expenses, by using stuff like next.js, RoR, etc. And that saves the company money. There is also a spectrum in between, with associated hassles of transition as the company grows. My favorite example is that eBay rewrote their backend three times, and they did it not because they kept building the wrong thing. They kept building the right thing for their scale at the moment. Baby clothes don't fit a grown-up, but wearing baby clothes while a baby was not a mistake. Ideally, of course, you have a tool that you can keep using from the small prototype stage to the world-scale stage, and it lets you build highly correct, highly performant software quickly. Let's imagine that such a fantastical tool exists. To my mind, the problem is usually not in it but in the architecture: what's efficient at a large scale is uselessly complex at a small scale. The ability to express intricate constraints that precisely match the intricacies of your highly refined business logic may feel like an impediment while you're prototyping and haven't yet discovered what the logic should really be. In short, more precision takes more thinking, and thinking is expensive. It should be applied where it matters most, and often it's not (yet) the technical details.
pjmlp 2y ago
Learning how to actually use the language features that don't rely on GC, like on Swift, D, C#, Linear Haskell, Go, Eiffel, OCaml effects... is already a great step forward. Plenty of people keep putting GC languages on the same basket without understanding what they are talking about. Then if it is a domain where any kind of automatic resource management is impossible due to execution deadlines, or memory availability, Rust is an option.
- elcritch 2y ago
  Well Rust also has certain aspects of “automatic resource management”. You can run into execution deadline issues with allocation or reallocated (drop) in Rust. The patterns to avoid this in critical areas is largely the same in any of the languages you listed. Though I like using effect systems like in Nim or Ocaml for preventing allocation in specific areas.
  - pjmlp 2y ago
    You can even run into execution deadlines with malloc()/free(), that is why there are companies that made business out of selling specialized versions of them, and nowadays that is only less of a business because there are similar FOSS implementations. The point is not winning micro-benchmarks games, rather there are specific SLAs for resource consumption and execution deadlines, is the language toolchain able to meet them, when the language features are used as they should, or does it run out of juice to meet those targets? The recent Guile performance discussion thread is a good example. If language X does meet the targets, and one still goes for "Rewrite XYZ into ZYW" approach, then we are beyond pure technical considerations.
    - throwaway2037 2y ago
      > The recent Guile performance discussion thread is a good example. Sounds very interesting. Can you share a link?
      - itishappy 2y ago
deleted 2y ago
[deleted]

From security perspective I agree but what if you want to be rid of GC or just reduce your overall resource consumption?

by Ygg2 2y ago

From security perspective I agree but what if you want to be rid of GC or just reduce your overall resource consumption?

steveklabnik 2y ago

Then you should use the language that’s memory safe without GC.

Ygg2 2y ago
Yes, I'm saying in those cases it does make some sense to rewrite it in Rust.
- UncleMeat 2y ago
  If you have a codebase that has no security implication and won't receive significant benefit from improved productivity/stability from a more modern language, almost certainly not. Such projects exist. That's fine.

nine_k 2y ago

Your engineers are usually your most expensive resource. Developing software in Typescript or even Ruby is a way to get to the revenue faster, having spent less money on development. Development cost and time (that is, the opportunity cost) are usually the most important limitations for a project where the defect rate does not need to be extremely low (like in aircraft control firmware). Rust saves you development time because less of it is spent fixing bugs, but often would pick it not because it saves you RAM and CPU cycles; Haskell or, well, Ada/Spark may be comparably efficient if you can wield them.

hyperman1 2y ago
This is true, but there is a crossover point where engineers spend more time understanding existing code than writing new code. Crossing it is typically a point where more static languages with more built in checks become cheaper than more dynamic code. In my experience, it takes about a year to reach this point, less if you hire more people.
- deleted 2y ago
  [deleted]
Ygg2 2y ago
To a point. Let's say you're optimizing a backend written in TS on Amazon, sure it's cheaper to hire guys to optimize it, but at some point it won't be. Either you need some really high class talent to start optimizing shit out of TS or you can't scale as fast as before. Didn't something similar happened at Discord. It was Go if I recall.
- pjmlp 2y ago
  Indeed, however I would vouch those rewrites have been more a people issue than technical. Apparently there is unwillingness to have "high class talent", while starting from scratch in a completly different programming language stack where everyone is a junior, is suddenly ok. Clearly CV driven development decision. Secondly, in many cases, even if all optimization options on the specific language are exhausted, it is still easier to call into a native library in a lower level language, than a full rewrite from scratch.
  - geodel 2y ago
    My takeaway was if it is our server/cloud cost we will try to optimize the hell out of it. When it is user / client side cost, fuck the user, we will write the crappiest possible software in JS/TS/Electron whatever and ask user upgrade their machine if they whine too much. And totally agree about CV driven development. All these rewrite articles looks like they are trying to convince themselves instead if intelligent readers about rewrites.
- nine_k 2y ago
  Indeed, the larger the scale, the more impact (including the costs of operation) a piece of software has. In a dozen^W^W OK, a thousand places where the scale is large, engineers shave off a percent or two of resource usage, and this saves company money. But most places are small, and engineers optimize the time to market while remaining at an acceptable levels of resource consumption and support expenses, by using stuff like next.js, RoR, etc. And that saves the company money. There is also a spectrum in between, with associated hassles of transition as the company grows. My favorite example is that eBay rewrote their backend three times, and they did it not because they kept building the wrong thing. They kept building the right thing for their scale at the moment. Baby clothes don't fit a grown-up, but wearing baby clothes while a baby was not a mistake. Ideally, of course, you have a tool that you can keep using from the small prototype stage to the world-scale stage, and it lets you build highly correct, highly performant software quickly. Let's imagine that such a fantastical tool exists. To my mind, the problem is usually not in it but in the architecture: what's efficient at a large scale is uselessly complex at a small scale. The ability to express intricate constraints that precisely match the intricacies of your highly refined business logic may feel like an impediment while you're prototyping and haven't yet discovered what the logic should really be. In short, more precision takes more thinking, and thinking is expensive. It should be applied where it matters most, and often it's not (yet) the technical details.

pjmlp 2y ago

Learning how to actually use the language features that don't rely on GC, like on Swift, D, C#, Linear Haskell, Go, Eiffel, OCaml effects... is already a great step forward. Plenty of people keep putting GC languages on the same basket without understanding what they are talking about. Then if it is a domain where any kind of automatic resource management is impossible due to execution deadlines, or memory availability, Rust is an option.

elcritch 2y ago
Well Rust also has certain aspects of “automatic resource management”. You can run into execution deadline issues with allocation or reallocated (drop) in Rust. The patterns to avoid this in critical areas is largely the same in any of the languages you listed. Though I like using effect systems like in Nim or Ocaml for preventing allocation in specific areas.
- pjmlp 2y ago
  You can even run into execution deadlines with malloc()/free(), that is why there are companies that made business out of selling specialized versions of them, and nowadays that is only less of a business because there are similar FOSS implementations. The point is not winning micro-benchmarks games, rather there are specific SLAs for resource consumption and execution deadlines, is the language toolchain able to meet them, when the language features are used as they should, or does it run out of juice to meet those targets? The recent Guile performance discussion thread is a good example. If language X does meet the targets, and one still goes for "Rewrite XYZ into ZYW" approach, then we are beyond pure technical considerations.
  - throwaway2037 2y ago
    > The recent Guile performance discussion thread is a good example. Sounds very interesting. Can you share a link?
    - itishappy 2y ago

deleted 2y ago

[deleted]