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

My hometown. From what I heard, an engineer wanted to move home and started a small remote office there. I think the office is moving to Edmonton.

I used to go there as a kid. It was one small town, and I don't suppose it has boomed since.

Why would they use Swift? It doesn't seem like the most fitting replacement for C level infrastructure.

Swift’s performance isn’t really up for high-performance network processing, at least not yet.

Rust has more safety features and better runtime performance. So either or both of those reasons.

Swift is not yet a zero-abstraction-cost language like C or Rust which might be one of their concerns.

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.

Reference counting.

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

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.

>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.

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, the experience at Google and Apple was quite different. At Apple, I waited months, with multiple follow up pings, to get approval from a lawyer for a one line trivial patch for an OSS project. I had to give an argument that my contribution provided a direct business benefit to Apple, and generating goodwill in the community was explicitly listed as a reason that is not valid. I couldn't contribute to any Google run OSS projects either (some issue with the CLA, not sure of the blame, TBH).

In contrast, at Google you are encouraged to contribute, don't need any approval for normal OSS projects, and I have easily gotten approval to release two personal projects.

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 concerned that if an employee casually browses GitHub and is inspired by some GPLv3 code that they could rewrite themselves for use in a proprietary Apple product then the lawyers consider that Apple product now possibly tainted (as rewriting code or being "inspired" by other code still legally counts as a derivative work, even if absolutely nothing was copy and pasted).

Microsoft lost that attitude around the same time Satya became CEO - I was at Microsoft when the transition happened and it was a refreshing change of policy that really came top-down. Of course we still had annual SBC training to remind us to always verify the licenses of any third-party or open-source components we use (and GPL is generally a big no-no, of course, without special dispensation from LCA) but the idea that a product's legal status could be tainted by casual browsing went by the wayside. I think a lot of the change came from a wave of sanity at the C-level when they realised the company was not actually being actively destroyed by meritorious - and meritless - open-source copyright violation lawsuits, and the few incidents that did occur (like the Windows ISO-to-USB tool debacle) were overblown with minimal impact to the company.

But Apple's paranoia isn't just about legal matters, but also out of concern that if Apple-watchers know who works for Apple and monitor their GitHub accounts then they'd be able to see which areas of technology interest those people, which may in-turn drop-hints about what Apple is working on (e.g. if we suddenly see a bunch of Apple folks Starring and forking LiDAR libraries for private use then that hints Apple is working on a LiDAR product... which they announced this week that they are: https://www.theverge.com/2020/3/18/21185959/ipad-pro-lidar-s...

Now, as someone who believes they'd otherwise make a great contribution to Apple as a valuable SE asset (yes, I'm being self-aggrandizing) this policy of theirs is a huge deal-killer for me. Not just because I own some popular GitHub repos with GPL licenses, but because I also have popular (and profitable) side-projects that only use a few hours of my time each month - and Apple is just as paranoid about those things as open-source projects are as vectors for leaking company movements, even unintentionally.

Heh - I remember shortly after I did NEO at MSFT and filled-out the "prior inventions" paperwork for my side-projects, my team lead admonished me for wasting his time looking at my dumb Google AdWords-supported websites - though he did agree the definition of "prior invention" was too vague.

(Footnote: if you're a recruiter or hiring-manager at Apple and you're reading this, and you agree that my side activities won't be a problem, please reply to this comment - I'd love to work on WebKit or Darwin at Apple :D!)

Usually.

Don’t believe everything you read on the internet.

> having related engineering hobbies

Like an engineering blog and open source projects? I would be surprised if a company can restrict employee's hobbies outside of working time.

None of the big clouds use hardware network encryption. All of the resources in your network are at the leaves, so you might as well use their CPUs to do it. I think Google published that crypto and compression in their internal RPC stack cost them less than 1% of their global CPU resources.

> This sounds like it’s doing packet processing in software

From the article:

> Based on a custom implementation of IPsec

Seems pretty clear.

I think big companies see a lot of opportunity in locations outside of Silicon Valley. If you don't care about the weather in the Bay Area, which is quite pleasant, or the other industries around you (be it for business or for pleasure), then you can get an easier commute and a better house for the same salary, which is appealing to some people. (You can also pay people less, which seems to be a strategy used by companies without any Bay Area locations.)

As for how these offices exist; sometimes the team lead is senior enough to move the project there because they want it to be there, and other times a company is acquired that has offices there and there was no reason to move them. (I think Google got their NYC office by buying DoubleClick, for example.)

It all comes down to world-class talent and their willingness to relocate. John Carmack famously joined Oculus without leaving Dallas, TX. I also believe that Chrome's entire V8 team is based out of Aarhus, Denmark due to Lars Bak's desire to move back home.

Apple has a number of small offices around the world in addition to their large presence in the Bay Area and Austin.

Was this a response to something else in this thread that you accidentally top-posted?

It's cool, technically, but maybe a little off-topic.

This is a 'mindshare' game. D had its chance, now Rust has its chance. Would have been cool though if D had caught on more back in the day. Re-invention seems to be impossible to avoid in the software world.

Thank you for responding. There's always a room for an awesome programming language. I've never used D but as a professional c++ programmer, I admire what you set out to do. (Assuming you are the creator....)

Please ignore the naysayers. HN is diverse in degree and area of knowledge and some people even think electron is the only cross platform gui framework.

That's great to know. I'll to check it out. D is a great language and it's good to see it's getting even better.

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.

Search “apple engineer camrose alberta linkedin” on Google [1]

You will find a handful of people who either relocated during the last year or were hired there.

This includes people like Jeff Davey, Steven Bromling, Tony Gong, Derek Hausauer and Lucas Wagner who are brilliant.

[1] https://www.google.com/search?q=apple+engineer+camrose+alber...

Population (2016) 18,742. Wow, Camrose is a really surprising location

If you're writing performance sensitive code and/or correct code, Rust makes more sense. Rust makes more sense for almost any use-case over Swift unless you're building Apple clients.

Swift still hasn't really escaped its niche of being a language for end-users to build clients for the Apple ecosystem with trade-offs in mind for those end-users who are just building clients (rather than, say, implementing a safer openssl).

For example, even Rust's web framework story is more mature and benchmark competitive than Swift's. Go to https://www.techempower.com/benchmarks/ and filter for just Rust and Swift.

I say all this sadly as someone who builds iOS apps. I would find it very weird that someone was using Swift of all language for infrastructure projects.