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.
Apple is looking for engineers to convert its code from C to Rust
231–240 of 240 posts
Re: Apple is looking for engineers to convert its code from C to Rust
#232doesn'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,…
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
#233Earlier 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.
Re: Apple is looking for engineers to convert its code from C to Rust
#234As 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
#235Earlier 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.
Re: Apple is looking for engineers to convert its code from C to Rust
#236Earlier 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.
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
#237Earlier 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.
Re: Apple is looking for engineers to convert its code from C to Rust
#238Earlier 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/...
Re: Apple is looking for engineers to convert its code from C to Rust
#239Earlier 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.
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
#240Earlier 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.
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.