Earlier quoted context omitted.
I think it's just a shameless plug from the creator of D :)
Rust has shown that an O/B system is viable, and now D shows that an O/B system can work with C-like syntax.
What's your opinion on it? Good idea? Bad idea?
Apple is looking for engineers to convert its code from C to Rust
91–100 of 240 posts
Re: Apple is looking for engineers to convert its code from C to Rust
#92Earlier quoted context omitted.
You reduce it by using custom routing ASICs that can handle orders of magnitude more traffic than a CPU with equal or lower power consumption. To put things into perspective: Cisco’s latest routing ASIC — the Cisco Silicon One — can handle 10.8 Tbps (in fixed mode). I’m sure Google and others have evaluated this, but it’s just kind of surprising that they opt to do per-packet processing in software. Disclaimer: I wri…
10tb sounds like a big scary number but when you think about it that's only 100 100gb ports. It should be no surprise to you that a company making their own switches and NICs, where every RPC is individually authenticated and possibly also encrypted with session keys specific to the peer has no need of vendor "acceleration". https://cloud.google.com/blog/products/networking/google-clo... https://cloud.google.com/secu…
10 Tbps is not a scary number? I am honestly still in awe of how such a small box can route an entire city’s worth of traffic. Different perspectives I suppose.
Regarding your points: I am not sure I completely follow.
Firstly, as far as I know, Google does not make its own switching or routing ASICs.
Secondly, virtually all switching and routing ASICs are highly programmable. So if you need a custom protocol, you can implement it using the vendor’s microcode (e.g., P4). In other words, you are not limited to the protocols that the vendor has implemented.
Given the above, I don’t see what kind of technical requirements Google has that would disqualify the use of routing ASICs.
Re: Apple is looking for engineers to convert its code from C to Rust
#93D 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.
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.
Re: Apple is looking for engineers to convert its code from C to Rust
#94As 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?
Re: Apple is looking for engineers to convert its code from C to Rust
#95Re: Apple is looking for engineers to convert its code from C to Rust
#96Earlier quoted context omitted.
You reduce it by using custom routing ASICs that can handle orders of magnitude more traffic than a CPU with equal or lower power consumption. To put things into perspective: Cisco’s latest routing ASIC — the Cisco Silicon One — can handle 10.8 Tbps (in fixed mode). I’m sure Google and others have evaluated this, but it’s just kind of surprising that they opt to do per-packet processing in software. Disclaimer: I wri…
Does that actually accomplish the desired goal? Encrypting across data centers is one thing, but encrypting within a data center only makes sense if the threat model includes the datacenter's internal network being compromised – I suppose either physically or by hacking a router or something. I can't judge how much that threat model makes sense. But to the extent it does, a centralized router doesn't protect against…
If you split secrets across NICs such that compromise of one NIC would only compromise a portion of internal datacenter traffic, then that would make sense. Again, as you noted, it depends on the threat model.
But from just the bandwidth and latency perspective, a custom ASIC makes more sense to me.
Re: Apple is looking for engineers to convert its code from C to Rust
#97Earlier quoted context omitted.
Because C programmers are 1000x more common than Rust programmers. Edit: "only" 50x according to TIOBE.
It said Rust and/or C though, and I imagine learning Rust is pretty easy compared to C from what I've seen.
Arguably not. Rust has a lot of things that C doesn't, like classes, lifetimes, and the borrow checker, which can be jarring to deal with for programmers used to other languages.
And, unlike most other languages I've seen, you can't just sit down and write a "bad" Rust program and then refine your abilities; the compiler won't let you do the "bad" things, so you have to get everything write from the word go.
Re: Apple is looking for engineers to convert its code from C to Rust
#98Earlier quoted context omitted.
It said Rust and/or C though, and I imagine learning Rust is pretty easy compared to C from what I've seen.
people who are very good at C or C++ will be able to learn Rust pretty quickly yes. People who LIKE C probably won't like Rust though. Its more like C++.
For what it's worth, I used to be big on C, and grew to very dislike C++ (because it's simple insane). Rust is my language of choice for years now.
IMO, Rust shares the same inner-simplicity that C has, but combined with ability to build and use bulletproof higher-level abstractions. The same way I roughly knew what machine instructions (roughly) my C code produces, I know what machine instructions my Rust code produces.
Re: Apple is looking for engineers to convert its code from C to Rust
#99Earlier quoted context omitted.
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.
D missed the train because the creator(s) didn't open source it, instead they wanted to monetize it right away
D has never had a price tag on it.