Hacker News Reader

Comment by tptacek | Hacker News Reader

The subtext of Rust in posts like this is that Rust compiles programs that are pin-compatible with C/C++ programs. Without rethinking the architecture of a kernel, for instance, you're meant to be able to write Rust drivers.

I prefer other higher-level languages to Rust; I'd rather just work with garbage collection than wrangle the Rust borrow-checker. But if you need to write software that can't abide GC, Rust is basically the only memory-safe game in town.

View on HN

nickp mentioned some alternatives, basically verified C or model-driven development for cases where it really matters.

Anyway, if we stick to standard commercial projects, I'd say the languages I enumerated are solid C++ (and Rust) competitors, because C++ at least isn't used to develop only super-performant or low-level bit twiddling SW, and I don't see why Rust would be either.

Obj-C was a solid C++ competitor on anything Apple and now Swift maybe even more so. It's a great language that can get you 95% there and I can almost guarantee that the remaining 5% won't be Rust, but rather C or C++.

Same goes more or less for Android with Java or Kotlin. Having a GC didn't stop them from becoming the platform standard, despite the embarassing growing pains they had.

It's really a game of platforms. Almost no one would pick a language because it's memory-safe, it's just a standard feature for most kinds of software developed nowadays.

For the SW where Rust and C++ would both be good fit (gaming?, audio, video, etc), C++ is entrenched and it's very unlikely that companies will have to justify using it instead of Rust in 2019 or 2020, erc when it's already the default in the first place.

A hard lesson I took from my experience with Turbo Pascal, Oberon and others, is that platform languages always win in the end.

Better syntax, improved semantics are nice, but if the debugging experience, IDE tooling and integration with platform libraries take a hit, then in the long run, the improvements aren't really worthwile.

However, given that Google (Fuchsia), Microsoft (IoT Core, Azure), Oracle (railcar), Amazon (Firecracker) are testing waters with Rust, I guess it might eventually become a blessed language in some of their systems.

But it will take time for sure, specially regarding tooling parity.

I’ve been trying to correct my instincts from that era for the success of open source. It’s a lot easier now to collaborate, especially without things licensing, and the tools built around things like LLVM seem like a significant shift for the costs of a non-default language.

Not really, you just need to have a look at Android, as open source platform.

Java is the platform language, followed by Kotlin, which even with all Google love of latest, there are still a few corner cases where it isn't 1:1 with Java on the platform.

Finally there is C++, which comes on 3rd, with lots of caveats given the NDK evolution and integration into Studio.

Anything else brings their own set of problems, the headache of having the NDK as entry point into Android and JNI as FFI for Android APIs.

I’m not saying it’s easy now, just easier. Thinking back to the TurboPascal/Delphi era you had to convince people to make a large purchase, and your team had to spend a non-trivial amount of time dealing with compiler code generation, debuggers, and a wide range of less compatible operating systems (when I worked for a compiler vendor, our QA test matrix was ~600 different OS & CPU combinations). That’s a lot to fund out of a smaller revenue stream.

Although I like Rust for those scenarios where GC isn't an option, I bet Ada/SPARK still have more commercial deployments out there.

It might change given the price of their compilers versus free rustc, however those are industries that also certify compilers, which isn't going to happen for the time being for Rust toolchains.

Also Rust still isn't pin-compatible with COM/UWP or Objective-C runtime, and I guess we need to wait around one year until mixed language debugging experience is a thing across all major IDEs.

> Although I like Rust for those scenarios where GC isn't an option, I bet Ada/SPARK still have more commercial deployments out there.

I doubt it, if you're counting users. Hundreds of millions of users of Firefox and Dropbox, just to name the first two that come to mind, use Rust code.

> Also Rust still isn't pin-compatible with COM/UWP or Objective-C runtime

What? Of course it is. We're shipping Rust code that uses COM and Objective-C in Firefox beta, right now (WebRender).

Of course statistics is the art to make the numbers how we like them to be.

On my case I am counting systems in production.

Using COM is a tiny portion of COM development experience.

Where is the Rust support for creating COM and UWP components, including mixed mode debugging on Windows IDEs, likewise for Objective-C integration.

If I missed that, where can I find more about it?

Again, we ship COM components. You can't load local fonts on all versions of DirectWrite without that.

Likewise, Rust has had support for creating Objective-C classes with methods written in Rust for ages. You can't usefully render OpenGL into a window on macOS without doing that.

In that case it would be nice to actually answer my question.

> If I missed that, where can I find more about it?

How do COM type libraries get generated in Rust?

> Also Rust still isn't pin-compatible with COM/UWP or Objective-C runtime

Both COM and Objective-C can be accessed from C, and Rust is compatible with the C FFI.

Since Windows 3.x days actually, but only by those masochist enough to use the C API, or low level OS devs on the respective companies.

Anyone else that praises productivity uses programming languages that take care of the lowlevel boilerplate, and offer high level debugging experience on the respective IDEs.

> Also Rust still isn't pin-compatible with COM/UWP or Objective-C runtime

I found this: https://github.com/SSheldon/rust-objc/

How does it integrate with XCode or AppCode debugging experience, code generation and UI designers?

Debugging works just fine. Cross-language debugging in Xcode even works, because LLVM generates the debug info.

And designing a Core Data model in Rust?

Implementing an XPC server or an IO Kit driver?

Writing Metal shaders?

These are the kinds of issues that I am referring to.

Compile to a static library and drag it into the Xcode sidebar?

What about generating a Core Data model in Rust?

> ...Rust is basically the only memory-safe game in town.

How about thread safety? Are there other thread safe games in town?

As far as I know, only the Pony Programming Language[0] statically ensures identical guarantees as Rust, but it is not 1.0 and the community is tiny. Pony takes a wildly different approach to achieving those guarantees though - and it's more geared towards highly concurrent servers rather than the wide spectrum of programming domains that Rust embodies (embedded, systems, etc). It uses actor-based concurrency, is AOT compiled, has a concurrent GC without stop-the-world collection and ships with a "cache-aware, work-stealing scheduler" runtime. Similarly steep learning curve as Rust with its Reference Capabilities which is Pony's equivalent to Rust's ownership & borrow checker.

[0]: https://www.ponylang.io/discover/

Reply on news.ycombinator.com