28 ms·

"Rust" really just means "Not javascript" as a recurring pattern in these articles.

noirscape 2y ago
It's also frankly kinda like comparing apples and oranges as a language. JavaScript (and many of the "bad performance" high level languages minus Rails; Rails is bad and should be avoided for projects as much as possible unless you have lots of legacy cruft) are also heavily designed around rapid iteration. Rust is however very much not capable of rapid iteration, the borrow checker will fight you heavily every step of the way to the point where it demands constant refactors. Basically the best place where Rust can work is one where all variables, all requirements and all edgecases are known ahead of time or cases where manual memory safety is a necessity vis-a-vis accepting a minor performance hike from things like the garbage collector. This works well in some spaces (notably; systems programming, embedded and Browser Engines and I wouldn't consider the latter a valid target), but webserver development is probably one of the furthest places where you are looking for Rust.
- hathawsh 2y ago
  I have often thought that programmers can actually just choose to make Rust easy by using a cyclic garbage collector such as Samsara. [1] If cyclic GC in Rust works as well as I think it can, it should be the best option for the majority of high level projects that need fast development with a trade-off of slightly lower efficiency. I suspect we'll see a "hockey stick" adoption curve once everyone figures this out. [1] https://github.com/chc4/samsara https://github.com/chc4/samsara
  - 0cf8612b2e1e 2y ago
    I am still waiting for a scripting language to be bolted on top of Rust. Something that will silently Box all the values so the programmer does not have to think about the Rust specifics, but can still lean on all of the Rust machinery and libraries. If performance/correctness becomes a problem, the scripting layer could be replaced piecemeal with real Rust.
    - dartos 2y ago
      And then we would’ve come full circle. Beautiful
      - jvanderbot 2y ago
        The world is mad. After a decade of this, I give up. The cycles never end.
        hathawsh 2y ago
        I know. We're all just rediscovering Lisp in our own way. ... And yet the fact that most of us know we're reinventing Lisp, and still doing it anyway, says something. I guess it says that we're just trying to get our jobs done.
        dartos 2y ago
        The issue with lisp is that linked lists kind of suck on modern hardware.
        kazinator 2y ago
        Lisp is a language family, not one specific language. Do you have a particular one in mind? There are many languages that can be called Lisp which are different from each other, and some have multiple implementations. Mainstream Lisp dialects have had objects other than lists for many, many decades. The LISP-1 programmer's manual from 1960, referencing the original language which started it all, describes zero-based arrays already. In some Lisp-like languages, the syntax processing itself is based on arrays, like Janet. The parenthesized notation turns into a nested array, not a nested linked list. In Lisps where the syntax is based on lists, that doesn't imply that your program has to work with list at run-time. The code-transformations (macros) which happen at compile time will be working with linked lists. Budding computer scientists and engineers like to write toy Lisp dialects (sometimes in one weekend). Often, those languages only work with linked lists, and are interpreted, meaning that the linked lists representing the code structure are traversed to execute the program, and repeatedly traversed in the case of loops. (If you're making remarks about an important historic language family based on familiarity with someone's toy Lisp project on github, or even some dialect with an immature implementation, that is a gross intellectual mistake. You wouldn't do that, would you?) Linked lists may "kind of suck" on cached hardware with prefetch, but that doesn't prevent them from being widely used in kernels, system libraries, utilities, language run-times (internally, even in the run-times of languages not known for exposing linked lists to the programmer), ... C programmers use linked lists like they are going out of style.
  - worik 2y ago
    This is what async/await rust programmers need They are comfortable with runtimes
- sophacles 2y ago
  I found this to be untrue after I spent a little energy learning to think about problems in rust. In a lot of languages you're working with a hammer and nail (metaphorically speaking) and when you move to a different language its just a slightly different hammer and nail. Rust is a screwdriver and screw though, and once I stopped trying to pound the screw in with the screwdriver, but rather use the one to turn the other, it was a lot easier. Greenfield projects with a lot of iteration are just as fast as doing it in python (although a bit more front-loaded rather than debugging), working new features into existing code - same thing.
- echelon 2y ago
  > Rust is however very much not capable of rapid iteration, the borrow checker will fight you heavily every step of the way to the point where it demands constant refactors. Misconception. You will encounter the borrow checker almost never when writing backend web code in Rust. You only encounter it the first time when you're learning how to write backend code in Rust. Once you've gotten used to it, you will literally never hit it. Sometimes when I write super advanced endpoints that mutate global state or leverage worker threads I'll encounter it. But I'm intentionally doing stuff I could never do in Python or Javascript. Stuff like tabulating running statistics on health check information, batching up information to send to analytics services, maintaining in-memory caches that talk to other workers, etc.
  - materielle 2y ago
    To put this another way: the Rust borrow checker attempts to tie memory lifetime to stack frames. This tends to work well for most crud api servers, since you allocate “context, request, and response” data at the start of the handler function, and deallocate at the end. Most helper data can also be tied to the request lifecycle. And data is mainly isolated per-request. Meaning there isn’t much data sharing across multiple request. This means that the borrow checker “just works”, and you probably won’t even need lifetime annotations or even any special instructions for the borrow checkers. It’s the idealized use case the borrow checker was designed for. This is also the property which most GC languages like Java, Go, and C# exploit with generational garbage collectors. The reason it “works” in Java happens to be the same reason it works in Rust. If your server does need some shared in-memory data, you can start by just handing out copies. If you truly need something more complicated, and we are talking about less than 10% of crud api servers here, then you need to know a thing or two about the borrow checker. I’m not saying to rewrite web servers in Rust, or even advocating for it as a language. I’m just pointing out that a crud api server is the idealized use case for a borrow checker.
    - echelon 2y ago
      Incredibly well said. This is precisely what makes it work so well. The language never set out to solve this problem. It wasn't an intentional design goal. The language design and problem space just happen to overlap more or less perfectly. Complete serendipity.
- timeon 2y ago
  Writing server API'n'co is not unknown path that needs rapid prototyping.
- worik 2y ago
  > the borrow checker will fight you heavily every step of the way to the point where it demands constant refactors. No Once you learn to surrender to the borrow checker it becomes friend, not foe You must submit
- jvanderbot 2y ago
  You've described Rust's niche circumspectly: Systems, which have strict requirements and are fragile minefields. The performance benefits of Rust were supposed to be a non-penalty: "Look, you can please please use this where you'd use C or C++ I promise it won't impact your performance!" Performance and GC overhead was the rejection de jure of every other C replacement. But here we are: All friends are javascript front-enders-turned-backenders and are wondering if they should pick up Rust. It fits into a pattern of "new shiny" but it's good, don't get me wrong, if everyone experiences compiled languages and starts writing their headless code in sensible languages. Repeating myself, but I'm just wondering why not Go? Why now?
- dralley 2y ago
  >Rust is however very much not capable of rapid iteration, the borrow checker will fight you heavily every step of the way to the point where it demands constant refactors. If you have sufficient experience, that's not really the case. Certainly compared to "comparable" languages like C++ where that time fighting the borrow checker might instead have been spent chasing random crashes.
  - jvanderbot 2y ago
    I have written both professionally for long enough to say that there's not real comparable advantage to either. You trade one complexity to fight for another when refactoring or iterating.
- consteval 2y ago
  I don't think this is very true. Certainly, you can rapidly iterate in C#, and it's so much faster it's not even close. But, if you want a dynamically typed experience, look no further than PHP or Perl. Also significantly faster, and, if I had to bet, you could probably iterate much faster in Perl. It wouldn't be fun, but honestly, I doubt that Perl is more footgunny than JS.
IshKebab 2y ago
Not exactly. It wouldn't help if you moved your JavaScript to Python or Ruby or PHP... and anyway it's not really feasible from an FFI perspective to move it to anything other than Rust or C/C++ or maybe Zig. There's no good reason to pick C/C++ over Rust in most of these cases... So "Rust" means "Not JavaScript, and also a bunch of other constraints that mean that Rust is pretty much the only sensible choice."
- marcosdumay 2y ago
  > It wouldn't help if you moved your JavaScript to Python or Ruby or PHP... Hum, no. The point is exactly that it would help a great deal if you moved to Python or Ruby or PHP. Of course, Rust will give you even better memory efficiency. But Javascript is a particularly bad option there, and almost anything else would be an improvement. ("Almost", because if you push it enough and move to something like MathLab, you'll get worse results.)
  - chrisldgk 2y ago
    This seems a bit unfair to JavaScript. There’s a lot of optimizations made to the language and its runtimes that have made a more than viable choice for server side applications over the years. The JavaScript that started as a Webbrowser client side language is very different from the ECMAScript that we have today. Depending on its usage it can also be one of the fastest, only regularly eclipsed by rust[1]. So no, JavaScript really isn’t a bad option for server side applications at all. [1] https://www.techempower.com/benchmarks/#hw=ph&test=composite&section=data-r22 https://www.techempower.com/benchmarks/#hw=ph&test=composite...
  - jerf 2y ago
    If moving from JS to CPython would help, it might help memory consumption, because JITs generally trade speed for increased memory. But then you'd get slower execution, because CPython is slower than the JS engines we tend to use. PyPy might generally track JS on performance (big, BIG "it depends" because the speed profile of JITs are crazy complicated, one of my least favorite things about them) but then you're back to trading memory for speed, so it's probably net-net a sideways move. Also, I don't know what Node is doing exactly, but if you take a lot of these dynamic languages and just fork them into multiple processes, which they still largely need to do to effectively use all the CPUs, you will generally see high per-process memory consumption just like Node. Any memory page that has a reference counter in it that is used by your code ends up Copied-On-Write in practice by every process in the steady state because all you need to do to end up copying the page is looking at any one reference it happens to contain in such a language. At least in my experience memory sharing gains were always minimal to effectively zero in such cases.
chipdart 2y ago
[flagged]
- echelon 2y ago
  No, this is actually an earth-shattering revelation: A bare metal systems programming language can be used for web backend development. Let that sink in. Rust has a great type system, and because of this and the compiler, the quality of code you wind up writing is naturally extremely high. You'll write code with fewer defects than in other compiled languages like Go or Java. And it's even more pronounced against languages like Javascript, Ruby, and Python. You can write backend web code in Rust quickly, too. There's minimal performance or development velocity loss, and you produce code that is much higher quality and easier to maintain. And it's fast, doesn't GC, can run on cheap VMs. You get all of this for free. This is the shocking statement that is being made.
  - chipdart 2y ago
    > A bare metal systems programming language can be used for web backend development. Let that sink in. Hand-roled assembly too, and even brainfuck. What an epiphany. Meanwhile this cargo cult is invested in toy projects to meet the bandwagon quotas of their cargo cult while the rest of the world goes on adding feature sets with a couple lines of code. And what's their tradeoff? At best saving cents on vCPU costs? Totally worth it, I suppose.
    - deleted 2y ago
      [deleted]

It's also frankly kinda like comparing apples and oranges as a language. JavaScript (and many of the "bad performance" high level languages minus Rails; Rails is bad and should be avoided for projects as much as possible unless you have lots of legacy cruft) are also heavily designed around rapid iteration. Rust is however very much not capable of rapid iteration, the borrow checker will fight you heavily every step of the way to the point where it demands constant refactors. Basically the best place where Rust can work is one where all variables, all requirements and all edgecases are known ahead of time or cases where manual memory safety is a necessity vis-a-vis accepting a minor performance hike from things like the garbage collector. This works well in some spaces (notably; systems programming, embedded and Browser Engines and I wouldn't consider the latter a valid target), but webserver development is probably one of the furthest places where you are looking for Rust.

hathawsh 2y ago
I have often thought that programmers can actually just choose to make Rust easy by using a cyclic garbage collector such as Samsara. [1] If cyclic GC in Rust works as well as I think it can, it should be the best option for the majority of high level projects that need fast development with a trade-off of slightly lower efficiency. I suspect we'll see a "hockey stick" adoption curve once everyone figures this out. [1] https://github.com/chc4/samsara https://github.com/chc4/samsara
- 0cf8612b2e1e 2y ago
  I am still waiting for a scripting language to be bolted on top of Rust. Something that will silently Box all the values so the programmer does not have to think about the Rust specifics, but can still lean on all of the Rust machinery and libraries. If performance/correctness becomes a problem, the scripting layer could be replaced piecemeal with real Rust.
  - dartos 2y ago
    And then we would’ve come full circle. Beautiful
    - jvanderbot 2y ago
      The world is mad. After a decade of this, I give up. The cycles never end.
      - hathawsh 2y ago
        I know. We're all just rediscovering Lisp in our own way. ... And yet the fact that most of us know we're reinventing Lisp, and still doing it anyway, says something. I guess it says that we're just trying to get our jobs done.
        dartos 2y ago
        The issue with lisp is that linked lists kind of suck on modern hardware.
        kazinator 2y ago
        Lisp is a language family, not one specific language. Do you have a particular one in mind? There are many languages that can be called Lisp which are different from each other, and some have multiple implementations. Mainstream Lisp dialects have had objects other than lists for many, many decades. The LISP-1 programmer's manual from 1960, referencing the original language which started it all, describes zero-based arrays already. In some Lisp-like languages, the syntax processing itself is based on arrays, like Janet. The parenthesized notation turns into a nested array, not a nested linked list. In Lisps where the syntax is based on lists, that doesn't imply that your program has to work with list at run-time. The code-transformations (macros) which happen at compile time will be working with linked lists. Budding computer scientists and engineers like to write toy Lisp dialects (sometimes in one weekend). Often, those languages only work with linked lists, and are interpreted, meaning that the linked lists representing the code structure are traversed to execute the program, and repeatedly traversed in the case of loops. (If you're making remarks about an important historic language family based on familiarity with someone's toy Lisp project on github, or even some dialect with an immature implementation, that is a gross intellectual mistake. You wouldn't do that, would you?) Linked lists may "kind of suck" on cached hardware with prefetch, but that doesn't prevent them from being widely used in kernels, system libraries, utilities, language run-times (internally, even in the run-times of languages not known for exposing linked lists to the programmer), ... C programmers use linked lists like they are going out of style.
- worik 2y ago
  This is what async/await rust programmers need They are comfortable with runtimes
sophacles 2y ago
I found this to be untrue after I spent a little energy learning to think about problems in rust. In a lot of languages you're working with a hammer and nail (metaphorically speaking) and when you move to a different language its just a slightly different hammer and nail. Rust is a screwdriver and screw though, and once I stopped trying to pound the screw in with the screwdriver, but rather use the one to turn the other, it was a lot easier. Greenfield projects with a lot of iteration are just as fast as doing it in python (although a bit more front-loaded rather than debugging), working new features into existing code - same thing.
echelon 2y ago
> Rust is however very much not capable of rapid iteration, the borrow checker will fight you heavily every step of the way to the point where it demands constant refactors. Misconception. You will encounter the borrow checker almost never when writing backend web code in Rust. You only encounter it the first time when you're learning how to write backend code in Rust. Once you've gotten used to it, you will literally never hit it. Sometimes when I write super advanced endpoints that mutate global state or leverage worker threads I'll encounter it. But I'm intentionally doing stuff I could never do in Python or Javascript. Stuff like tabulating running statistics on health check information, batching up information to send to analytics services, maintaining in-memory caches that talk to other workers, etc.
- materielle 2y ago
  To put this another way: the Rust borrow checker attempts to tie memory lifetime to stack frames. This tends to work well for most crud api servers, since you allocate “context, request, and response” data at the start of the handler function, and deallocate at the end. Most helper data can also be tied to the request lifecycle. And data is mainly isolated per-request. Meaning there isn’t much data sharing across multiple request. This means that the borrow checker “just works”, and you probably won’t even need lifetime annotations or even any special instructions for the borrow checkers. It’s the idealized use case the borrow checker was designed for. This is also the property which most GC languages like Java, Go, and C# exploit with generational garbage collectors. The reason it “works” in Java happens to be the same reason it works in Rust. If your server does need some shared in-memory data, you can start by just handing out copies. If you truly need something more complicated, and we are talking about less than 10% of crud api servers here, then you need to know a thing or two about the borrow checker. I’m not saying to rewrite web servers in Rust, or even advocating for it as a language. I’m just pointing out that a crud api server is the idealized use case for a borrow checker.
  - echelon 2y ago
    Incredibly well said. This is precisely what makes it work so well. The language never set out to solve this problem. It wasn't an intentional design goal. The language design and problem space just happen to overlap more or less perfectly. Complete serendipity.
timeon 2y ago
Writing server API'n'co is not unknown path that needs rapid prototyping.
worik 2y ago
> the borrow checker will fight you heavily every step of the way to the point where it demands constant refactors. No Once you learn to surrender to the borrow checker it becomes friend, not foe You must submit
jvanderbot 2y ago
You've described Rust's niche circumspectly: Systems, which have strict requirements and are fragile minefields. The performance benefits of Rust were supposed to be a non-penalty: "Look, you can please please use this where you'd use C or C++ I promise it won't impact your performance!" Performance and GC overhead was the rejection de jure of every other C replacement. But here we are: All friends are javascript front-enders-turned-backenders and are wondering if they should pick up Rust. It fits into a pattern of "new shiny" but it's good, don't get me wrong, if everyone experiences compiled languages and starts writing their headless code in sensible languages. Repeating myself, but I'm just wondering why not Go? Why now?
dralley 2y ago
>Rust is however very much not capable of rapid iteration, the borrow checker will fight you heavily every step of the way to the point where it demands constant refactors. If you have sufficient experience, that's not really the case. Certainly compared to "comparable" languages like C++ where that time fighting the borrow checker might instead have been spent chasing random crashes.
- jvanderbot 2y ago
  I have written both professionally for long enough to say that there's not real comparable advantage to either. You trade one complexity to fight for another when refactoring or iterating.
consteval 2y ago
I don't think this is very true. Certainly, you can rapidly iterate in C#, and it's so much faster it's not even close. But, if you want a dynamically typed experience, look no further than PHP or Perl. Also significantly faster, and, if I had to bet, you could probably iterate much faster in Perl. It wouldn't be fun, but honestly, I doubt that Perl is more footgunny than JS.

IshKebab 2y ago

Not exactly. It wouldn't help if you moved your JavaScript to Python or Ruby or PHP... and anyway it's not really feasible from an FFI perspective to move it to anything other than Rust or C/C++ or maybe Zig. There's no good reason to pick C/C++ over Rust in most of these cases... So "Rust" means "Not JavaScript, and also a bunch of other constraints that mean that Rust is pretty much the only sensible choice."

marcosdumay 2y ago
> It wouldn't help if you moved your JavaScript to Python or Ruby or PHP... Hum, no. The point is exactly that it would help a great deal if you moved to Python or Ruby or PHP. Of course, Rust will give you even better memory efficiency. But Javascript is a particularly bad option there, and almost anything else would be an improvement. ("Almost", because if you push it enough and move to something like MathLab, you'll get worse results.)
- chrisldgk 2y ago
  This seems a bit unfair to JavaScript. There’s a lot of optimizations made to the language and its runtimes that have made a more than viable choice for server side applications over the years. The JavaScript that started as a Webbrowser client side language is very different from the ECMAScript that we have today. Depending on its usage it can also be one of the fastest, only regularly eclipsed by rust[1]. So no, JavaScript really isn’t a bad option for server side applications at all. [1] https://www.techempower.com/benchmarks/#hw=ph&test=composite&section=data-r22 https://www.techempower.com/benchmarks/#hw=ph&test=composite...
- jerf 2y ago
  If moving from JS to CPython would help, it might help memory consumption, because JITs generally trade speed for increased memory. But then you'd get slower execution, because CPython is slower than the JS engines we tend to use. PyPy might generally track JS on performance (big, BIG "it depends" because the speed profile of JITs are crazy complicated, one of my least favorite things about them) but then you're back to trading memory for speed, so it's probably net-net a sideways move. Also, I don't know what Node is doing exactly, but if you take a lot of these dynamic languages and just fork them into multiple processes, which they still largely need to do to effectively use all the CPUs, you will generally see high per-process memory consumption just like Node. Any memory page that has a reference counter in it that is used by your code ends up Copied-On-Write in practice by every process in the steady state because all you need to do to end up copying the page is looking at any one reference it happens to contain in such a language. At least in my experience memory sharing gains were always minimal to effectively zero in such cases.

chipdart 2y ago

[flagged]

echelon 2y ago
No, this is actually an earth-shattering revelation: A bare metal systems programming language can be used for web backend development. Let that sink in. Rust has a great type system, and because of this and the compiler, the quality of code you wind up writing is naturally extremely high. You'll write code with fewer defects than in other compiled languages like Go or Java. And it's even more pronounced against languages like Javascript, Ruby, and Python. You can write backend web code in Rust quickly, too. There's minimal performance or development velocity loss, and you produce code that is much higher quality and easier to maintain. And it's fast, doesn't GC, can run on cheap VMs. You get all of this for free. This is the shocking statement that is being made.
- chipdart 2y ago
  > A bare metal systems programming language can be used for web backend development. Let that sink in. Hand-roled assembly too, and even brainfuck. What an epiphany. Meanwhile this cargo cult is invested in toy projects to meet the bandwagon quotas of their cargo cult while the rest of the world goes on adding feature sets with a couple lines of code. And what's their tradeoff? At best saving cents on vCPU costs? Totally worth it, I suppose.
  - deleted 2y ago
    [deleted]