[flagged]
Given it's Microsoft, they are probably thinking about .net.
... you know that this about what 9/10th's of an operating systems device driver code look like, right?
Are you suggesting the post I linked above from someone claiming to be an engineer on Office is inaccurate? It may be well be, but it sounds more plausible and supportable than whatever question it is you seem to be posing.
If you have evidence to suggest that Office365 is written in C# these days I'd like to see it please, because I have read on more than one occasion over the last 10 years that MS had attempted this and given up.
Quoting your favourite engineer "The desktop app’s are fully native".
There is also "Office 365 Desktop" which is what I think you'll find most large corporations that have migrated from Office 2016 Desktop apps are using.
https://www.howtogeek.com/334597/whats-the-difference-betwee...
Office 365 Mobile/Online are much cut down, more comparable from Google Docs from the sounds of it, and hardly a 1:1 replacement for the Desktop apps. Which are still C/C++.
In addition, if you have any hard evidence that the majority of the Office Mobile/Online web apps are written in C# I would like to see that, because I can't seem to find any.
Thankyou.
Thankyou.
You still have an explicit outstanding assertion that they are written in C# though, once we figured out which of the three versions you were actually talking about (ie: it's the versions that almost nobody uses) so let's see it.
> How do you think Office 365 works?
Second message:
> I was referrring to Office 365 on Azure
Everyone can see it, its there and black and white. Having received your clarification that you meant "mobile or online" edition, I asked you to provide evidence it's written in C# which is apparently your claim, which you still haven't done. I haven't asserted that it's still written in C or C++, it could be assembled with spit and paper clips for all I know.
So enlighten us, as per your claim, if you can. I'm genuinely interested.
When your worst case latency/perf requirements don't allow you to have a GC, Rust is another great choice.
Async/await are still far away from being anywhere near figured out nor implemented, CSP primitives in the std. lib like std::mpsc are basically DOA/obsolete/half-functioning and tokio/futures are still early alpha.
There's a lot more to concurrency than just compile-time verification of safe usage of a mutex or moving data in/out of a thread. A lot more.
Async/await (and production quality gRPC) is currently what's keeping us from using Rust at dayjob.
> There's a lot more to concurrency than just compile-time verification of safe usage of a mutex or moving data in/out of a thread. A lot more.
Sure, but it's better to have at least that.
I would also emphasis the need for type safety and contracts.
So it's code written in C# or VB or another supported language, compiled by JIT to a common bytecode running on a virtual machine and probably a whole slew of libraries that target that VM too.
Okay. I have no idea why I'm struggling so much with that.
Thanks.
Two years ago, .NET in an everyday connotation would imply C# (VB.NET is mainly only used in legacy corporate environments, although there was nothing stopping people from implementing greenfield VB projects until last year or so) and an installation of the .NET Framework (equivalent to Java runtime environment) on a Windows PC.
Today, it is increasingly referring to .NET Core, which is still likely C# (with a smattering of F# from enthusiasts) but without a runtime necessarily pre-installed on the PC, now available as first-class citizens (and developed in concert with) on Windows 7+, macOS, Linux, and soon FreeBSD. The runtime has been broken down from the monolithic framework to hundreds of individual libraries (all available via a package manager) compiled to platform- and architecture-independent dlls available via the binary nuget package manager.
Back when .NET was first getting started there were a lot more languages (Microsoft paid language developers to port Java (the language) and the community provided ports of Python, Ruby, and others; while new languages specifically designed for .NET also came and went; I have somewhat fond memories of learning Boo, but I don't think it saw any updates this side of .NET Core 1.0), today it's mostly just C# and F#.
More interestingly, there were some serious attempts at introducing native MSIL (Microsoft Intermediate Language) the assembly-level language interpreted by the runtime environment, now known as CIL or Common Instruction Language) in the form of microcontrollers that natively executed MSIL instructions, but besides a few extremely niche implementations (and very expensive - I remember being disheartened at the time) that ended up going nowhere and I'm not aware of any modern efforts at revisiting that, although I wouldn't be surprised given the resurgence of .NET in recent years.
Today, .NET Core is being pushed for all desktop, mobile, and web development; and is supported on major consumer platforms. The entirety of .NET Core development is out in the open (and there are now official public committees for furthering its development and making decisions affecting its future) and the code is actually available on GitHub.
I jumped on board the .NET train when I found a letter to the only tech-literate teacher at my high school who had thrown it away; it offered to send a free sample pack of CDs and basic literature in advance of the release to interested schools back in 2001 or so (when J# was still a thing, C# had just been introduced, .NET was still at the "we don't speak of it" 1.0 mile marker before the hard fork to redo the CLR with support for generics and revisit some poor decisions in the initial release, and the "new" ASP.NET offering still used WYSIWYG to design the layout!) and managed to get them to send me a copy. It feels like forever ago! C# stagnated for some years, but then Microsoft became serious about it once again after the Windows Vista release (and after they failed to port the Windows userland to .NET due to serious performance constraints in particular pertaining to GC with the Longhorn project), but then saw some great updates that made it an incredibly well-designed and efficient language (without even taking the standard library into account).
I swear, they would've named Bill Gates' grand kids .Net Gates if they could have gotten away with it.