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

161–170 of 204 posts

Re: Welcome to Comprehensive Rust

#161

Post by masklinn »

fulafel wrote: post #154
eloff wrote: post #148

Earlier quoted context omitted.

Rust doesn’t though. But it does make it much harder to leak memory than C. You need to create a cycle between reference counted objects versus just forget to free something. Not that it matters as much as people think. Memory leaks aren’t a correctness problem. You typically want to restart a program or service regularly anyway to deal with memory fragmentation. You also frequently have a watchdog like systemd to re…

Interesting view that memory leaks aren't correctness problems. But I would require more convincing to agree. It's true that memory leaks can be small enough that they don't become problems in the end-to-end behaviour of the system in regular use. But a lot of bugs are like that. For example many memory safety bugs.

> Interesting view that memory leaks aren't correctness problems.

The view of rust is rather that they’re not safety problems.

Whether they’re correctness problems is more complicated: in general they are, but there are lots of cases where they’re not, like short-running processes (once the process terminated it’s memory is reclaimed so freeing it is unnecessary overhead), or FFI (you’re moving memory out of your purview, you can’t know whether it’ll be disposed of anymore).

Re: Welcome to Comprehensive Rust

#162

Post by varajelle »

pjmlp wrote: post #55
Shinmon wrote: post #30

Earlier quoted context omitted.

Most of the errors can already be caught by running `cargo check` which is substantially faster than rust. Coming from C++ rust's compile times don't feel extraordinarily long.

Useless for graphics and GUI programming.

For GUI programming, you can use a toolkit that have a preview extension that updates in real time as you type. For example, Slint does that.

Re: Welcome to Comprehensive Rust

#163

Post by pjmlp »

frou_dh wrote: post #159
pjmlp wrote: post #126

Earlier quoted context omitted.

Most of those features are available in ML derived languages, without having to deal with Rust features that make it usefull C and C++ replacement. With faster compiler toolchains and REPL like tooling.

The trend is to just assume that using GC is off the table, without that being driven by any actual requirements or measurements.

The usual cargo cult.

Re: Welcome to Comprehensive Rust

#164

Post by pjmlp »

adwn wrote: post #157
pjmlp wrote: post #108

Earlier quoted context omitted.

Rust still needs to do a lot of catching up in HPC, HFT, GUI, game engines, console SDKs, OS drivers on Apple and Microsoft OSes, Arduino, LLVM and GCC,... Rust threading is only safe between threads accessing data structures in process own memory. It does nothing for shared resources using OS IPC, or external resources shared among threads. It will certainly improve, as hopefully C++ will, even it never gets 100% as…

> Rust threading is only safe between threads accessing data structures in process own memory. "Only". Intra-process shared memory is by far the most important kind of shared memory. 80% of the time you see someone advocating for message-passing multi-process over shared memory multi-thread concurrency or parallelism, it's because shared mutable memory is incredibly hard to get right in just about every mainstream la…

Not in the age of microservices.

Language constructs only help if there are no other applications accessing the same resources.

Re: Welcome to Comprehensive Rust

#165

Post by gernb »

kibwen wrote: post #31
ohbtvz wrote: post #22

Earlier quoted context omitted.

I'm tired of installation instructions that consist of "curl | sh". Especially since this one just tries to detect the platform and downloads the correct installer for me. I know what platform I'm running, and I don't want to pipe the internet to my shell. In the end this is unpacking a tarball in ~/.rustup, I don't need the risk of running some bespoke script for that.

Since the ultimate objective is to run a binary blob that you just downloaded off of the internet, piping a script to your shell over HTTPS adds no additional attack surface.

piping to the shell might be somewhere in the middle but node's npx is just asking for trouble. You type `npx cmd` and it downloads cmd. Which means any typo could be death

Re: Welcome to Comprehensive Rust

#166

Post by pjmlp »

varajelle wrote: post #162
pjmlp wrote: post #55

Earlier quoted context omitted.

Useless for graphics and GUI programming.

For GUI programming, you can use a toolkit that have a preview extension that updates in real time as you type. For example, Slint does that.

It doesn't do that for Rust code being called from UI.

Re: Welcome to Comprehensive Rust

#167

Post by gernb »

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?

because some people in charge of android mistakenly believed that because some stats claimed Java was the most popular language that chosing Java would lead to the most developers for android (and then they chose Kotlin later beacuse it's a better Java and compatible with the JVM)

IMO, choosing Java was one of the worst decisions they ever made. There's a reason why no other platform (PS5, XBox, iPhone, Mac, Linux, etc..) don't choose a language like Java. Android has so much jank because they chose Java

Re: Welcome to Comprehensive Rust

#168

Post by fulafel »

masklinn wrote: post #161
fulafel wrote: post #154

Earlier quoted context omitted.

Interesting view that memory leaks aren't correctness problems. But I would require more convincing to agree. It's true that memory leaks can be small enough that they don't become problems in the end-to-end behaviour of the system in regular use. But a lot of bugs are like that. For example many memory safety bugs.

> Interesting view that memory leaks aren't correctness problems. The view of rust is rather that they’re not safety problems. Whether they’re correctness problems is more complicated: in general they are, but there are lots of cases where they’re not, like short-running processes (once the process terminated it’s memory is reclaimed so freeing it is unnecessary overhead), or FFI (you’re moving memory out of your pur…

Safety and security as terms have an interesting relationship especially in Rust context - traditionally in engineering safety means defending against accidents and security means defending against malicious attackers, but "safety" in the term "memory safety" commonly implies security as well. Language is hard...

Considing whether memory leaks are a security problem brings us to the traditional CIA definition of security - the A (availability) is at risk from memory leaks.

Re: Welcome to Comprehensive Rust

#169

Post by fulafel »

haradion wrote: post #160
fulafel wrote: post #146

Earlier quoted context omitted.

"Trusting the Rust org not to screw you" is one part, another part is trusting the Rust server operators to defend against server compromise by any third party. So trusting the intentions is not sufficient.

The same thing applies to any binaries downloaded from their site, so unless you you've got signed binaries (that use an independently obtained/verified chain of trust), trusting the server is your your only option. Even with signed binaries, you're still trusting the entity that holds the signing key.

In real world trust is not so binary. In a risk assessment I'd be interested evaluating the level of assurance there is in the supply chain of how you get your binaries and artifacts. Some of it can be done using crypto like you say, some of it could be eg published audit reports from a reputable evaluator or other credible information about the processes.

Re: Welcome to Comprehensive Rust

#170

Post by eggy »

bobajeff wrote: post #150
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…

I've looked a tiny bit into Ada and I like the language. I particularly like the pascal-like syntax and the ranges feature. However I love rusts cargo and build system better than Alire. As Alire seems to bolted ontop of gprbuild. I also find it unfun to go back to forward declaration and definition (ads) files. It also seems to me the rust ecosystem has more libraries in things I'm interested in and better support f…

What libraries are you interested in that Rust has and other PLs do not?

What is your main use of Rust? It all depends on what you are doing. I use Zig for fun game dev stuff, and not SPARK, but for the safety-critical control systems, it's SPARK, not Zig or Rust.

Post reply on HN