When it comes to “who hires the best?” it gets a bit fuzzy and anecdotal, but roughly RenTech hires the best. You know, the elite places with boundless budgets and counter-productively high technical hiring bars.
I mention Swiss/glog/gtest/tf because I was always talking about FANG companies, high finance (Renaissance, Jump, etc.) and to a lesser extent some of the unicorns.
#Apple java language code
The reality is that there's good and bad code everywhere, and the larger a company is the more it tends to regress toward the mean. Not without reason in any case, but still incorrectly. Facebook engineers think that Facebook hires the best people in the world, but people at Google think that they do, and people at Apple think that they do, and people at random startups think that they do. There are people all over this industry pushing the state of the art. People who have no experience beyond school see something new, they think it's the bees' knees, surely they think they must be blessed to work at a place where such things are created.
Some of it's so Facebook-specific that it's only useful inside, or it's just plain junk that the rest of the world is spared.Īfter eight years working solely on open source at Red Hat, I've seen nothing particularly exceptional about the quality of Facebook's proprietary code. Yes, there's stuff in folly that's available internally before it's open sourced. You can't be "better than anything" in a category that you're in yourself. The "g" in "gtest" and "glog" doesn't stand for Facebook, so I don't even know why you include those. Rust may have a window of opportunity before C++ finds an answer on that. At some point you just can’t fucking build the thing no matter how many boxes you throw at it. The thing that might get Rust over the threshold isn’t memory safety (modern C++ with hardcore warnings-as-errors static analysis and automated ASAN/TSAN/UBSAN runs is rather solid), it’s build times.īuild times are the thing that will kill C++ unless they can come up with a modules solution that is cheaper to migrate than rewriting everything. When you think about the dizzying array of touch points (logging, metrics/monitoring, service publishing and discovery, and on and on) that even the smallest component needs, the absurd wealth of libraries better than anything in open source, the standards-committee level expertise an email away that you have in one of the mainstream languages it becomes clear that you’d need more than a large incremental improvement in the language itself to break even. I was at FB from 2011-2018, and things may have changed since, but at that time it required serious buy-in to do anything that wasn’t in Hack, C++, Python, Java, or one of the mainstream mobile languages (JS/Swift/etc.) There were pilots of various things that made it into prod (Haskell had a modest niche and I spent a year on that team). This could be a big deal for a networking team. Still no async/await (or any real concurrency model at all) in Swift it’s planned to be available in the next year or two. No stack-allocated arrays in Swift all collections are reference-counted and stored on the heap. Rust/C++ exclusively uses compile-time template instantiation, which is a little less flexible and doesn’t guarantee ABI stability but it always guarantees unimpaired performance. Usually the compiler will inline/specialize generics, but there’s no guarantee, especially when calling generics across module boundaries (due to ABI stability restrictions). Swift’s generics are dynamic by default, which involves wrapping up every object into a possibly-heap-allocated container and using dynamic dispatch for everything. It’s usually convenient and efficient (and lets you do cool things like copy-on-write), but when you know more about your object lifetimes than the compiler, the unnecessary retain/release traffic gets really annoying and is not easy to avoid. Swift’s memory management is based on reference counting. Swift’s philosophy is basically “give everything a Python-like level of dynamism, and then heavily inline/optimize out when statically possible.” For instance: Swift is great for application programming, but for low-level performance-critical systems programming it’s currently a huge pain in the rear. And I was thinking why did they make Swift for low level usage if they were going to use Rust.
0 kommentar(er)
