[HN Gopher] Microsoft seeks Rust developers to rewrite core C# code
___________________________________________________________________
Microsoft seeks Rust developers to rewrite core C# code
Author : yau8edq12i
Score : 168 points
Date : 2024-02-03 13:36 UTC (9 hours ago)
(HTM) web link (www.theregister.com)
(TXT) w3m dump (www.theregister.com)
| timeon wrote:
| I 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#.
| fortran77 wrote:
| 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.
| xedrac wrote:
| Given your username I suspect you're quite a bit older. I've
| mentored several grey beards on Rust and they weren't at all
| happy about it, at first. After a few months though, they
| were some of its strongest advocates. It's hard to not love
| Rust when you realize just how much pain it saves you from.
| candiddevmike wrote:
| What pain does it save most folks from that are using GC
| languages (as GP alluded to)? Genuinely curious.
| williamdclt wrote:
| 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.
| nycdotnet wrote:
| "The garbage comes from somewhere" -David Fowler
| yazaddaruvala wrote:
| Oh man, GC is amazingly nice but when it fails sure does
| it fail. It also typically fails when your biggest task
| is reducing overall resource spend, or getting that extra
| 9 after 3+ 9s of latency reduced.
|
| On multiple teams of FAANG engineers, Ive seen the GC be
| a big part of some meltdown and none of us knew a good
| way around it. Tuning only goes so far. Otherwise, you
| just have to give it more memory and CPUs (horizontally
| or vertically).
|
| Almost always the answer was, this might need to be
| reworked in C++ entirely or JNI. In same cases it even
| got funded and was a tremendous success (like 10x fewer
| resources). However, then you're dealing with C++ and all
| of its issues.
|
| I'm looking forward to more value types in Java but
| managing the heap will always be a bottleneck eventually.
| josephg wrote:
| Weirdly enough, some of the worst memory leaks I've
| debugged in my career were in GCed languages. Because any
| object can reference anything, retaining references can
| hide anywhere in the code. (Including via closures and
| other exotic things you forget about). And because in GC
| languages we don't often have a destructor (or anything
| like it), it's very common for people to forget to clean
| up resources. (Eg filesystem handles, sockets, wasm
| object references, and so on).
|
| One weird thing about rust is that network sockets and
| file handles are automatically closed when the handle
| drops out of scope. The borrow checker takes care of
| that. If you do the same thing in JavaScript (open a
| socket then do nothing), the program won't even quit on
| its own and you'll have no idea why.
| xigoi wrote:
| > And because in GC languages we don't often have a
| destructor (or anything like it), it's very common for
| people to forget to clean up resources. (Eg filesystem
| handles, sockets, wasm object references, and so on).
|
| > One weird thing about rust is that network sockets and
| file handles are automatically closed when the handle
| drops out of scope. The borrow checker takes care of
| that. If you do the same thing in JavaScript (open a
| socket then do nothing), the program won't even quit on
| its own and you'll have no idea why.
|
| That's not an inherent problem of GC. You can have linear
| types or destructors in a GC language.
| thfuran wrote:
| The first sentence you quoted acknowledged that it's a
| tendency rather than a fact of GC.
| secondcoming wrote:
| Just like Jesus!
| zahllos wrote:
| I'm a Rust convert, but that needs to be put into context: I
| do stuff in in cryptography, often on embedded. Prior to Rust
| I did C and C++ for most of my work. There's also Ada... and
| it has SPARK, but Ada has never had the level of exposure
| that Rust has achieved.
|
| But there's all manner of "business systems", e.g. Java/RHEL
| shops, ".net shops", where GC pauses don't matter, the code
| is something other than CPU/memory bound anyway,the GC/JIT
| are mature, and a human writing C++ likely can't do better
| and will probably do worse. I've seen this with a write-heavy
| log-ingesting system where the developers used smart pointers
| everywhere - which internally use atomic reference counting,
| which implies sync barriers for otherwise entirely unrelated
| data. I agree, these kinds of places are unlikely to move to
| Rust - the code writes faster in anything else and runs well.
| There's also Go, which has a GC but compiles natively,
| GraalVM, which is AOT compiled Java etc. I definitely agree
| GC'd languages are not going anywhere.
|
| I'm not sure I agree with C# becoming more important because
| of ARM, though. I don't think it'll change much - I think
| shops already invested in certain stacks will mostly stick to
| them and for all Rust's popularity, it doesn't make sense to
| implement your CRM in it really. It does, however, make sense
| to reimplement the C++ parts of the .net runtime and
| miscellaneous other C and C++ parts of Windows that can
| benefit from the borrow checker, because it vastly reduces
| spatial memory safety bugs. There's a massive cost to this,
| but it's no longer just about about on-prem patching but
| Azure.
| josephg wrote:
| > C# -- and garbage collected languages in general -- aren't
| going anywhere.
|
| So what? What does that have to do with rust? There's no
| fight between C# and rust where only one language will
| survive. Both languages are great, and both languages
| probably have a bright future. C# depends on a lot of low
| level C/C++ code to function and run fast. I can imagine a
| future where rust enables c# to get better.
|
| I love rust, but there's also lots of programs and teams for
| which c# is a better language choice. So your comment is
| really weird to me - there's no reason loving c# should
| impact your relationship with rust at all.
| 01HNNWZ0MV43FF wrote:
| Interpreters such as wasm :P
| fl0ki wrote:
| > 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?
| oaiey wrote:
| Totally agree. The .NET team itself is probably costing above
| 100 million every year, probably more. Microsoft is not
| ditching .NET, they are heavily investing it.
|
| The office division is implementing some code in Rust while the
| same division just posted a success story of their usage of
| migrating some low latency server code to .NET Core.
|
| Microsoft is a big company and like any other they use JS, TS,
| Rust, C++, Python, Go and so on. The only thing they do not use
| is Java ... And I am not 100% confident there.
|
| So let us congratulate Rust for entering the office domain and
| stop writing swan songs about .NET.
| rileymichael wrote:
| They use a ton of java, they even have their own distro. In
| fact, they answer this question on its landing page
| (https://www.microsoft.com/openjdk):
|
| > Java at Microsoft spans from Azure to Minecraft, across SQL
| Server to Visual Studio Code, LinkedIn and beyond! We use
| more Java than one can imagine.
| bigtex wrote:
| There is a reddit post where a dotnet developer on the MSFT team
| details why they are moving certain processes to Rust. TLDR, it
| is all about performance that scale.
| rubyfan wrote:
| Can they start by not needing a multiple gigabyte download and
| admin rights to get the rust compiler to work on Windows?
| vijaybritto wrote:
| Is that needed because the compiler accesses some higher
| privileged APIs?
| Measter wrote:
| The MSVC-based compiler doesn't come with a linker, so you
| need the MSVC build tools to get it. One of the ways to get
| the build tools is to install Visual Studio, which is fairly
| large.
| filiphorvat wrote:
| You don't need the whole Visual Studio installation, only
| MSVC build tools and Windows SDK. See here: https://rust-
| lang.github.io/rustup/installation/windows-msvc...
| Thaxll wrote:
| Why would a compiler needs any privileges, it's like a text
| editor
| cerved wrote:
| In widows, you get bonus points if your program needs
| administrative rights
| itishappy wrote:
| Does C# not require a multiple gigabyte download and admin
| rights?
|
| FWIW I've gotten rust working with the GCC build tools on
| windows without admin rights, thought it's admittedly somewhat
| janky.
| thrownaway561 wrote:
| Just hire Yehuda Katz
| rahen wrote:
| What's the point of rewriting from C# to Rust, as C# is
| performant enough and already has memory safety? What will offset
| the huge rewrite cost?
| chiph wrote:
| I suspect this is the .NET runtime + libraries, not
| applications written in C#.
| Merad wrote:
| No, they're looking at migrating some core Office 365
| services to Rust. This is the job posting: https://jobs.caree
| rs.microsoft.com/global/en/job/1633482/Pri...
|
| At the scale of O365 it totally makes sense to look at a high
| performance non-GC language for your core systems that see
| the most traffic (I say this as a .Net dev).
| cebert wrote:
| Too bad you have to be in the office 50% of time for that
| role.
| solarkraft wrote:
| That surprises me since I'd expect that you could get
| really far with hot path optimisation.
| adrr wrote:
| Not sure microsoft's problem is the language. Their
| frontend JavaScript code is bloated and slow. It makes
| office365 feel slow and there are so many bugs in the azure
| management tools. I assume the backend code has the same
| low quality.
| Merad wrote:
| I imagine the goal here is to optimize MS' compute and
| hosting costs. The core pieces of O365 probably handle
| many billions of requests per day. At that scale even
| small optimizations can be worth millions a year in cost
| savings.
| dragonwriter wrote:
| C# doesn't have ownership/lifetimes and the kind of safety that
| comes with them.
|
| Also, at the scale of Microsoft's core global services, when
| you are paying for the processing, fast enough (or "CPU
| efficient enough") isn't the same as with common apps. Even
| small efficiency gains are going to yield sufficient savings to
| be worth a fair amount of developer time.
| hgs3 wrote:
| > C# doesn't have ownership/lifetimes and the kind of safety
| that comes with them.
|
| Could you elaborate? C# has a garbage collector for tracking
| resources.
| lucasyvas wrote:
| I think the parent post is wrong. This rewrite probably has
| more to do with performance, "fearless concurrency", and/or
| developer happiness. C# is safe.
| whimsicalism wrote:
| thread safe?
| jmull wrote:
| It isn't, but neither is rust.
|
| Safe rust is safe from data races, but that's just one
| kind of potential thread safety issue -- one of the
| simpler kinds. It's not nothing, but not anywhere close
| to thread-safe.
| Kinrany wrote:
| I think GP is talking about concurrency issues that arise
| even in single-threaded code when simultaneous mutation
| from multiple sources is permitted.
| CHY872 wrote:
| C# has a garbage collector for specifically tracking
| memory, but lifetimes are more broadly useful.
|
| For example, Rust lifetimes (this is also the case in C++
| afaik) can be used to suitably scope the lifetimes of
| mutexes, to have temporary folders which are deleted when
| they go out of scope, to require that a connection pool is
| destroyed _after_ the last connection inside it is
| returned, etc, etc.
|
| Mostly, garbage collected language do a bad job of cleaning
| up objects which refer to resources held elsewhere. Java
| had persistent issues with direct ByteBuffers (which were
| wrappers around malloc (but not free!)). Locks are easily
| held too long. File handles are easily left open. And
| depending on your GC settings, that file descriptor that's
| holding a 10GB file around may not get cleaned up for
| hours.
|
| Refcounted languages can be somewhat better, but they don't
| avoid the bug, they just mitigate the effects.
| jmull wrote:
| > C# doesn't have ownership/lifetimes and the kind of safety
| that comes with them.
|
| That's not really true.
|
| Like rust, C# is memory safe, although it comes at it in a
| very different way.
|
| "safe" rust does inherently prevent a certain kind of race
| condition in multi-threaded code that C# does not, thought
| that's more of a nice incremental improvement, not a
| fundamental one -- i.e. it doesn't make your multi-threaded
| code thread-safe, but it does prevent a one type of thread
| safety violation.
| k_bx wrote:
| Rust gives you clear semantics on when it drops a variable,
| so it's being used not only for memory safety but to close
| files, kill threads, synchronization primitives, and
| whatever else you want (can be implemented via Trait).
|
| Does C# have any kind of GC behaviour guarantees that are
| similar?
| magicalhippo wrote:
| Not really. There's the IDisposable interface you can
| implement, and some language features around making it
| easy to use[2], however there's nothing _preventing_ you
| from not using those language features and forgetting to
| call Dispose.
|
| In case you forget the GC _will_ call Dispose but it 's
| entirely up to the GC _when_ that happens, so personally
| I wouldn 't say it's similar.
|
| [1]: https://learn.microsoft.com/en-
| us/dotnet/fundamentals/runtim...
|
| [2]: https://learn.microsoft.com/en-
| us/dotnet/csharp/language-ref...
| SigmundA wrote:
| >In case you forget the GC will call Dispose but it's
| entirely up to the GC when that happens, so personally I
| wouldn't say it's similar.
|
| This actually has to be implement in the classes
| finalizer its not done automatically. The finalizer is
| called by the GC which if the designer chooses can call
| Dispose. This is usually done in well designed classes
| that use unmanaged resources.
|
| Dispose and using give you the determinism if you want it
| and the finalizer gives you the backstop to prevent leaks
| if it makes sense.
| magicalhippo wrote:
| Good point, I forgot about that little, but crucial,
| detail.
|
| So it's flexible, but there are footguns about,
| especially if you're wrapping a handle to something
| external.
| cerved wrote:
| Doesn't the compiler complain if you don't use using or
| try? I forget
| helix278 wrote:
| There are warnings given by analyzers in some cases, but
| it's not exhaustive
| vips7L wrote:
| It does. So does every IDE or linter.
| SigmundA wrote:
| C# is IDisposable [1] for that kind of stuff and has the
| "using" block [2] to make it hard to get wrong.
|
| 1. https://learn.microsoft.com/en-
| us/dotnet/api/system.idisposa...
|
| 2. https://learn.microsoft.com/en-
| us/dotnet/csharp/language-ref...
| jmull wrote:
| That's great, but not relevant to the topic of memory
| safety in C#, which is all I was addressing.
|
| I think you are making a point in the broader discussion
| of C# vs. rust, but that doesn't fit here. (And,
| personally, I don't care about that so have nothing to
| say on the topic.)
| krona wrote:
| > C# doesn't have ownership/lifetimes and the kind of safety
| that comes with them.
|
| I believe .net Core has supported several forms of escape
| analysis for quite a while.
| charles_f wrote:
| Almost all of the services I've seen at Microsoft were built
| in C#
| packetlost wrote:
| > C# is performant enough
|
| until it isn't. At Microsoft's scale, I imagine performance is
| actually a major concern for certain pieces of applications.
| fbdab103 wrote:
| Considering the Microsoft consumer software that burns cycles
| to do trivial things (Teams, OneDrive, pick your favorite
| example). I do not think language performance should be a
| compelling argument.
| LeFantome wrote:
| How have you established that there is a "huge rewrite cost"?
|
| Despite other comments here, I see nothing in the post that
| says "we are moving away from C# and rewriting everything in
| Rust!"
|
| Microsoft is using Rust in Windows as well. They have given
| examples of how. In that case, they are not "rewriting Windows"
| but rather targeting specific components that benefit from the
| characteristics of Rust. Those components are just part of the
| larger application that is still primarily written in C.
|
| C# easily with C and therefore with Rust. They interoperate
| well. So it seems likely that MS is following the same plan and
| rewriting specific components of the larger system that would
| benefit from Rust.
| gigatexal wrote:
| Why is MS so hyped on Rust? It's good but doesn't it have its
| caveats? It seems they've become Rust zealots.
| marcosdumay wrote:
| > It's good but doesn't it have its caveats?
|
| Compared to C#, it's a low level language, where you have to be
| concerned with a lot of details.
|
| But then, I'd bet this is for replacing bad C# that does low
| level tasks, that nobody sane would write but MS pushed for
| anyway because they were hyping C#.
| tialaramex wrote:
| Office 365 is was introduced in 2010. So when it was created
| Microsoft had two reasonable options:
|
| 1. Accept the performance penalty from using a safe garbage
| collected language (such as their own C#) which is slower
| which may make the service less attractive and more resource
| hungry which means more expensive to run at scale.
|
| 2. Accept the correctness penalty from C++ which delivers
| good performance but will cause an endless stream of bugs,
| some very hard to diagnose.
|
| Rust makes this much easier, because you aren't paying the
| correctness penalty, your Rust will probably have the same or
| fewer correctness bugs as your C#, and yet you get the good
| performance you'd have wanted from C++.
|
| For a 2010 product Rust was not an option, but presumably at
| some point in the last say five years, Microsoft did the
| maths and worked out that unless they're killing Office 365
| soon or somehow C++ magically becomes safe with no work, a
| transition to Rust is cost effective.
| jimberlage wrote:
| MS has lots of battle scars from the security headaches they
| went through in the 2000s/2010s.
| 01HNNWZ0MV43FF wrote:
| In 2007 they were .NET zealots and now .NET is old guard
| lucasRW wrote:
| I can understand the move from unmanaged C to Rust for security
| reasons, but C Sharp to Rust ? Am I missing something here ?
| jonhohle wrote:
| Performance reasons.
| mmastrac wrote:
| I 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 has been.
| rockwotj wrote:
| On the reverse side of things, trying to find a C++ dev is
| usually harder than finding people who want to write Rust.
| mmastrac wrote:
| I suppose C++ devs are on the correct side of the demand
| curve, unlike myself. :D
|
| I was _really_ tempted to take a C++ job at some point but I
| held out.
| secondcoming wrote:
| 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.
| jimbob45 wrote:
| 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.
| risyachka wrote:
| It only works one way though (at least in this case). If
| you know C++ you can quickly become proficient in Rust.
|
| But not the other way around.
| timeon wrote:
| Yeah C++ have steep learning curve compared to Rust.
| secondcoming wrote:
| It's not about proficiency, it's about not getting bogged
| down in programming language bikeshedding.
| fl0ki wrote:
| Sigh. People don't even know what bikeshed means any
| more.
|
| 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...
| StewardMcOy wrote:
| 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
| overlap in the domains that C++ and Rust serve. Isn't it a
| good thing for job candidates to have an interest in
| learning about other approaches to their work? To
| understand what makes C++ better or worse than Rust in
| difference circumstances?
|
| Why would a mere mention of Rust be a red flag?
| wredue wrote:
| 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.
| namaria wrote:
| 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.
| 01HNNWZ0MV43FF wrote:
| n=1 but I did bring Rust to my C++ job. I needed a web
| server, and I didn't want to put in an order with the web
| server team, and writing a web server in C++ looked like
| a recipe for pain.
| zaphirplane wrote:
| Really people write a web server from scratch? What
| industry? Don't tell me it's some CRUD
| EVa5I7bHFq9mnYK wrote:
| What pain? Just include mongoose.h and .c in your
| project. It's in C, but C is C++.
| wredue wrote:
| I feel like you're giving rust a pass here.
|
| 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.
| namaria wrote:
| I'm sorry but I'm having a hard time understanding why a
| person bringing up a tool in conversation during an
| interview is seen as such a clear and strong signal
| containing so much information about their professional
| performance.
|
| But nowadays it seems like one has to 'turn on' an
| interviewer and avoid a minefield of forbidden words to
| get a job. If a workplace is to become a toxic cult-like
| environment being policed against such thoughtcrimes as
| being curious and interested in technology for its own
| sake I think one would be fortunate to be passed on after
| an interview to enter such a place.
| fl0ki wrote:
| > 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
| 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.
| wredue wrote:
| They're not "your engineers". This is an interview for a
| position listing the job requirements.
|
| 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.
| diego_moita wrote:
| Agree, I am still looking for a Rust position, although I have
| more than 3 years of experience with it.
|
| And yes, it is very hard.
|
| It seems Rust is in a chicken/egg position: employers avoid it
| because "there are few developers", developers avoid it because
| "there are few jobs".
|
| Until recently the majority of Rust jobs were blockchain stuff.
| Now I see a rise in network infrastructure and security.
| godzillabrennus wrote:
| 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.
| wredue wrote:
| Honestly. Rust is not all that "difficult". There's just SO
| MUCH that you MUST know to be effective.
|
| You need to know all of the rustisms. Plus you need to have
| a general knowledge of memory. You need to understand how
| memory is being abstracted and how to work within those
| constraints so as not to be slow. You need to know all of
| the monads, what they mean, why each exists, what the
| nuance is, and why you might use one over another in a
| specific situation.
|
| It's not difficult so much as it just takes so much time
| and challenging-yourself practice to try to memorize
| everything.
|
| A "being effective at rust" book would probably dwarf a
| "being effective at C++" book in pages assuming similar
| prose. And we all know how much of a beast C++ is.
| spoiler wrote:
| > A "being effective at rust" book would probably dwarf a
| "being effective at C++" book in pages assuming similar
| prose. And we all know how much of a beast C++ is.
|
| I've written C++ for close to a decade before switching
| to Rust, and this is categorically untrue.
|
| > Plus you need to have a general knowledge of memory.
| You need to understand how memory is being abstracted and
| how to work within those constraints so as not to be
| slow.
|
| If anything, this is more true so of C++.
|
| > You need to know all of the monads, what they mean, why
| each exists, what the nuance is, and why you might use
| one over another in a specific situation
|
| You can use a lot of stuff before needing to know their
| full history. You don't need to know the history behind
| 0, null, pointer, numbers and addresses before, how
| hardware works, etc to use Option, for example. You also
| don't need to know the (inconsistent and arcane) history
| of errno and magic numbers to use Result. Etc, etc.
|
| This vastly over-exaggerates Rust's complexity.
|
| Yes, it borrows concepts from functional programming, but
| a lot of these concepts are simpler than stuff you deal
| with in imperative programming.
|
| I think the issues here is that people don't tend to like
| to change their way of thinking, even if it's for the
| better. Also, Rust has ample in common with
| imperative/traditional language, so it's not a huge leap
| into some alien mental model, as you make it sound.
|
| Further, C++ makes you think way more than Rust; in Rust
| the compiler does a lot of the thinking for you. Not to
| mention, the type system is easiest to reason about than
| C++'s old (and mentally inefficient) template system.
| withoutboats3 wrote:
| "Dwarf"? "Dwarf"?! I may be biased (because I am very
| effective at Rust and terrible at C++) but I can't
| believe this seems probable. std::optional, move
| semantics, boost, template templates, SFINAE(!!) C++ has
| all the expressivity of Rust and more, with far less
| regulation to assist the programmer in using it
| effectively.
| PH95VuimJjqBqy wrote:
| you don't have to know _any_ of what you just listed in
| order to be effective with C++.
|
| the closest thing to required would be move semantics.
| thfuran wrote:
| >It's not difficult so much as it just takes so much time
| and challenging-yourself
|
| What's the difference?
| adamnemecek wrote:
| Learning Rust to the point of being productive is 100x
| easier than C or C++. It's not even funny.
| josephg wrote:
| That hasn't been my experience with it. I found rust
| significantly harder to learn than C; and this is after I
| already knew C. (At least - learn rust to the point of
| feeling productive, and like I wasn't fighting the borrow
| checker constantly).
|
| Arguably becoming an expert in C means you need to
| understand all the nuances of undefined behaviour. And
| that's a much harder process. But it can happen slowly.
| Rust preloads all the pain. You essentially can't write
| rust at all until you understand rust references,
| lifetimes (implicit and explicit) and the borrowchecker.
| The payoff is huge, but I found climbing that mountain to
| be no joke.
| adrianN wrote:
| Given the number of CVEs that can be directly attributed
| to C and C++ you only need to be half-joking to argue
| that approximately nobody has managed to learn the
| languages sufficiently to write production code in them.
| josephg wrote:
| As uncomfortable as this is to say, the existence of
| latent security vulnerabilities doesn't seem to stop
| people from shipping a lot of apparently working code in
| C and C++.
|
| And I don't think a lot of those CVEs come from people
| misunderstanding the languages. As I understand it they
| mostly come from honest software bugs. C++ makes it easy
| for honest mistakes by experts to become security
| nightmares. This is a controversial opinion - but I think
| the fault is in C and C++ themselves. Not the programmers
| who need to work even harder such that they stop ever
| making mistakes.
| vacuity wrote:
| Which is why some people push for no longer using C and
| C++ as much as possible. It's just not feasible to expect
| the average programmer to avoid all the security
| pitfalls. Of course, whether Rust is the best option
| isn't a given.
| LtWorf wrote:
| So you're saying there is no CVE in php, java, go, js,
| and python?
| zozbot234 wrote:
| > You essentially can't write rust at all until you
| understand rust references, lifetimes (implicit and
| explicit) and the borrowchecker.
|
| You can if you're willing to use stuff like .clone() and
| the interior mutability types. In Rust, you can tell when
| code has been written to be a bit sloppy because it has
| that kind of boilerplate. And the compiler checks are a
| huge help when it comes to refactoring the code and
| making it cleaner and better-performing.
| josephg wrote:
| Eh. If you don't know how references work in rust, you'll
| struggle to use most of the standard library or any 3rd
| party crates. And if you can't pass mutable references to
| functions or iterators there's a lot of programs that
| will be hard to write at all. Performance will be pretty
| rubbish too.
|
| You might be able to write some simple programs, but I
| wouldn't say you know rust yet, or could really be
| productive with the language.
| riku_iki wrote:
| > 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 that? You can write rust the same way you write C
| but with nicer syntax, standard lib and build system and
| more potential to future expansion.
| josephg wrote:
| > 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 most of it decades ago, while the pain
| of learning rust is still fresh.
|
| > why is that? You can write rust the same way you write
| C
|
| Because I use pointers everywhere in my C code. Rust's
| borrow checker simply won't compile my code if I
| transliterate it directly from C. There are software
| patterns which work well in rust with the borrow checker
| in mind - but they take time to learn and get used to.
| Until you do, you simply aren't productive.
| riku_iki wrote:
| > Because I use pointers everywhere in my C code. Rust's
| borrow checker simply won't compile my code if I
| transliterate it directly from C.
|
| borrow checker is more relevant to C references I think.
|
| For pointers you can use Arc or Rc and don't worry about
| borrow checker.
|
| Disclaimer, I am not a rust or c coder, so my opinion has
| a high chance to be wrong..
| adamnemecek wrote:
| Yeah, that's what I meant by productive. Not like learn
| the language but like build stuff.
| edgyquant wrote:
| Objectively false
| unclad5968 wrote:
| I don't care that it's hard to learn. What turns me off
| rust is that if I ever make a change that requires a
| lifetime annotation, I now have to go back through all my
| code potentially adding lifetime annotations to everything
| it touches.
|
| I was making a little toy compiler in rust and basically
| gave up when I wanted to make a change that would have
| amount to string -> string_view in c++ because in rust I
| now need to tell the compiler that the String to my &String
| is going to outlive the struct. Now I understand why it's
| good but Id rather just let c++ blow my feet off. Maybe
| once I nail down all the data structures I'll rewrite it in
| rust.
| zozbot234 wrote:
| Isn't that why Rc<> and Arc<> exist in Rust? So that you
| can deal with situations where you don't know the object
| lifecycle at compile time?
| miniupuchaty wrote:
| If you're fine with dropping safety you can just make a
| wrapper around a raw pointer. I wouldn't do it in public
| library but if it's fine for your cpp code then it's fine
| for your rust code. You can always drop to the "blow my
| feet off" level.
| merb wrote:
| The last few versions made a lot of the lifetimes elided
| so you can drop them.
| pornel wrote:
| This effect of <'a> spreading everywhere is very
| frequently a novice mistake of putting temporary scope-
| bound loans (AKA references) in structs that aren't
| temporary views themselves.
|
| People used to C or C++ perspective tend to reflexively
| (over)use references to avoid copying, but references in
| Rust are to avoid _owning_ , and not-copying is handled
| in different ways.
|
| BTW, apart from edgiest of edge cases, &String is a
| useless type in Rust, because String already stores data
| "by reference" and is never implicitly copied. For loans
| it's generally better to deref to &str.
| FlyingSnake wrote:
| I know some teams that are hiring Rust devs. Please feel free
| to ping me if you would like to know more.
| xedrac wrote:
| The trick is to introduce Rust wherever you're at, assuming
| it's a good fit for the task. This may be harder to do if you
| don't have enough influence.
| tayo42 wrote:
| Quick way to be annoying and unlikeable at work.
|
| The times I've seen rust introduced, and tried it my self, it
| introduces a whole bunch of related tech debt. Like hacks to
| make builds work
| beeboobaa wrote:
| If it's a good fit then it's a good fit. Of course you'll
| need to ensure the CI is set up properly, just like
| everything else.
|
| If it's not a good fit, then you're just forcing it, and
| yeah...
| jonnytran wrote:
| Yes, I did this at my startup. Fast forward a few years, and
| now the company has more Rust code than Python, and the
| majority of the company's IP is in Rust.
|
| I suggest beginning with small, one-off things that don't
| have much impact. People, even developers, tend to shy away
| from things that aren't familiar. By introducing Rust in a
| small, low-risk way, it helps people get familiar with it.
| They get to build familiarity with building Rust projects,
| navigating the project structure, and reading docs. I submit
| pull requests that get people to read Rust code, even if it's
| just to say "looks good". Their familiarity builds slowly
| over time, meaning they'll be less triggered by seeing Rust
| in a larger, more impactful project down the road.
|
| How do you boil a software developer? Slowly.
|
| If they give Rust a chance and your team has a champion to
| guide them, they'll see its merits. I think a lot of people
| come to Rust for the performance, but that's not why they
| stay.
| TrackerFF wrote:
| We acquired a product last year, where the entire back-end was
| written in Rust.
|
| Unfortunately, Rust developers were hard to get by, and we
| didn't have any internally that could maintain the Rust code at
| such scale.
|
| The entire back-end ended up being re-written.
| codetrotter wrote:
| Nooo :'(
| beeboobaa wrote:
| What happened to the developers who wrote the back-end in the
| first place?
| cerved wrote:
| maybe the borrow checker determined their lifetime was up
| ducktective wrote:
| >The entire back-end ended up being re-written.
|
| In Go, I presume?
| rowanG077 wrote:
| Why not just learn rust? It really is not that exotic to
| learn. I doubt it is faster to rewrite it.
| jonnytran wrote:
| Yeah, this is just baffling. A team can be so averse to
| learning new tools, good ones too, that they would rather
| dump their time into rewriting. Instead of getting paid to
| level up their skills, they'd rather block forward movement
| of the company's goals to maintain the status quo.
| kasajian wrote:
| I'm a bit surprised at this, too.
| davidmurdoch wrote:
| There are tons of Rust jobs in blockchain.
| surajrmal wrote:
| It's equally difficult to try and hire a team of folks who know
| rust. There is also a lot of legacy code which doesn't cleanly
| interop with rust (cxx and the like are not sufficiently easy
| to bridge the gap). It would be much easier to convince your
| existing team to start using rust where it makes sense than it
| would be to switch jobs in search of one which primarily uses
| that. Over time both of these problems will diminish, but
| that'll likely take another decade.
| bobajeff wrote:
| I'm not totally sold on rust as a language but I have to admit
| the tooling and ecosystem is really nice. I'm noticing that I'm
| increasingly using more stuff built with it.
|
| I'm also not sold on zig either for many of the same reasons. I
| prefer my low level languages to be smaller like c. I think that
| might be true for languages higher level languages too. I just
| don't like to have to down a lot of documentation on hundreds of
| different features and concepts behind them.
| kiririn wrote:
| The tooling/ecosystem looks probably great for developers
| actively creating with it, but for developers 'consuming' it
| (downloading some foss from github and changing a couple of
| lines) it leaves a lot to be desired. Not being able to 'apt
| install' a working toolchain on Debian for example - it's
| already too outdated after just a year
| wslh wrote:
| Hi @dang, regarding HN karma, what happened to the karma points
| if a user posted the same article just twenty hours earlier?
| (*_*) [1]
|
| [1] https://news.ycombinator.com/item?id=39232275
| Sparkyte wrote:
| I imagine it comes down to the handling of threads vs anything
| else. Technology is rapidly adopting the more cores strategy of
| technology since we are hitting some IPC limitations and in the
| server space more cores is better.
| TideAd wrote:
| I find this very strange, Microsoft has a lot of big internal
| high-performance services written in C#.
|
| You have to be intentional about some things - largely making
| sure objects are very short-lived or very long-lived, to avoid
| long GX pauses. But .NET performs much better than it did 10-15
| years ago and I can't think of a fundamental reason why you'd
| rewrite in Rust.
| dtx1 wrote:
| Might not be all about performance but about security aswell.
| zozbot234 wrote:
| The Rust folks are working on experimental codegen for the CLR
| https://fractalfir.github.io/generated_html/rustc_codegen_cl...
| leveraging the existing CIL/CLR support for "unsafe" languages.
| Once that work is complete, you should be able to rewrite C#
| code to Rust on a very fine-grained basis (a single function at
| a time or thereabouts), just like you can when porting C to
| Rust. Of course, you'll also be able to remove the CIL/CLR
| dependency altogether if you're left with 100% Rust code, and
| compile to a binary just like in ordinary C/C++.
| jasonjmcghee wrote:
| Are there any rust books that have the focus of "ok you are
| productive in rust, this is what you should know / do to write
| proper rust"?
|
| Edit: ok found https://github.com/sger/RustBooks
|
| Any specific recommendations?
___________________________________________________________________
(page generated 2024-02-03 23:01 UTC)