Hacker News Reader

Comment by GarryManson | Hacker News Reader

Seems like theres no good reason for rust to do this when vala can -- and better, it just compiles to the same C

Vala has reference counted garbed collection, while Rust doesn't need that. Also, Rust verifies, among other things, the absence of data races.

That's not much good when you're just talking to ahitty GObject APIs that - guess what! - use reference counted GC and have lots of race conditions. You gain nothing

Yes, you do. Your internal logic doesn't need the overhead of reference counting and can be race-free.

This is how Mac apps tend to be fast: the high-level application logic is reference-counted and uses relatively slow Objective-C dynamic method calls, but things that are performance critical (CoreGraphics, VideoToolbox/AudioCodec, OpenGL, sqlite, the Mach kernel) are written in C and C++.

This is also a general pattern in Rust, cf. unsafe blocks: You wrap code that doesn't adhere to Rust's strict rules (e.g. because it interacts with C) in unsafe { }, disabling various compiler checks and requiring you to check it for correctness manually. Unsafe-ness doesn't bubble up, though, i.e. having an unsafe block within doesn't taint, say, a function - allowing you to silo nasty things away and enforce strict checks around it.

I haven't noticed that Mac apps tend to be faster than apps on other platforms. Can you provide a citation for this?

I didn't mean "faster than other platforms", just "not slow". Really it's a testament to the fact that front-end glue logic can often be written in whatever language you want without compromising interactive performance (as long as the implementations of those languages don't require long pauses or something like that), which is something we've known for a long time.

Heck, when doing Objective-C I'd drop down to C++ as quickly as possible just because the language is nicer. I'd be even more inclined to drop down to Rust.

Reply on news.ycombinator.com