Why not incrementally convert it to modern C++?
If the code base needs to be rewritten anyway, why not to a memory safe language. Can be converted incrementally to Rust, too, because in the end its all machine code.
Apple is looking for engineers to convert its code from C to Rust
201–210 of 240 posts
Re: Apple is looking for engineers to convert its code from C to Rust
#202I'd love a Rust job, but there are so few roles out there, nearly everything is Javascript/Python/Java. Is it worth even learning?
Apple is looking for engineers to convert its code from C to Rust
Re: Apple is looking for engineers to convert its code from C to Rust
#203Earlier quoted context omitted.
C is far from zero-abstraction-cost. For example you can't do a generic qsort supporting user defined types with zero overhead, other than with preprocessor macros (ugly, unsafe, unmaintainable).
This sort of standard seems hard to meet for any language, if the bar is "all abstractions should be included and zero-cost." In practice, you probably write a specialized quicksort for a given type in C to work around the lack of generic quicksort. You do this in the same way you manually convert your suspendable forkable computations into a struct that has all your "local variables" and an "instruction counter" ins…
So there's an intrinsic cost to abstractions: namely that by using an abstraction, you're not specializing to the optimal extent possible; your general-purpose algorithm may well be close to ideal, but various details will not be; and even in languages that support specialization, you're likely to end up in a not quite optimal solution.
But that's not what people usually mean with zero-cost, right? They mean that assuming you do use the same algorithm, then the abstracted version is just as fast and memory efficient as the specialized version.
And that is a bar that C++ at least clearly meets, and, by the looks of it, rust is in practice much closer than C. Other languages have various features that address this need too; it's not that rare. C really is particularly poor here, but even C has macros, and although it's horrible in terms of usability, people nevertheless manage to do some pretty nifty stuff with macros.
Still; it's fair to say C is pretty bad at zero-cost abstractions, and that widely used alternatives support that a lot better (even C++ alone is a solid chunk of the market, more than C - https://redmonk.com/sogrady/2020/02/28/language-rankings-1-2...) Implementing a custom quicksort in C is a pain, enough pain that I expect most hand-tuned special case quicksorts are likely slower than general versions available for C++ simply because people aren't going to bother doing a good job; it's too much work. And that's just quicksort; the same goes for lots and lots and lots of other things too; reimplementing everything from scratch is just too much pain - in practice people are likely to not bother, and just pay the costs.
So while "zero-cost" abstractions are a slightly nebulous goal, clearly C in particular is worse at providing those than all of its low level competitors and wannabe competitors (C++, Rust, D, Nim, etc).
Re: Apple is looking for engineers to convert its code from C to Rust
#204Earlier quoted context omitted.
How is he managing to post these comments repeatedly? I need to make a new account here every day or two because I get flagged almost immediately.
Ah, is this your 45th account @gasthem_1? :P
No, on HN I usually just type something related to whatever is on my mind at the time.
No prizes for guessing what it was this time.
Re: Apple is looking for engineers to convert its code from C to Rust
#205Earlier quoted context omitted.
Swift compiles and runs on Linux.
It’s only supported on Ubuntu, not Linux in general, and it still lacks. The corporate backing is missing, and IBM going away from the Server-side Swift deal doesn’t spread confidence. The whole ecosystem just isn’t there (yet?). This rewrite isn’t only related to the current situation on Linux, but also to Swift’s current performance characteristics. Lack of full Linux support is just another hindrance, before you c…
If it runs on Ubuntu it runs on nearly any Linux distribution.
Re: Apple is looking for engineers to convert its code from C to Rust
#206I'd love a Rust job, but there are so few roles out there, nearly everything is Javascript/Python/Java. Is it worth even learning?
>nearly everything is Javascript/Python/Java.
That's depends on where you are living (if you are looking for a local job of course).
But sure, Rust is a pretty new language with a relatively high entry threshold.
Is it worth learning? Yes if you are planning to do system\relatively low-level stuff in the future.
Re: Apple is looking for engineers to convert its code from C to Rust
#207Earlier quoted context omitted.
Rust does not have classes.
In the wild, the meaning of class ranges from whatever it means in the bowels of theoretical OOP, to a struct that has thing.method() invocation syntax. I'd wager about 99% of people don't get more academic about what classes are beyond the latter definition since it's the only way in their language to create a group of state and then associate some methods with it, which is exactly what Rust has.
I think in the general case, you are absolutely correct.
In a sub-thread comparing language features of two languages to each other to compare their overall complexity, I think it pays to be precise.
Re: Apple is looking for engineers to convert its code from C to Rust
#208Earlier quoted context omitted.
It hasn't solidified for the same reason that C++ in many ways still hasn't solidified. Software is a very young industry by many standards and we still haven't found the best way to make it. Rust is one way to do it, but there are many others besides, in the end which tool wins out is less important than that we make some progress and get out of the tar-pit that we've been stuck in for the last two decades. All we s…
idk man, people can dish out complicated, hard tested, reliable systems in a really short time. most aspects of most languages have been severely altered and improved...
> idk man, people can dish out complicated, hard tested, reliable systems in a really short time
You must be living in some alternative universe. What I typically come across, even in fairly young companies, is tech debt ridden, buggy, endless cakes of layer upon layer of mostly cruft with a spiffy looking front thrown over the whole. Pretty icing on a crappy cake. As soon as you lift that top layer the illusion crumbles. I'd be happy to bet that most companies that run services out there would not survive a hostile audit of their code and systems.
Re: Apple is looking for engineers to convert its code from C to Rust
#209I'd love a Rust job, but there are so few roles out there, nearly everything is Javascript/Python/Java. Is it worth even learning?
IMHO it's worth learning at least to internalize the concept of ownership. Ownership in some form exists in most languages, but Rust makes it very explicit. It guides you towards clearly organizing program's data into isolated tree-like structures, instead of a web of everything referencing everything else. Like Lisp, even if you don't use it, it may change how you think about code.
I see companies adopting Rust internally. Instead of hiring "Rust developers" they just add Rust to the stack and let their devs learn it. For example, Cloudflare writes most new code in Rust, but Rust is barely mentioned in the job postings.
Re: Apple is looking for engineers to convert its code from C to Rust
#210doesn't Apple prevent engineers from having related engineering hobbies when they sign the contract ?
From my friends that work there - the answer is "it's complicated". Some of them do get away with it, obviously such as those that work on open-source software at Apple (like Safari, Darwin, etc) - or those with non-computer-related side-projects like photography or artisanal furniture making... Apple seems to have inherited Microsoft's previous institutional paranoia about open-source software: the legal dept is con…
> Some of them do get away with it, obviously such as those that work on open-source software at Apple (like Safari, Darwin, etc)
To be clear, Safari is closed source, while WebKit is worked on mostly in the open. XNU is semi-frequently released as source dumps.