4 ms·

I was a security researcher since 1992. I don't mean to sound arrogant, but why continue to use languages that lead to security holes when we now have a languag

I was a security researcher since 1992. I don't mean to sound arrogant, but why continue to use languages that lead to security holes when we now have a language that it strongly resistant to most of those failings? Rust isn't just type safe or memory safe - eliminating foot-guns was a guiding principle throughout. People hate the borrow checker, but that concept of ownership eliminated broad classes of concurrency bugs. Rust was a godsend for computer security.

neya 4y ago
Security is just one aspect of web application development. Writing in rust doesn’t guarantee an application free of security issues like how writing in another language doesn’t necessarily guarantee an app full of security issues.
- jimmydoreornot 4y ago
  The odds of correct operation are higher with Rust, and for some people that matters a lot to them. There are plenty of good reasons not to use rust. If your use case doesn't care about security, fine use whatever. Or if time-to-market is critical, use go or whatever. Or if your organization can't handle the risk that when you leave they can't find another good rust developer, then don't use it.
closeparen 4y ago
Memory safety is the main thing though, and people were not normally practicing web development in C. For concurrency safety, there are a number of approaches from functional programming/immutability, to the actor model, to even PHP's shared-nothing architecture. And then there's the whole area of type safety, fancy type systems, dependent types, etc. Rust doesn't seem to be a particular standout for web application correctness in the same way that it is for systems code (where memory safety issues are indeed a huge deal), although you could certainly do worse.
- dhzhzjsbevs 4y ago
  Wasn't most of Google and eBay written in C/C++? Most of the webs applications were written in C/C++ pre PHP days.
  - saghm 4y ago
    I think the original question here was asking about frontend since this post is about using Rust with web assembly as an alternative to JavaScript. There's no need to use web assembly to use Rust on the backend, nor is there any reason why you couldn't use JavaScript on the frontend if you were using Rust on the backend. As much as I love Rust and prefer to avoid writing JavaScript, I think the arguments for using Rust on the frontend are a lot less clear right now given the hoops you'd need to jump through. If wasm ends up getting proper access to the DOM, that might change, but I'm out of the loop and have no idea if there's any planned timeline for that at all, let alone when that might be.
  - icedchai 4y ago
    Many folks were using Perl CGI scripts, or ASP (VBScript.)
- deleted 4y ago
  [deleted]
ozzythecat 4y ago
> Rust isn't just type safe or memory safe - eliminating foot-guns was a guiding principle throughout. People hate the borrow checker, but that concept of ownership eliminated broad classes of concurrency bugs. Rust was a godsend for computer security. How often are folks writing server side code where they need to pass objects across thread boundaries? Back end logic is usually straightforward. Each request uses a single thread. Maybe there’s some client library that has a thread pool, for things like reusing connections. But that’s about it. Is Rust a security silver bullet? Are the other languages obsolete? Is there nothing simpler than Rust, because the borrow checker saves you from doing things you can do in C++, and that’s what we should all optimize for? Again… why do I need Rust and WASM for serving web pages? It sounds like you’re saying security is the number one non functional requirement and is the only requirement, which I don’t think is accurate. Even then, entire companies are running on JVM. If I have a C++ use case, I can maybe see using Rust benefits in some areas, although the learning curve is very steep.
- switchbak 4y ago
  Backend logic is not necessarily straightforward, that depends completely on your domain. Each request uses a single thread? In the stuff I'm working on we often orchestrate asynchronous operations across many different systems, that alone would involve a lot of parallelism and concurrency. We lean heavily into functional code with immutable data, but we're not writing a systems level program. If you're doing much beyond simple crud, I imagine you're going to want a lot of what you're describing fairly quickly.
  - ozzythecat 4y ago
    > If you're doing much beyond simple crud, I imagine you're going to want a lot of what you're describing fairly quickly. There are different models for asynchronous execution across different systems. Even then, Rust isn’t a silver bullet. A request can be scoped to a single thread, and then messages can passed across systems (queues, pubsub, etc), stored to a database, etc etc. Not having concurrency within a single process doesn’t mean someone is doing simple CRUD, unless you’ve mistaken Facebook.com, Twitter, and Amazon retail website to all be simple CRUD applications. Rust seems like a solution for your very specific use case, or it’s better suited for C++ and systems programming scenarios. The borrow checker is a pain in the ass to use. Presenting Rust as silver bullet and ignoring its cost is misguided and near sighted at best. It’s not just Rust but saying <X> is the perfect solution is generally wrong. Every thing has a cost.
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
lolbutwtfsrsly 4y ago
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust Rust only appears safe when compared to C. Many languages have even better support for writing correct programs (thanks to garbage collection, arbitrary-precision arithmetic, message-passing concurrency, contracts, etc.)

neya 4y ago

Security is just one aspect of web application development. Writing in rust doesn’t guarantee an application free of security issues like how writing in another language doesn’t necessarily guarantee an app full of security issues.

jimmydoreornot 4y ago
The odds of correct operation are higher with Rust, and for some people that matters a lot to them. There are plenty of good reasons not to use rust. If your use case doesn't care about security, fine use whatever. Or if time-to-market is critical, use go or whatever. Or if your organization can't handle the risk that when you leave they can't find another good rust developer, then don't use it.

closeparen 4y ago

Memory safety is the main thing though, and people were not normally practicing web development in C. For concurrency safety, there are a number of approaches from functional programming/immutability, to the actor model, to even PHP's shared-nothing architecture. And then there's the whole area of type safety, fancy type systems, dependent types, etc. Rust doesn't seem to be a particular standout for web application correctness in the same way that it is for systems code (where memory safety issues are indeed a huge deal), although you could certainly do worse.

dhzhzjsbevs 4y ago
Wasn't most of Google and eBay written in C/C++? Most of the webs applications were written in C/C++ pre PHP days.
- saghm 4y ago
  I think the original question here was asking about frontend since this post is about using Rust with web assembly as an alternative to JavaScript. There's no need to use web assembly to use Rust on the backend, nor is there any reason why you couldn't use JavaScript on the frontend if you were using Rust on the backend. As much as I love Rust and prefer to avoid writing JavaScript, I think the arguments for using Rust on the frontend are a lot less clear right now given the hoops you'd need to jump through. If wasm ends up getting proper access to the DOM, that might change, but I'm out of the loop and have no idea if there's any planned timeline for that at all, let alone when that might be.
- icedchai 4y ago
  Many folks were using Perl CGI scripts, or ASP (VBScript.)
deleted 4y ago
[deleted]

ozzythecat 4y ago

> Rust isn't just type safe or memory safe - eliminating foot-guns was a guiding principle throughout. People hate the borrow checker, but that concept of ownership eliminated broad classes of concurrency bugs. Rust was a godsend for computer security. How often are folks writing server side code where they need to pass objects across thread boundaries? Back end logic is usually straightforward. Each request uses a single thread. Maybe there’s some client library that has a thread pool, for things like reusing connections. But that’s about it. Is Rust a security silver bullet? Are the other languages obsolete? Is there nothing simpler than Rust, because the borrow checker saves you from doing things you can do in C++, and that’s what we should all optimize for? Again… why do I need Rust and WASM for serving web pages? It sounds like you’re saying security is the number one non functional requirement and is the only requirement, which I don’t think is accurate. Even then, entire companies are running on JVM. If I have a C++ use case, I can maybe see using Rust benefits in some areas, although the learning curve is very steep.

switchbak 4y ago
Backend logic is not necessarily straightforward, that depends completely on your domain. Each request uses a single thread? In the stuff I'm working on we often orchestrate asynchronous operations across many different systems, that alone would involve a lot of parallelism and concurrency. We lean heavily into functional code with immutable data, but we're not writing a systems level program. If you're doing much beyond simple crud, I imagine you're going to want a lot of what you're describing fairly quickly.
- ozzythecat 4y ago
  > If you're doing much beyond simple crud, I imagine you're going to want a lot of what you're describing fairly quickly. There are different models for asynchronous execution across different systems. Even then, Rust isn’t a silver bullet. A request can be scoped to a single thread, and then messages can passed across systems (queues, pubsub, etc), stored to a database, etc etc. Not having concurrency within a single process doesn’t mean someone is doing simple CRUD, unless you’ve mistaken Facebook.com, Twitter, and Amazon retail website to all be simple CRUD applications. Rust seems like a solution for your very specific use case, or it’s better suited for C++ and systems programming scenarios. The borrow checker is a pain in the ass to use. Presenting Rust as silver bullet and ignoring its cost is misguided and near sighted at best. It’s not just Rust but saying <X> is the perfect solution is generally wrong. Every thing has a cost.

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

lolbutwtfsrsly 4y ago

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust Rust only appears safe when compared to C. Many languages have even better support for writing correct programs (thanks to garbage collection, arbitrary-precision arithmetic, message-passing concurrency, contracts, etc.)