Live data from Hacker News

Apple is looking for engineers to convert its code from C to Rust

jobs.apple.com

231–240 of 240 posts

Re: Apple is looking for engineers to convert its code from C to Rust

#231

D now has an Ownership/Borrowing system implemented (though it is in its early stages). It will work with existing code, including DasBetterC code. You're able to incrementally adapt a program to O/B rather than rewrite it.

Walter, have you seen http://aardappel.github.io/lobster/memory_management.html ? If you looked at refcounting, this may be a way to make that compile time.

Re: Apple is looking for engineers to convert its code from C to Rust

#232

doesn't Apple prevent engineers from having related engineering hobbies when they sign the contract ?

Apple makes you sign the same contract that e.g. google makes you sign, which says basically "I sign away all rights to anything I create to the maximum extent legally permissible under California law" (You can look up what those exceptions). For companies like Apple, this basically means they own everything you might do, since their "area of business" in essentially limitless. However, once I signed away my rights,…

And at Microsoft we didn’t need any approval at all for things done in our own time and own equipment - provided it wasn’t competing with anything the company was working on.

It gets better: during the Windows 8 launch and for the life of Windows Phone 8/10 we were actively encouraged to build own apps for their respective App Stores (cynically this was in-part to boost app count numbers, but also to make us motivated to dogfood the platform, provide feedback, etc). IIRC we were expressly permitted today use company hardware too - just not during core business hours. That said, I openly worked on my never-released clone of “Lose Your Marbles” during my downtime in our teamroom office during the day - right in front of our team’s Partner-level director who didn’t bat an eyelid...

Re: Apple is looking for engineers to convert its code from C to Rust

#233
post #229

Earlier quoted context omitted.

> Cloudflare writes most new code in Rust, I think you might be over-stating this. We do write a bunch of Rust though!

I mean newly started projects. Of course there's a ton of existing code to maintain, but — at least in my team — Rust is the default for new services.

I am glad to hear it. My team doesn’t work that way :) (we actually just did a spike in Rust and are going to end up doing the final version in Go, for a few reasons.)

Re: Apple is looking for engineers to convert its code from C to Rust

#234
post #94
post #54

As a human of color, don't think I could live in this town but maybe team is really fun. Interesting to see a Camrose here! I've driven by numerous times. Feel free to ask any questions about Alberta.

> As a human of color, don't think I could live in this town Are you saying it's a racist town, or yourself objecting to its current demographic?

I didn't mean it is a racist town. The population of the town is 18,742 and from years of living in Alberta, I don't think I'd find people with similar taste or interest in activities or topics I'm interested in.

Re: Apple is looking for engineers to convert its code from C to Rust

#235
post #94

Earlier quoted context omitted.

> As a human of color, don't think I could live in this town Are you saying it's a racist town, or yourself objecting to its current demographic?

Not OP, but I would imagine being one of the only minorities in a town like that is difficult if you just want a nonchalant life.

Thanks, that's what I meant.

Re: Apple is looking for engineers to convert its code from C to Rust

#236
post #180

Earlier quoted context omitted.

> There's nothing sad about it. Why? It's a drop-in replacement for Objective-C that allowed you to dip into C and C++ code in the same code file, even in one function. Now Swift is faster for most higher level scenarios a front-end developer deals with but it's slower than the C performance Objective-C allowed.

I.e. it isn't a drop-in replacement. There is nothing wrong about a language not being good at something. When you want to have everything, you get C++. And working with C++ is just sad.

> you want to have everything, you get C++.

C++ is an excellent example on the perils of developing a tool that's good at everything, because the cognitive load to do anything with it is simply not manageable.

Picking the right tool for the job is always the solution.

Re: Apple is looking for engineers to convert its code from C to Rust

#237
post #189

Earlier quoted context omitted.

You are saying that like it must then be as fast as Rust by this virtue.

No, semantics and idiomatic code matters but I don't think performance oriented Swift code would be significantly slower than Rust. I might be wrong though - feel free to share relevant benchmarks.

There are some benchmarks that I think you should give them a look: https://github.com/ixy-languages/ixy-languages https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re: Apple is looking for engineers to convert its code from C to Rust

#238
post #189

Earlier quoted context omitted.

No, semantics and idiomatic code matters but I don't think performance oriented Swift code would be significantly slower than Rust. I might be wrong though - feel free to share relevant benchmarks.

There are some benchmarks that I think you should give them a look: https://github.com/ixy-languages/ixy-languages https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Interesting, thanks! Ref counting has an overhead, of course. I wonder about the performance of the "performance oriented Swift code" - i.e. it would be non-idiomatic, but to avoid ref-counting - something you would write in your inner loop or other similar hot points.

Re: Apple is looking for engineers to convert its code from C to Rust

#239
post #238

Earlier quoted context omitted.

There are some benchmarks that I think you should give them a look: https://github.com/ixy-languages/ixy-languages https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Interesting, thanks! Ref counting has an overhead, of course. I wonder about the performance of the "performance oriented Swift code" - i.e. it would be non-idiomatic, but to avoid ref-counting - something you would write in your inner loop or other similar hot points.

Yes, they're programs from the benchmarks game that use a lot of UnsafeMutablePointer, which is: > provides no automated memory management or alignment guarantees. You are responsible for handling the life cycle of any memory you work with through unsafe pointers to avoid leaks or undefined behavior. [1]

So I think they're "performance oriented Swift code". I'm not familiar with Swift, so sorry if I'm wrong. [1]: https://developer.apple.com/documentation/swift/unsafemutabl...

Re: Apple is looking for engineers to convert its code from C to Rust

#240
post #179

Earlier quoted context omitted.

Why is this downvoted? It's a valid question. Chris Lattner, the creator of Swift, has stated many times his goal of Swift being the best language for all uses.

Either you misquote him or he has no idea what he is talking about. Maybe in a walled garden as Apple's it could come pretty close in many instances but One Language To Rule Them All is naive at best.

>Either you misquote him......

Not parent but no, I wish that was the case, he stated it numerous times and he compare it to scaling from Low Level C to Javascript. That was 3 - 4 years ago.

I was extremely sceptical of it because it was unrealistic, that is of course very much against the silicon valley optimistic view so it wasn't a popular opinion. But in a recent interview he has definitely rephrase and said it doesn't need to be the best in everything.

Now I have another problem, It is not the best at anything, what is it actually good at?

That is why I still think Objective-c is going stay for at least a few more years.

Post reply on HN