Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Welcome to Comprehensive Rust

google.github.io

Post reply on HN
Print view View original

131–140 of 204 posts

Re: Welcome to Comprehensive Rust

#131

Post by jeremyjh »

pornel wrote: post #121
jeroenhd wrote: post #70

Earlier quoted context omitted.

Which is why many people choose to only install software from their trusted distro maintainers who add a layer of vetting for random software packages, often built from source so messing with the package isn't possible without leaving some kind of trace that can be detected later.

Your distro's overworked maintainer isn't reviewing 15+ million lines of code included in Rust. Most likely they get the precompiled rustc binary just like rustup, and LGTM-YOLO the package. If they try to be diligent, they maybe take extra 150K lines of mrustc code they can't reasonably carefully review for backdoors either, and then use it to bootstrap the several sets of 15M lines of code they won't look at.

The one thing you may get in using your distribution is protection for the case that the rustup.sh website has been temporarily pwned. But I agree that focusing on curl | sh is nonsense.

Re: Welcome to Comprehensive Rust

#132

Post by eklavya »

candiddevmike wrote: post #103
rapsey wrote: post #8

Earlier quoted context omitted.

Slower compile times are a small price to pay for memory safety and much higher productivity.

I get those with Go and I have blazing fast compile times too.

Really? Do you get compile time deterministic memory management while being much more high level than Go?

There are trade-offs, rust makes one, use it if it makes sense but these comparisons are just pointless. This whole thread is filled with such arguments. Sure use OCaml, Haskell, Go whatever suits your needs. But let's not pretend that they achieve at compile time what rust does.

Somebody is complaining about compile time, somebody says GC alternatives exist. No, if you are getting into Rust you pretty much know the trade offs. It's on you if you choose Rust somewhere where a GC, REPL providing alternative would have been enough. The miracle of Rust to me is that I usually find Rust high level enough to not have to bother with the alternatives most of the time. I would write my UIs in flutter and my web frontends in TS. I am under no illusion that a GC language would not be more productive in most cases.

Re: Welcome to Comprehensive Rust

#133

Post by thesuperbigfrog »

celurian92 wrote: post #119
eggy wrote: post #86

I still play with Rust (and Zig), but I have decided to put my work efforts into SPARK[1], the subset of Ada, for high-integrity software and formal verification. I know AdaCore and Ferrous Systems are collaborating in trying to bring a lot of Ada/Spark's capabilities to Rust, but this is still going to be some time. Ada has a longer legacy in this game. I am working on safety critical control systems and there is a…

what resources can you suggest to learn formal verification and implement it to make high integrity fault tolerant services? I am quite intrigued by AdaCore. Want to try it out. I dont know much about Formal Verification.

https://en.wikipedia.org/wiki/Formal_verification

AdaCore SPARK Introduction: https://learn.adacore.com/courses/intro-to-spark/index.html

https://www.synopsys.com/verification/static-and-formal-veri...

Re: Welcome to Comprehensive Rust

#134

Post by sanderjd »

nf17 wrote: post #109

Unrelated: but why does Google use Kotlin(for developing Android apps) and Rust when they have a nice little language in Go. Genuinely curious: Is Go not a good fit for developing Android apps(Is targeting JVM the concern?) or system programming(using Rust in Android systems), what does it lack?

My take is that Java -> Kotlin was a very natural progression, as they are very similar languages with an identical runtime in the jvm. Kotlin is just a better Java, which is incredibly easy to adopt into an existing Java ecosystem.

But then they also wanted a more bare metal environment in addition to that. So something like C, C++, or Rust.

It's always been unclear whether Go belongs in that list. It was conceived or at least positioned as a "systems" language like those I listed, and there was noise early on about it replacing C++ codebases at Google, but with over a decade of hindsight now, I think in practice it's pretty clearly a Java replacement rather than a C++ replacement. (I guess there's a fun symmetry here in that Java was also conceived as a C++ replacement and also wasn't.) But Kotlin is just a much more natural way to fill the Java replacement niche on Android.

Re: Welcome to Comprehensive Rust

#135

Post by galangalalgol »

eggy wrote: post #86

I still play with Rust (and Zig), but I have decided to put my work efforts into SPARK[1], the subset of Ada, for high-integrity software and formal verification. I know AdaCore and Ferrous Systems are collaborating in trying to bring a lot of Ada/Spark's capabilities to Rust, but this is still going to be some time. Ada has a longer legacy in this game. I am working on safety critical control systems and there is a…

People have picked stranger things than julia for safety critical control systems. I know people have generated it from simulink and have used labview, and it wouldn't surprise me if somewhere someone is using an excel macro to control the pressure system on a boiler... The world is a scary place.

Reading theough the spark tutorials and examples seems fairly similar to the rustlings excercise. I find the ways spark prevents problems, like forbidding side effects, is more onerous than the borrow checker making me specify a lifetime every so often. I'm not saying you are wrong to prefer spark, just that people with different backgrounds will find the learning curves different. You have been programming longer than I've been alive, so you certainly have a different perspective. I started with c64 basic then c on the amiga 500, then x86 assembler on 386, them turbo pascal, then turbo c++ on the 386.

I can't argue that spark isn't more mature for formal verification, but it feels like formal verification relies heavily on correct contract specifications with no way to measure when your contracts are correct. Unit tests and coverage at least give me a little feel good that I wrote enough tests for my rust.

Re: Welcome to Comprehensive Rust

#136

Post by gpderetta »

kibwen wrote: post #65
ohbtvz wrote: post #61

Earlier quoted context omitted.

You can't check the hash of something you immediately piping to your shell, for example.

Checking the hash isn't relevant here. The content is served via HTTPS, you either trust the host or you don't. A host can easily serve you a malicious binary, as well as the valid hash of that malicious binary.

you might have another known-good source of the hash.

Re: Welcome to Comprehensive Rust

#137

Post by hedora »

nf17 wrote: post #109

Unrelated: but why does Google use Kotlin(for developing Android apps) and Rust when they have a nice little language in Go. Genuinely curious: Is Go not a good fit for developing Android apps(Is targeting JVM the concern?) or system programming(using Rust in Android systems), what does it lack?

Not sure why they picked Kotlin (probably JVM interop) or Rust, but Go's thread safety is closer to C++ than Rust. I think of it as an excellent python replacement, not a C++ replacement.

Re: Welcome to Comprehensive Rust

#138

Post by toyg »

FridgeSeal wrote: post #100
toyg wrote: post #56

Earlier quoted context omitted.

Rust is a safer C/C++. If you'd never consider writing anything in C/C++ (i.e. low-level code where performance is essential), you'll never use Rust.

That’s underselling it quite a lot. Rust has a number of features (ergonomic and technical) and some really nice language design that permits writing quite “high-level” code. Personally, having a compiler and type system as powerful as Rusts makes it worthwhile alone.

It's nowhere as ergonomic, for the general population, as the likes of Python. References alone add a level of bothersomeness to the language that dramatically restricts its appeal.

Rust has a great role to play, replacing C and C++ in all performance-critical and security-critical underpinnings of modern computation (from kernels to UI toolkits). But higher up the stack, where those concerns are outweighed by overall development costs, other languages will continue to rule; and if one's focus is there, learning Rust is probably a waste of time.

Re: Welcome to Comprehensive Rust

#139

Post by [deleted] »

nf17 wrote: post #109

Unrelated: but why does Google use Kotlin(for developing Android apps) and Rust when they have a nice little language in Go. Genuinely curious: Is Go not a good fit for developing Android apps(Is targeting JVM the concern?) or system programming(using Rust in Android systems), what does it lack?

[deleted]

Re: Welcome to Comprehensive Rust

#140

Post by ngrilly »

galangalalgol wrote: post #135
eggy wrote: post #86

I still play with Rust (and Zig), but I have decided to put my work efforts into SPARK[1], the subset of Ada, for high-integrity software and formal verification. I know AdaCore and Ferrous Systems are collaborating in trying to bring a lot of Ada/Spark's capabilities to Rust, but this is still going to be some time. Ada has a longer legacy in this game. I am working on safety critical control systems and there is a…

People have picked stranger things than julia for safety critical control systems. I know people have generated it from simulink and have used labview, and it wouldn't surprise me if somewhere someone is using an excel macro to control the pressure system on a boiler... The world is a scary place. Reading theough the spark tutorials and examples seems fairly similar to the rustlings excercise. I find the ways spark p…

I started working with functional safety only two years ago, and I've been surprised when colleagues expressed that Simulink was actually the go-to solution for functional safety software where they were working before. The logic being that the Simulink toolchain is qualified for functional safety, and if you use it in combination with a qualified C toolchain and RTOS, then you're good to go, certification-wise.
Post reply on HN