Earlier quoted context omitted.
Yup, we were hiring C++ devs recently and it was quite common for candidates to mention Rust. Did they not read the job description??? Immediate red flag.
Are you not a developer? Being proficient in one means that it will take very little time to transfer to the other. C++ and Rust have a great deal of overlap in that way.
Microsoft seeks Rust developers to rewrite core C# code
111–120 of 256 posts
Re: Microsoft seeks Rust developers to rewrite core C# code
#112Earlier quoted context omitted.
I've been a C++ dev for most of my career. Not looking to change jobs at the moment, and I like C++ a lot. We still occasionally start new projects in C++ where I work. I've tinkered with rust in my spare time, but never introduced it at work. I think the borrow checker is a fantastic tool, but Rust has just never been the right tool for the domain we're in. But I'm a bit confused by your statement. There's a lot of…
It’s a red flag because you’re going to get people bring in random languages just because, then they fuck off to another job and you’re left supporting code that nobody knows.
Rust is hardly a random choice. You can debate its merits for some domains, but replacing C++ in most of the places that C++ is used is exactly what Rust was built for and is widely recognized as doing well at.
> just because
If your engineers are pitching a technology with no more basis than "just because", I can understand dismissing them out of hand. But ask yourself if that's actually what happened, or if they gave specific reasons justifying their proposal and you dismissed them out of hand anyway.
Even if you disagree with the reasons, or agree with them but conclude they are outweighed by other arguments, either of those is totally fine, but dismissing them as "just because" is not an effective way to make technical decisions as a team.
Re: Microsoft seeks Rust developers to rewrite core C# code
#113Earlier quoted context omitted.
Are you not a developer? Being proficient in one means that it will take very little time to transfer to the other. C++ and Rust have a great deal of overlap in that way.
It's not about proficiency, it's about not getting bogged down in programming language bikeshedding.
https://en.wiktionary.org/wiki/bikeshedding
If you think the differences between C++ and Rust are "unimportant but easy-to-grasp issues" then you may not know enough about either/both to contribute to the discussion.
We're talking about differences so impactful and well-recognized that everyone from Google[1] to the NSA[2] is advocating for using Rust to reduce the unsafety compared to C++. Are you saying all of them are bogged down in bikeshedding?
[1] https://security.googleblog.com/2022/12/memory-safe-language...
[2] https://www.nsa.gov/Press-Room/News-Highlights/Article/Artic...
Re: Microsoft seeks Rust developers to rewrite core C# code
#114Earlier quoted context omitted.
It’s a red flag because you’re going to get people bring in random languages just because, then they fuck off to another job and you’re left supporting code that nobody knows.
People _mentioning_ Rust means they will bring a random language into your stack if they are hired? This red flag cultural trend is blinding people to nuanced thought.
It would be a red flag if you were interviewing for react and decided to bring up vue or svelte or angular or whatever else as well.
It’s not like it’s only this C++/Rust type deal that is being picked on. Although I would suggest that rust fans tend to be particularly ardent and loud at the current moment, so interviewers may be far more turned off of you as a person just for bringing it up. Interviewers probably felt this way about people bringing up Python 20 years ago (Python devs of yore were WAY WAY worse about their “HAVE YOU HEARD THE WORD?!” Than rust devs are today), blockchain 7 years ago, etc.
Anyway. As an interviewee, I’d probably try to avoid being the one to bring up alternative technologies.
Re: Microsoft seeks Rust developers to rewrite core C# code
#115I love writing Rust, but I was really surprised by how difficult it was to find a job _actually_ writing Rust. I'm happy to see the increased activity in the space, but searching for a job in Rust is probably still 10x harder than C or C++. It worked out in the end, and I'm happy to be getting paid to be writing Rust every day, but I hope that the market for Rust jobs continues to grow -- ideally even faster than it…
Re: Microsoft seeks Rust developers to rewrite core C# code
#116Earlier quoted context omitted.
It’s a red flag because you’re going to get people bring in random languages just because, then they fuck off to another job and you’re left supporting code that nobody knows.
> bring in random languages Rust is hardly a random choice. You can debate its merits for some domains, but replacing C++ in most of the places that C++ is used is exactly what Rust was built for and is widely recognized as doing well at. > just because If your engineers are pitching a technology with no more basis than "just because", I can understand dismissing them out of hand. But ask yourself if that's actually…
You go ahead an interview however you like, but generally, giving your interviewer a feeling that you plan to shake up their tech stack because you feel like it isn’t going to go well.
Re: Microsoft seeks Rust developers to rewrite core C# code
#117Earlier quoted context omitted.
> I found rust significantly harder to learn than C language itself maybe, but you also need to learn ecosystem, libs, build systems, testing. Benchmark could be: how fast you can learn and bootstrap some type of app of your choice: high performance DB or torrent server, etc. > You essentially can’t write rust at all until you understand rust references, lifetimes (implicit and explicit) and the borrowchecker why is…
> but you also need to learn ecosystem, libs, build systems, testing. That’s a really good point that I hadn’t thought of. If we include header files, compiling and linking, makefiles and CMake and the mess of dealing with 3rd party libraries in C - well, yeah. All that stuff is probably worse than learning the rust borrow checker. I think I’ve forgotten how horrific that mountain is for beginners because I learned m…
Re: Microsoft seeks Rust developers to rewrite core C# code
#118I upvote almost any post "in Rust" here (yeah that's me) but this story went bit too far. It was just one job posting and so many sites acts like MS is going to ditch C#.
That’s funny because I downvote almost any “in Rust” post here! C# — and garbage collected languages in general — aren’t going anywhere. With the shift to Arm, languages compiled for a runtime interpreter will get even more important for Microsoft.
How's that? Apple and its app ecosystem just ship universal binaries, so native, heavily optimized x86_64 and aarch64 code is always ready to go with no added fuss for the user.
You could certainly argue this makes already-large binaries even larger, but users care much more about CPU & RAM efficiency than on-disk binary size. Especially on ARM machines that many people buy for battery efficiency in the first place.
On Linux you don't even bother with universal binaries because you just ship the entire package repository already built for the target CPU. It's only more fuss for the user if they need to pick specific packages from outside their distro.
Has Microsoft still not managed to make something similar work on Windows?
Re: Microsoft seeks Rust developers to rewrite core C# code
#119Earlier quoted context omitted.
Seems like RUST needs work to become easier to learn. Hard for a business to take a risk on using it (outside of a use case absolutely needing a memory safe language) if the talent pool is shallow.
Learning Rust to the point of being productive is 100x easier than C or C++. It's not even funny.
Re: Microsoft seeks Rust developers to rewrite core C# code
#120Earlier quoted context omitted.
What pain does it save most folks from that are using GC languages (as GP alluded to)? Genuinely curious.
GC _is_ the pain. Lots of use-cases where precise memory management is critical, or real-time guarantees are needed that are difficult with GC.