6 ms·

I don't want to discourage the developers working on this project, but I'm curious why we're still writing applications that will almost certainly execute or pr

I don't want to discourage the developers working on this project, but I'm curious why we're still writing applications that will almost certainly execute or process hostile content in languages that don't maintain strict memory safe contract? Have we not learned our lesson yet, or am I misunderstanding the situation? I believe it was a Microsoft study that linked unsafe memory access to ~70% of exploit chains.

peoplefromibiza 2y ago
> in languages that don't maintain strict memory safe contract? for the same reason people still use the English language, despite being full of crazy inconsistencies and being very hard to become a native speaker, coming from another language: proficiency. Proficiency is one of the most, if not the most, valuable metric when choosing the tool you will use to take on some complex/daunting task.
- elygre 2y ago
  The language “legalese” was invented when it turned out that being proficient in English does not protect you against malicious contract partners. (The success of legalese is still debated, but its existence is generally accepted)
  - peoplefromibiza 2y ago
    legalese is a subset of English. BTW Rust (or any other so called "memory safe" language) is not the equivalent of legalese, it's the equivalent of using French because it's the "language of diplomacy" (that's why many English words come from French) instead of English. If you're not proficient in French, French legalese won't save you.
    - oriolid 2y ago
      Could you explain your thinking a bit more? To me the "language of diplomacy" equivalent for computers sounds more like C calling convention, HTTP and XML or JSON.
      - torstenvl 2y ago
        Nobody is saying there is a programming equivalent of the language of diplomacy. He said that using Rust to achieve memory safety is analogous to using French for diplomacy, in that, whatever value the language itself might bring to that goal, you are not likely to achieve it if you are not proficient. If you are not proficient in French, you likely ought not to conduct diplomacy in French. If you are not proficient in Rust, you likely ought not to achieve memory safety by writing everything in Rust.
        oriolid 2y ago
        Ok, I'll try to explain. - French itself does not add much value to diplomacy. The reason to use is that everyone else who does diplomacy is expected to know French (and probably isn't a native speaker which makes things a bit more equal). English is probably taking over there, like it has done in other domains. - The recent C++ versions are not actively promoting shooting yourself in the foot like older variants, but they aren't exactly trying to prevent it. - Rust is going out of its way to prevent writing memory unsafe code. It is still possible if you know what you are doing, but just trying out stuff at random is more likely to give you a compile-time error than undefined behaviour. - Most programmers aren't very competent, not matter what they believe about themselves. With Rust they are less likely to commit serious errors. Or get anything done, but that's a separate discussion. The French will probably point out your pronunciation mistakes too before continuing discussion, but that's also not the point here.
        peoplefromibiza 2y ago
        > - French itself does not add much value to diplomacy. Funny, given that the word diplomacy is a French word, together with embassy, treaty, alliance, passport and protocol :) > Rust is going out of its way to prevent writing memory unsafe code But if someone is not proficient in Rust it will only slow them down and they'll end up fighting the language and the compiler instead of using the language. It's a common complain among non Rust programmers. > Most programmers aren't very competent I strongly believe Andreas Kling is very competent. For the rest of us who are not him, incompetence does not go well in hand with Rust, which is a very complex language. EDIT: pretending that a very proficient C++ programmer will chose Rust because "it's 2024" it's the same thing as pretending that they will chose Haskell, which is equally memory safe and also equally complex. Why nobody ever recommend Haskell or Smalltalk? It doesn't seem much like a discussion about memory safety to me, but rather promoting Rust.
- voidwtf 2y ago
  This makes the most sense and thank you for offering a genuine answer to my question. Which leads to a follow-up question. Has the rise of these memory safe languages caused any shift in the proficiencies of the average developer? I see a lot of younger people gush over python early in their careers but see a lot of Java/.NET in enterprise. I personally grew up learning Delphi, PHP, and HTML. Java and .NET came later, but I rarely had a hand in initiating the projects so my language proficiency typically flowed with the job/project I was working on professionally.
  - peoplefromibiza 2y ago
    > Has the rise of these memory safe languages caused any shift in the proficiencies of the average developer? That's a good question, but I have no answer for it. AFAIK the data is missing or is inconsistent. But I can link to you the obligatory Ken Thompson's "three weeks away from an OS" https://youtu.be/EY6q5dv_B-o?t=1360&si=Nx6dK4KigZJ3962F https://youtu.be/EY6q5dv_B-o?t=1360&si=Nx6dK4KigZJ3962F
aniviacat 2y ago
On the v8 engine's blog, it is claimed that most of its vulnerabilities are caused by logic issues which Rust wouldn't help with. Perhaps it's a similar situation for Ladybird. >Memory safety remains a relevant problem: all Chrome exploits caught in the wild in the last three years (2021 – 2023) started out with a memory corruption vulnerability in a Chrome renderer process that was exploited for remote code execution (RCE). Of these, 60% were vulnerabilities in V8. > V8 vulnerabilities are rarely "classic" memory corruption bugs (use-after-frees, out-of-bounds accesses, etc.) but instead subtle logic issues which can in turn be exploited to corrupt memory. As such, existing memory safety solutions are, for the most part, not applicable to V8. In particular, neither switching to a memory safe language, such as Rust, nor using current or future hardware memory safety features, such as memory tagging, can help with the security challenges faced by V8 today. See: https://v8.dev/blog/sandbox https://v8.dev/blog/sandbox
- kroolik 2y ago
  I believe the fact that V8 vulnerabilities are not "classic" memory corruption can be attributed to their developers' experience and review processes. This doesn't imply, though, that another project in C++ will share these traits.
- debugnik 2y ago
  40% may not be a majority, but it's still close to half of all Chrome exploits in the wild, and they could be avoided with a memory-safe toolchain. (Doesn't have to be Rust.) As for the other 60%, they point to logic errors as the root cause, but that's true of all memory corruption bugs: they wouldn't exist if there weren't logic errors behind them. The actual difference here is that the vulnerabilities are either in the machine code generated by the JIT (e.g. type confusion), rather than V8's own code; or they're in code they insist must be memory-unsafe for performance reasons. So the takeaway there should be that JS engines for hostile code should either not use a JIT at all, nor memory-unsafe code paths, or use stronger tools to verify the correctness of the JIT and those code paths. But hey, retaining the capability to speed up bloated web apps ever so slightly is more important that
- timeon 2y ago
skywal_l 2y ago
Andreas (the author of ladybird) started a language[0] that would be memory-safe and in which he would eventually write SerenityOS (and I assume LadyBird too). He hasn't committed to it for 6 months now so not sure what the status is. At the end of the day, LadyBird is still a hobby project, so one of the main objective is to have fun which does not always coincide with rationality (although the decision to move on from NIH[1] is a sign that this might be changing). [0] https://github.com/SerenityOS/jakt https://github.com/SerenityOS/jakt [1] https://en.wikipedia.org/wiki/Not_invented_here https://en.wikipedia.org/wiki/Not_invented_here
- jraph 2y ago
  Ladybird is sponsored now and I seem to remember that Andreas is paid full time to work on it. I don't think Ladybird is still strictly a hobby project anymore. But it was definitely started as a hobby project so your point still stands, mostly. (to be clear, I'm not answering to the question of which programming language should be used to write Ladybird)
- asddubs 2y ago
  Jakt was described more as an experiment and to potentially replace C++ in the codebase, rather than definitely. I haven't seen any official word on this but as you imply I would assume that this effort is essentially dead now. Just as with the operating system itself, the focus eventually shifted elsewhere and Jakt was left behind.
gkbrk 2y ago
> why we're still writing applications > Have we not learned our lesson yet Why are you speaking like this project is asking you to write code in C++? You are free to exclusively write Rust. Other people writing C++ has 0 impact on what you're writing or what lessons you've learned.
- voidwtf 2y ago
  If the eventual goal is to place the application in the hand of users, I think the question has merit.
jraph 2y ago
I'll take an alternative browser engine, even if it's written in C++. > I'm curious Is it really curiosity though? Because the answer is straightforward, the project started as a hobby, the developer picked whatever language they were proficient in. Andreas is open with the fact that he started Serenity OS and LadyBird as a rehab project. Put too much barrier in this setting (like learning a new language and all the ecosystem) and it might not happen at all.
- znpy 2y ago
  >> I'm curious > Is it really curiosity though? I'm kind of annoyed at this whole train of comments ("I'm curious..."). In so many occasion I see something cool and the main comment track is "why hasn't this been writte in rust?" (or some other allegedly safe/better programming language). It's like seeing a beautiful painting being painted and arguing about the kind of paintbrush the painter has used. It's so sad.
  - red_trumpet 2y ago
    > It's like seeing a beautiful painting being painted and arguing about the kind of paintbrush the painter has used. It's like seeing a beautiful painting and realizing the painter didn't use lightfast colors. In ten years the painting will not be beautiful anymore. Yes, the painter / author put in a lot of work, and this deserves acknowledgement. But ones decision to use it or not is not only based on the amount of work put in.
    - account42 2y ago
      It's more like seeing a beautiful painting and complaining that the painter didn't use your favorite brand of paint which promises to be much better looking than the other paints in ten years but hasn't even been around that long.
      - nindalf 2y ago
        This analogy has been tortured beyond usefulness.
flumpcakes 2y ago
It's crap programmers that write buggy code, and they will write similarly buggy code in any language. It's not hard to write memory safe code, most people are not skilled enough to do it. I doubt they will be skilled enough to write good rust.
surgical_fire 2y ago
> but I'm curious why we're still writing applications > Have we not learned our lesson yet, "We"? Do you speak in the name of the developer? What an odd choice of pronoum. Either way, if you are adamant about writing a new browser in your "memory-safe language" of choice, be the change you want made. Go ahead and write a new browser from scratch. Show the world how it should be done.
- voidwtf 2y ago
  I meant we as in the collective, and I explicitly referenced the collective of those writing applications that process and/or execute user generated content. So no, I don’t think it appropriate to focus my question on the author or this project. I am wondering if C++ is a better choice for reasons I don’t understand when it comes to HTML/JS/CSS, despite potential security implications as the complexity grows.
pjmlp 2y ago
Note that despite that study, Windows and XBox teams are quite found of their C and C++, and even their own .NET has more success on the Azure side, than replacing all those COM/WinRT C++ workloads, and extension points. It is Azure that is more keen in adopting memory safe languages, and has the mandate that new systems code should be done using them.
- TacticalCoder 2y ago
  > Note that despite that study, Windows and XBox teams are quite found of their C and C++... And we all know how secure the average user's Windows computer is. And Windows' security is so good that it's Windows who's powering tens of billions of servers, smartphones, IoT, appliances, routers etc. throughout the world? Oh, wait, no... These are all running Linux. And the uptime. Let's not forget the uptime with patch tuesday. Windows does not strike me as the ecosystem we should strive to immitate.
  - pjmlp 2y ago
    In what language is the Linux kernel written on? https://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33 https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm... Those that have glass ceilings should not throw rocks.
alexvitkov 2y ago
Because rust is a cargo cult. We're nearing 10 years since 1.0 and there's still not a single serious, widely used, large software project to prove its viability. Maybe make one instead of trying to passive aggressively convince others to do it for you?
- voidwtf 2y ago
  I didn’t mention rust, I don’t know Rust and if I were trying to start a similar project I might do so in .NET Core because of my familiarity with .NET. I’m asking because I don’t know if there is a reason it would not be viable, is the garbage collection too much of a hurdle to get decent performance while trying to interpret JavaScript? Is there too much overhead tracking claims on memory and doing the bounds checks? I’d assume the same checks eventually have to be written in C++ too?
  - alexvitkov 2y ago
    I apologize - when people mention "memory safe" nowadays 95% of the time they're talking about Rust, I made an assumption. Interpreting JavaScript at all it at all is a problem. Ladybird's LibJS compiles it to bytecode and interprets that (which is usually better than intereprting the AST). The bytecode interpreter is written in C++, and it's still pretty damn slow - websites take a long time to load, and LibJS is the main bottleneck. The reality is, modern websites throws so much junk at your JS implementation, that you basically need to JIT-compile it in order to have any sort of reasonable performance. And with JIT all memory safety guarantees are thrown out of the window - it doesn't matter if you write your compiler in Rust, C++ or a .NET language - if there's an exploit it's disproportionately more likely to be in the output assembly than it is to be in your compiler. Browsers nowadays make a best effort, and they have a stack of other mitigations in case the JIT leaks: https://chromium.googlesource.com/chromium/src/+/main/docs/design/sandbox.md https://chromium.googlesource.com/chromium/src/+/main/docs/d...
    - voidwtf 2y ago
      This may be the biggest gap in my understanding. I didn’t realize that at some point the JavaScript is turned into instructions running directly on metal, I thought everything occurred within a synthetic/virtual environment.
durandal1 2y ago
Where is the proof that Rust can achieve the productivity and design flexibility needed at browser scale?
einpoklum 2y ago
> writing applications that will almost certainly execute or process hostile content in languages that don't maintain strict memory safe contract? That point is 50% FUD. A language which "maintains strict memory safe contracts" but has an `unsafe` keyword; or has a "native code interface", or uses libraries implemented in a different language, doesn't really strictly maintain its guarantees. And on the other hand, a language in which you can, in principle, load and execute arbitrary code from a string you got from the user, can be hardened very well by statically-checkable constraints. So, it's a matter of degrees rather than absolutes. If you then add considerations such as programming paradigm flexibility and performance, C++ is very much a valid choice even for the use case of a browser.
deleted 2y ago
[deleted]
ArtixFox 2y ago
Because writing a browser in ATS or Frama-C is not possible. Or writing it in Coq and exporting it to ocaml and friends. Ada can be used but its mediocre at best and sucks at places where frama-C shines. A lot of pointer stuff that is easier to prove in ATS or frama-C is impossible in Ada [and by extension of that, rust] TLA+ can be used in mix with C++ just like how 90% of safety critical software is written but the development speed is very slow for it. That leaves Rust, which is a...mediocre language if you really care about safety. It has no idea of linear types that ATS has and cannot carry embedded proofs like Frama-C. Plus the culture regarding safety critical software in C/C++ is humongous and tbh fairly amazing. I cannot remember exactly but there are many projects targeting C++ for safety purposes, even the people behind frama-C are creating something called as frama-Clang to allow writing safety critical code in C++ backed by proofs. Are there any other languages that im missing? If ATS has a prettier syntax, it'd be my candidate for writing a web browser in.

peoplefromibiza 2y ago

> in languages that don't maintain strict memory safe contract? for the same reason people still use the English language, despite being full of crazy inconsistencies and being very hard to become a native speaker, coming from another language: proficiency. Proficiency is one of the most, if not the most, valuable metric when choosing the tool you will use to take on some complex/daunting task.

elygre 2y ago
The language “legalese” was invented when it turned out that being proficient in English does not protect you against malicious contract partners. (The success of legalese is still debated, but its existence is generally accepted)
- peoplefromibiza 2y ago
  legalese is a subset of English. BTW Rust (or any other so called "memory safe" language) is not the equivalent of legalese, it's the equivalent of using French because it's the "language of diplomacy" (that's why many English words come from French) instead of English. If you're not proficient in French, French legalese won't save you.
  - oriolid 2y ago
    Could you explain your thinking a bit more? To me the "language of diplomacy" equivalent for computers sounds more like C calling convention, HTTP and XML or JSON.
    - torstenvl 2y ago
      Nobody is saying there is a programming equivalent of the language of diplomacy. He said that using Rust to achieve memory safety is analogous to using French for diplomacy, in that, whatever value the language itself might bring to that goal, you are not likely to achieve it if you are not proficient. If you are not proficient in French, you likely ought not to conduct diplomacy in French. If you are not proficient in Rust, you likely ought not to achieve memory safety by writing everything in Rust.
      - oriolid 2y ago
        Ok, I'll try to explain. - French itself does not add much value to diplomacy. The reason to use is that everyone else who does diplomacy is expected to know French (and probably isn't a native speaker which makes things a bit more equal). English is probably taking over there, like it has done in other domains. - The recent C++ versions are not actively promoting shooting yourself in the foot like older variants, but they aren't exactly trying to prevent it. - Rust is going out of its way to prevent writing memory unsafe code. It is still possible if you know what you are doing, but just trying out stuff at random is more likely to give you a compile-time error than undefined behaviour. - Most programmers aren't very competent, not matter what they believe about themselves. With Rust they are less likely to commit serious errors. Or get anything done, but that's a separate discussion. The French will probably point out your pronunciation mistakes too before continuing discussion, but that's also not the point here.
        peoplefromibiza 2y ago
        > - French itself does not add much value to diplomacy. Funny, given that the word diplomacy is a French word, together with embassy, treaty, alliance, passport and protocol :) > Rust is going out of its way to prevent writing memory unsafe code But if someone is not proficient in Rust it will only slow them down and they'll end up fighting the language and the compiler instead of using the language. It's a common complain among non Rust programmers. > Most programmers aren't very competent I strongly believe Andreas Kling is very competent. For the rest of us who are not him, incompetence does not go well in hand with Rust, which is a very complex language. EDIT: pretending that a very proficient C++ programmer will chose Rust because "it's 2024" it's the same thing as pretending that they will chose Haskell, which is equally memory safe and also equally complex. Why nobody ever recommend Haskell or Smalltalk? It doesn't seem much like a discussion about memory safety to me, but rather promoting Rust.
voidwtf 2y ago
This makes the most sense and thank you for offering a genuine answer to my question. Which leads to a follow-up question. Has the rise of these memory safe languages caused any shift in the proficiencies of the average developer? I see a lot of younger people gush over python early in their careers but see a lot of Java/.NET in enterprise. I personally grew up learning Delphi, PHP, and HTML. Java and .NET came later, but I rarely had a hand in initiating the projects so my language proficiency typically flowed with the job/project I was working on professionally.
- peoplefromibiza 2y ago
  > Has the rise of these memory safe languages caused any shift in the proficiencies of the average developer? That's a good question, but I have no answer for it. AFAIK the data is missing or is inconsistent. But I can link to you the obligatory Ken Thompson's "three weeks away from an OS" https://youtu.be/EY6q5dv_B-o?t=1360&si=Nx6dK4KigZJ3962F https://youtu.be/EY6q5dv_B-o?t=1360&si=Nx6dK4KigZJ3962F

aniviacat 2y ago

On the v8 engine's blog, it is claimed that most of its vulnerabilities are caused by logic issues which Rust wouldn't help with. Perhaps it's a similar situation for Ladybird. >Memory safety remains a relevant problem: all Chrome exploits caught in the wild in the last three years (2021 – 2023) started out with a memory corruption vulnerability in a Chrome renderer process that was exploited for remote code execution (RCE). Of these, 60% were vulnerabilities in V8. > V8 vulnerabilities are rarely "classic" memory corruption bugs (use-after-frees, out-of-bounds accesses, etc.) but instead subtle logic issues which can in turn be exploited to corrupt memory. As such, existing memory safety solutions are, for the most part, not applicable to V8. In particular, neither switching to a memory safe language, such as Rust, nor using current or future hardware memory safety features, such as memory tagging, can help with the security challenges faced by V8 today. See: https://v8.dev/blog/sandbox https://v8.dev/blog/sandbox

kroolik 2y ago
I believe the fact that V8 vulnerabilities are not "classic" memory corruption can be attributed to their developers' experience and review processes. This doesn't imply, though, that another project in C++ will share these traits.
debugnik 2y ago
40% may not be a majority, but it's still close to half of all Chrome exploits in the wild, and they could be avoided with a memory-safe toolchain. (Doesn't have to be Rust.) As for the other 60%, they point to logic errors as the root cause, but that's true of all memory corruption bugs: they wouldn't exist if there weren't logic errors behind them. The actual difference here is that the vulnerabilities are either in the machine code generated by the JIT (e.g. type confusion), rather than V8's own code; or they're in code they insist must be memory-unsafe for performance reasons. So the takeaway there should be that JS engines for hostile code should either not use a JIT at all, nor memory-unsafe code paths, or use stronger tools to verify the correctness of the JIT and those code paths. But hey, retaining the capability to speed up bloated web apps ever so slightly is more important that
timeon 2y ago

skywal_l 2y ago

Andreas (the author of ladybird) started a language[0] that would be memory-safe and in which he would eventually write SerenityOS (and I assume LadyBird too). He hasn't committed to it for 6 months now so not sure what the status is. At the end of the day, LadyBird is still a hobby project, so one of the main objective is to have fun which does not always coincide with rationality (although the decision to move on from NIH[1] is a sign that this might be changing). [0] https://github.com/SerenityOS/jakt https://github.com/SerenityOS/jakt [1] https://en.wikipedia.org/wiki/Not_invented_here https://en.wikipedia.org/wiki/Not_invented_here

jraph 2y ago
Ladybird is sponsored now and I seem to remember that Andreas is paid full time to work on it. I don't think Ladybird is still strictly a hobby project anymore. But it was definitely started as a hobby project so your point still stands, mostly. (to be clear, I'm not answering to the question of which programming language should be used to write Ladybird)
asddubs 2y ago
Jakt was described more as an experiment and to potentially replace C++ in the codebase, rather than definitely. I haven't seen any official word on this but as you imply I would assume that this effort is essentially dead now. Just as with the operating system itself, the focus eventually shifted elsewhere and Jakt was left behind.

gkbrk 2y ago

> why we're still writing applications > Have we not learned our lesson yet Why are you speaking like this project is asking you to write code in C++? You are free to exclusively write Rust. Other people writing C++ has 0 impact on what you're writing or what lessons you've learned.

voidwtf 2y ago
If the eventual goal is to place the application in the hand of users, I think the question has merit.

jraph 2y ago

I'll take an alternative browser engine, even if it's written in C++. > I'm curious Is it really curiosity though? Because the answer is straightforward, the project started as a hobby, the developer picked whatever language they were proficient in. Andreas is open with the fact that he started Serenity OS and LadyBird as a rehab project. Put too much barrier in this setting (like learning a new language and all the ecosystem) and it might not happen at all.

znpy 2y ago
>> I'm curious > Is it really curiosity though? I'm kind of annoyed at this whole train of comments ("I'm curious..."). In so many occasion I see something cool and the main comment track is "why hasn't this been writte in rust?" (or some other allegedly safe/better programming language). It's like seeing a beautiful painting being painted and arguing about the kind of paintbrush the painter has used. It's so sad.
- red_trumpet 2y ago
  > It's like seeing a beautiful painting being painted and arguing about the kind of paintbrush the painter has used. It's like seeing a beautiful painting and realizing the painter didn't use lightfast colors. In ten years the painting will not be beautiful anymore. Yes, the painter / author put in a lot of work, and this deserves acknowledgement. But ones decision to use it or not is not only based on the amount of work put in.
  - account42 2y ago
    It's more like seeing a beautiful painting and complaining that the painter didn't use your favorite brand of paint which promises to be much better looking than the other paints in ten years but hasn't even been around that long.
    - nindalf 2y ago
      This analogy has been tortured beyond usefulness.

flumpcakes 2y ago

It's crap programmers that write buggy code, and they will write similarly buggy code in any language. It's not hard to write memory safe code, most people are not skilled enough to do it. I doubt they will be skilled enough to write good rust.

surgical_fire 2y ago

> but I'm curious why we're still writing applications > Have we not learned our lesson yet, "We"? Do you speak in the name of the developer? What an odd choice of pronoum. Either way, if you are adamant about writing a new browser in your "memory-safe language" of choice, be the change you want made. Go ahead and write a new browser from scratch. Show the world how it should be done.

voidwtf 2y ago
I meant we as in the collective, and I explicitly referenced the collective of those writing applications that process and/or execute user generated content. So no, I don’t think it appropriate to focus my question on the author or this project. I am wondering if C++ is a better choice for reasons I don’t understand when it comes to HTML/JS/CSS, despite potential security implications as the complexity grows.

pjmlp 2y ago

Note that despite that study, Windows and XBox teams are quite found of their C and C++, and even their own .NET has more success on the Azure side, than replacing all those COM/WinRT C++ workloads, and extension points. It is Azure that is more keen in adopting memory safe languages, and has the mandate that new systems code should be done using them.

TacticalCoder 2y ago
> Note that despite that study, Windows and XBox teams are quite found of their C and C++... And we all know how secure the average user's Windows computer is. And Windows' security is so good that it's Windows who's powering tens of billions of servers, smartphones, IoT, appliances, routers etc. throughout the world? Oh, wait, no... These are all running Linux. And the uptime. Let's not forget the uptime with patch tuesday. Windows does not strike me as the ecosystem we should strive to immitate.
- pjmlp 2y ago
  In what language is the Linux kernel written on? https://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33 https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm... Those that have glass ceilings should not throw rocks.

alexvitkov 2y ago

Because rust is a cargo cult. We're nearing 10 years since 1.0 and there's still not a single serious, widely used, large software project to prove its viability. Maybe make one instead of trying to passive aggressively convince others to do it for you?

voidwtf 2y ago
I didn’t mention rust, I don’t know Rust and if I were trying to start a similar project I might do so in .NET Core because of my familiarity with .NET. I’m asking because I don’t know if there is a reason it would not be viable, is the garbage collection too much of a hurdle to get decent performance while trying to interpret JavaScript? Is there too much overhead tracking claims on memory and doing the bounds checks? I’d assume the same checks eventually have to be written in C++ too?
- alexvitkov 2y ago
  I apologize - when people mention "memory safe" nowadays 95% of the time they're talking about Rust, I made an assumption. Interpreting JavaScript at all it at all is a problem. Ladybird's LibJS compiles it to bytecode and interprets that (which is usually better than intereprting the AST). The bytecode interpreter is written in C++, and it's still pretty damn slow - websites take a long time to load, and LibJS is the main bottleneck. The reality is, modern websites throws so much junk at your JS implementation, that you basically need to JIT-compile it in order to have any sort of reasonable performance. And with JIT all memory safety guarantees are thrown out of the window - it doesn't matter if you write your compiler in Rust, C++ or a .NET language - if there's an exploit it's disproportionately more likely to be in the output assembly than it is to be in your compiler. Browsers nowadays make a best effort, and they have a stack of other mitigations in case the JIT leaks: https://chromium.googlesource.com/chromium/src/+/main/docs/design/sandbox.md https://chromium.googlesource.com/chromium/src/+/main/docs/d...
  - voidwtf 2y ago
    This may be the biggest gap in my understanding. I didn’t realize that at some point the JavaScript is turned into instructions running directly on metal, I thought everything occurred within a synthetic/virtual environment.

durandal1 2y ago

Where is the proof that Rust can achieve the productivity and design flexibility needed at browser scale?

einpoklum 2y ago

> writing applications that will almost certainly execute or process hostile content in languages that don't maintain strict memory safe contract? That point is 50% FUD. A language which "maintains strict memory safe contracts" but has an `unsafe` keyword; or has a "native code interface", or uses libraries implemented in a different language, doesn't really strictly maintain its guarantees. And on the other hand, a language in which you can, in principle, load and execute arbitrary code from a string you got from the user, can be hardened very well by statically-checkable constraints. So, it's a matter of degrees rather than absolutes. If you then add considerations such as programming paradigm flexibility and performance, C++ is very much a valid choice even for the use case of a browser.

deleted 2y ago

[deleted]

ArtixFox 2y ago

Because writing a browser in ATS or Frama-C is not possible. Or writing it in Coq and exporting it to ocaml and friends. Ada can be used but its mediocre at best and sucks at places where frama-C shines. A lot of pointer stuff that is easier to prove in ATS or frama-C is impossible in Ada [and by extension of that, rust] TLA+ can be used in mix with C++ just like how 90% of safety critical software is written but the development speed is very slow for it. That leaves Rust, which is a...mediocre language if you really care about safety. It has no idea of linear types that ATS has and cannot carry embedded proofs like Frama-C. Plus the culture regarding safety critical software in C/C++ is humongous and tbh fairly amazing. I cannot remember exactly but there are many projects targeting C++ for safety purposes, even the people behind frama-C are creating something called as frama-Clang to allow writing safety critical code in C++ backed by proofs. Are there any other languages that im missing? If ATS has a prettier syntax, it'd be my candidate for writing a web browser in.