171–180 of 355 posts
> This project was a cloud-based SaaS product that is, more-or-less, a conventional CRUD app I would love to hear what tech stack (or stacks) the HN community thinks currently allows a small team to move fastest for this type of product.
Earlier quoted context omitted.
I would argue that a stronger type system will generally reduce bugs, and some of those bugs will impact users (whether by corrupting their data, or breaking a feature, or even causing a security issue). Most bugs are from the programmer having a misunderstanding about how the system works as they change it. The stronger the type system, the more potential misunderstandings can be verified statically by the compiler…
Stronger type systems do reduce bugs. But not all bugs are equal. When we talk about "velocity vs. safety" tradeoffs in SAAS software, we're virtually always talking about security vulnerabilities. There, it's much less clear that stronger type systems reduce vulnerabilities; in fact, the evidence mostly cuts the other way. As far as security is concerned, the major win is memory safety, and you can get that with pla…
I've decided to pick an arbitrary list of security issues where the fixes will be visible to gain some small anecdotal evidence. The top result for "gitlab CVEs" is this august release announcement, let's look at the first three vulns on it: https://about.gitlab.com/releases/2022/08/30/critical-securi...
1. Remote Command Execution via GitHub import
This one was a typeing issue where an object with special keys resulted in dynamic code execution. That could not happen in rust. See the hn discussion here - https://news.ycombinator.com/item?id=33155527
2. Stored XSS via labels color
This can be made into a type-system issue with a good enough type system, text and html should be different types. Arguably this could happen with rust, but honestly, probably would not.
3. Content injection via Incidents Timeline description
This one is also arguably a typing issue for the same reason as above.
----
Hey, look, 3 errors that type systems would help with and which had security implications.
> it's much less clear that stronger type systems reduce vulnerabilities; in fact, the evidence mostly cuts the other way.
What do you mean by that? In what case is a worse type-system (like java or go) going to make it harder to write vulnerabilities than a stronger type system (like haskell or rust)
I've seen a pretty clear difference in success with less popular technologies based more on management philosophy and culture than the technologies themselves. Management seeing individual developers as fungible—"lack of fungibility in the engineering team can be a real liability"—is a massive red flag in this regard. I am not surprised to hear Rust didn't work out in an environment like that!
Yeah, the infamous tin soldier approach that's often used to excuse using worse but more entrenched languages.
Earlier quoted context omitted.
God I get tired of the if err criticism with Go. I truthfully don't even notice it when I write Go, I don't understand why folks get so bent out of shape over it.
That just means you have written a lot of go. I truthfully don't notice lifetimes or the borrow checker most of the time when I write rust. I actually think that, ironically, the if err problem with go is worse for reading code than writing code. If you are used to the pattern it's not that difficult to add the `if err != nil` after a fallible function call, and as is mentioned elsewhere, linters can help catch if yo…
Rust's default paradigm for memory management seems more significant of a language feature in my opinion and is what I can imagine most people don't like. A lot of the programs I write don't fall into the class of problems Rust is trying to prevent which makes the restrictions it enforces bothersome for me.
Earlier quoted context omitted.
This doesn't match my experience. It took some time to get up to speed, but at this point it's much faster for me to write something in Rust than in other languages that I'm proficient in that are ostensibly faster to develop in (e.g., JavaScript). Part of this depends on one's bar for quality. In Node.js I could write `JSON.parse(input).foo.bar` really quickly. In Rust, I'd probably write two struct definitions with…
> This doesn't match my experience. Does it match the experience of a team and its need to collaboratively deliver software quality across varying levels of engineer experience? If not, then I'm not sure your individual experience is pertinent to the subject matter at hand (using Rust at a startup).
Earlier quoted context omitted.
That just means you have written a lot of go. I truthfully don't notice lifetimes or the borrow checker most of the time when I write rust. I actually think that, ironically, the if err problem with go is worse for reading code than writing code. If you are used to the pattern it's not that difficult to add the `if err != nil` after a fallible function call, and as is mentioned elsewhere, linters can help catch if yo…
I don't see how that's a specific problem of the Go programming language though. Rust still has option types and the cases where an Option could be None still need to be handled. Maybe the big difference is the compiler forcing the handling of this case but it seems like a small thing for experienced programmers. Rust's default paradigm for memory management seems more significant of a language feature in my opinion…
And rust has the `?` operator, as well as combinators like `map`, `and_then`, `unwrap_or_else`, etc. which IMO make the flow much easier to follow than say `if option.is_none() { return None }`.
> Rust's default paradigm for memory management seems more significant of a language feature in my opinion and is what I can imagine most people don't like
I never said it wasn't. My point is that if you use a language enough you get used to things that are difficult for people less experienced with that language.
Ruby on Rails certainly isn't perfect, but it's a highly battle-tested web framework. It's been so widely used for so long that you can have high confidence that you won't run into any bugs that will require digging into the guts of it. You can write code against it and be highly confident that any bugs or misbehaviors are in your code, with difficulty of finding and fixing dependent only on how good the code you've written is.
With Rust, I don't think that's the case. The DB and web server related libs just don't seem to have that much manpower behind them, and haven't had big complex services built on them in production for years. If you want to do anything mildly complex, there's a good chance you'll have to dig into the guts of these to figure out what's really happening or to resolve some weird bug or add a feature. That'll require a lot of skill, even if the code you're actually writing is mostly straightforward.
Earlier quoted context omitted.
Stronger type systems do reduce bugs. But not all bugs are equal. When we talk about "velocity vs. safety" tradeoffs in SAAS software, we're virtually always talking about security vulnerabilities. There, it's much less clear that stronger type systems reduce vulnerabilities; in fact, the evidence mostly cuts the other way. As far as security is concerned, the major win is memory safety, and you can get that with pla…
Most vulnerabilities in boring web apps are not memory safety issues. I've decided to pick an arbitrary list of security issues where the fixes will be visible to gain some small anecdotal evidence. The top result for "gitlab CVEs" is this august release announcement, let's look at the first three vulns on it: https://about.gitlab.com/releases/2022/08/30/critical-securi... 1. Remote Command Execution via GitHub impor…
There are exactly two types of vulnerabilities Rust (and some other modern memory-safe languages) mitigate beyond memory corruption:
1. Java, Python, and Ruby have deserialization libraries that can easily be misused to create RCE vulnerabilities.
2. Python, Ruby, and Javascript have eval and eval-equivalents (which is essentially what your first example is).
You can pretend anything is a type system issue, but neither of these two vulnerabilities are properly understood as type safety errors. Java has a sharply more prescriptive and policed type system than Ruby does, but both have deserialization issues; it's just a generational thing.
Deserialization in new Java code is unlikely; deserialization is much less common than SSRF, which plagues Rust code just like everything else. In 2022, there is no meaningful security benefit to Rust over Java.
There are other reasons to use Rust! People should just stop making up fake security reasons to do it.
Earlier quoted context omitted.
I don't see how that's a specific problem of the Go programming language though. Rust still has option types and the cases where an Option could be None still need to be handled. Maybe the big difference is the compiler forcing the handling of this case but it seems like a small thing for experienced programmers. Rust's default paradigm for memory management seems more significant of a language feature in my opinion…
> Rust still has option types and the cases where an Option could be None still need to be handled And rust has the `?` operator, as well as combinators like `map`, `and_then`, `unwrap_or_else`, etc. which IMO make the flow much easier to follow than say `if option.is_none() { return None }`. > Rust's default paradigm for memory management seems more significant of a language feature in my opinion and is what I can i…
People complain about Go's wordy error handling, but systems programming is error programming. The places where Go's error handling is most annoying is in application code, where you'd ordinarily EAFP instead of LBYL. But that's also the code Rust is least convenient for.
Go vs. Rust is truly the dumbest programming language slapfight in the entire industry.
> Rust is awesome, for certain things. > This project was a cloud-based SaaS product that is, more-or-less, a conventional CRUD app: it is a set of microservices that provide a REST and gRPC API endpoint in front of a database, as well as some other back-end microservices Of course. Use Java/Kotlin or Node.js/Typescript or Go or Python for your basic web services. Easy test: Would you at least seriously consider usin…
The difference between C++ and Rust here is that Rust has a large variety of easily-accessible third-party libraries you can drop in with a one-line change to your Cargo.toml. I think the assessment is no longer that straight-forward. There's some solid crates for building these types of endpoints now, but an honest self-assessment is required to see if it really meets your needs from a staffing perspective. I'm a Ru…