Microsoft is creating a new Rust-based programming language for secure coding | Hacker News Reader

Microsoft is creating a new Rust-based programming language for secure coding

zdnet.com

274 pointsTanakaTarou194 comments

Video where this was introduced, which has more details: https://vimeo.com/376180843

Slides: https://www.slideshare.net/KTNUK/digital-security-by-design-...

The slides don't really add much detail. They're just a light introduction to the sort of region-based memory management that was already being used by Cyclone, well before the Rust project was even a thing.

The video explains more:

- Need to keep old insecure code around, too much money to rewrite the world from scratch in Rust, C#, or whatever safe language makes your day

- They are just starting the project, so far only interpreter and runtime model

- It is based on CHERI CPU research (https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/), which has memory tagging

- They are planning to open source the existing work in a couple of months

- Looking for collaboration

> Need to keep old insecure code around

That's what process boundaries are for. (As a bonus, you get protection from any Spectre-like issues arising in the old code.)

Not everything can be neatly refactored out of a process.

Process boundaries don't protect against internal exploits, which is what most of the C and C++ exploits are all about.

If you are able to force a process to change its behaviour, the process boundaries become useless.

Process boundaries specifically protect against these exploits.

So how does a process boundary protect against Heartbleed?

Process boundaries help you when you start jumping through a ROP chain that spawns a shell because your process doesn't have access to things that it shouldn't, even when compromised. Calling Heartbleed an example of a process "changing its behavior" doesn't really make sense in the context of exploits that can cause arbitrary code execution.

So each one gives an example that suits their own sales pitch.

You don't have to spawn a shell as a seperate process. Injecting and executing code inside a vulnerable process has been done for a long time.

A shell spawned in an unprivileged process is not very useful.

One doesn't need to spawn a shell.

Injecting and executing code inside an unprivileged process is not very useful.

Some black hats would consider stealing data, data corruption or triggering DOS already very useful for ransonware.

Rewriting can be greatly automated. C2Rust[1] proves that. Just can be improved with new languages and refactoring capabilities.

[1] https://github.com/immunant/c2rust

> already being used by Cyclone, well before the Rust project was even a thing.

Let’s be a little more accurate here. Rust is an actively developed language, Cyclone was a research project that I don’t believe has received an update since 2006.

Rust also is explicit that it borrowed its lifetime concept from Cyclone. Rust is in use and gaining popularity in a way that Cyclone didn’t.

This is a bit like the debate between Apple and Xerox in terms of the beginnings of the desktop/mouse/GUI environment. Apple was the first to make it popular, xerox park invented it. Rust has a similar relationship with Cyclone.

It's clear to most that rust invented few, but that nobody cared because we just wanted these features to reach the mainstream, which rust embodies. Maybe the rust trend train gives people a false impression of innovative messiah... I don't know.

I always knew Rust was picking up from Cyclone, but I was, stupid enough to assume Cyclone was half baked, half finish programming languages with the Ownership idea.

It wasn't until today I did a search on it, and it reached 1.0!

Why wasn't Cyclone being used or continue to be developed?

Sylvan Clebsch and Sophia Drossopoulou (credited on Project Verona in a slide) work on the Pony, which has been described as a cross between Rust and Erlang.

I'm curious to see what Microsoft does.

The big breakthrough with Rust was ownership, and Microsoft seems to agree on that. Rust has a lot of other baggage that could be dispensed with. Of course, Microsoft has their own baggage.

I disagree about ownership being the big break through, I’d argue it’s the concept of multiple aliasing and handling that at the syntactic level through the borrow checker that leads to all the safety guarantees of Rust.

More precisely Cyclone already had borrow checker over a decade ago. Rust derives much of its memory model from that language.

Which is awesome. Standing on the shoulders of giants and all that.

There should be no doubt about the agenda: Embrace, extend and extinguish.

That doesn't apply here, unlike with WSL.

Microsoft has a huge problem: thousands of coders who aren't disciplined enough to write reliable code. They need a language to provide the needed discipline. They tried making their own language, and now understand that they are not good enough at that, either. Rust, or a fork of Rust, might suffice.

They are not interested in displacing Rust from wherever it is being used. They just need something for their things, that their customers can also use. Lock-in is exercised farther up the chain.

This slideshow is pretty interesting (in particular slide 14):

https://www.slideshare.net/KTNUK/digital-security-by-design-...

Talks about sandboxing C/C++ libraries that interact with Rust. Kinda make a safe unsafe sandbox Rust interface ("less unsafe?") if I understand it correctly (I likely don't).

The actual linked article is all over the place, I cannot make heads or tails of it and seems to be conflating multiple security issues/mitigations together into a mish mash.

> The actual linked article is all over the place, I cannot make heads or tails of it and seems to be conflating multiple security issues/mitigations together into a mish mash.

Typical ZDNet.

You really need to watch the video.

Basically a new language for system software and containers that allow to tame existing software, due to the expenses of rewriting everything into safe languages.

It is based on the CHERI tagged architecture.

https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

Just starting now, they have done the ground work, will open source it and are looking for collaborators.

Midori v2?

http://joeduffyblog.com/2015/11/10/objects-as-secure-capabil...

Midori was conceptually closer to what Pony lang offers.

You mean Sing#?

https://en.wikipedia.org/wiki/Sing_sharp

I'm surprised Microsoft didn't "invent" their own version of Go yet. Actually I'd use it in a heartbeat over Google's if they add generics to it. Just call it "Micro".

This so much! Go would be a great language if it had generics and no "interface {}". I'd use that over any flavor of Rust any day.

I'm curious what the next big language iteration will bring. It's been a while that I got excited about a new language, last time was probably C#, but that's 20 years ago... Crazy, that there hasn't been any new language revolution sort of how Java was one. But maybe I should look more into new things like Julia, but they seem a bit niche.

I believe the next evolution will be to combine Rust and Lisp; a programming language as flexible as LISP without giving up the safety of Rust, including a typesystem that can be entirely coded in the language itself, safely.

Rust’s macro system gives you this already. Is there something you see it not providing that the language you’re imagining would?

Rust's current macro's aren't as powerful as I would like them, and procedural macros are far more difficult and extremely hard to properly develop and debug.

The substitution macros aren't that much fun either since they lack certain capabilities (like introducing a new variable into the current scope without having to specify the name redundantly).

Without a lot of external libraries, procedural macros are almost impossible to write in my experience.

Neither of them allows one to properly code onto the type system or replace it and neither is properly supported by the IDEs (or RLS).

rust proc macros are limited because they need to be in a separate crate and syn is also not that much easier to work with, it's too level IMHO

I'd like to be able to hide Future, Vec, Result, etc. behind a trait.

> a typesystem that can be entirely coded in the language itself

The closest thing to this I can think of is Racket. It's supposedly powerful enough to embed Haskell in it https://lexi-lambda.github.io/hackett/

I would imagine something closer to rust in terms of base and then being able to put Haskell on top without loosing any safety guarantees. Or possibly even allowing an arbitrary type system as long as you can prove it's sound with the guarantees of the language.

Types are closed terms of contracts encoded in a language within specific phases. If you really need any guarantees without further knowledge shaped before running, then, besides the typechecking, the typing rules should also be programmable by users (rather than the language designer) for the sake of providing proofs. The base system must practically have no mandated static type systems at all, which is far from Rust.

I would disagree, you need a solid typesystem and then any other typesystem must prove to be a compatible superset.

It's about the ability, not the reality. As Racket, the base language can have no explicit rules for any type systems to be embedded. There can be more powerful candidates, e.g. Kernel: https://web.cs.wpi.edu/~jshutt/kernel.html.

Racket is special because its designers provide dedicated support of language-oriented programming. But that is about ecosystems, not typesystems.

I have something similar in mind: I want to have homoiconicity but with typed data underneath (instead of just untyped lists) in order to add some structure and let compiler help you with macros. That plus advanced type system with gradual verification. I'm in early exploration phase, but I have some ideas written down: https://github.com/krcz/zygote .

I hope the next big programming language will be one that is split into two language-variants: the "low-level-variant" and the "high-level-variant".

The high-level-variant is a dynamic language with optional typing, which is good for scripting, fast prototyping, fast time-to-market, etc.

The low-level-variant is similar to the high-level-variant (same syntax, same features mostly, same documentation), but it has no garbage collector, typing is mandatory and it runs fast like C/C++/Rust. Compiled packages that are written in the low-level-variant can be used from the high-level-variant with minimal effort or without additional effort at all. The tooling to achieve this comes with the language.

While it's not exactly there, this kind of describes Ruby and Crystal.

Proponents would say that julia is both languages at the same time

Yes, and I think Julia is a perfect starting point for an extremely productive general purpose language.

The one major wart with Julia is reliance on GC, I'm interested to hear what workarounds exist. If no common usage patterns rely on the GC, it should be possible to write "recycling" code that doesn't incur GC pauses and hence, unpredictable latency.

I really enjoy using Julia, it's a great balance of concision, expressiveness, and performance.

There is a common demand from people for extracting just a very concrete computation from a julia codebase and compiling it to a standalone library (or even just using it within an existing julia program, but guaranteeing certain allocation or real time behavior). For example, julia includes a pure julia implementation of libm, but we also maintain the openlibm C library, since we link it into some of our C dependencies that need good quality math functions. It would be nice just to compile the julia version and have it be a drop in replacement for the libm that can be linked. Of course for that you don't want the runtime, or GC or code generator. The challenge here is coming up with the right interfaces and abstractions to make this a feasible and useful thing, without splitting the community into those that care about it and those that don't. We've started some work in this direction, but it isn't really usable yet.

This sounds amazing and exactly what people have been clamoring for. Extremely excited.

I think it will also rocket up Julia's popularity and usage not just for ML but as a general purpose language

Looking forward to have this capability in Julia.

Is some concept of language support for traits/ interfaces and/or static typing part of this effort?

Also, would there be different levels of leanness for the static compile? I can see some people wanting binaries that use a minimal runtime or GC, but no heavy JIT etc so that a larger set of programs can be distributed but at some tradeoff.

AFAIK, Julia has a garbage collector. I envision the thing more like a rust split into two variants. One with GC and mandatory typing, one without.

Yes, for sure my suggestion was an incomplete answer, but still you would want the lower language be GC-aware/GC-compatible so I am not sure what the advantages of having two languages would be compared to having a GC language that can have non-GC modules/functions.

We also have an example of something more similar to what you are asking with Javascript+wasm (or better Typescript+wasm). I think they are both a fertile ground for future growth.

Here, https://dlang.org/

D is pretty much the opposite of Go, a pinnacle of feature bloat instead of stripped down simplicity. A C++ killer that turned into a kind of C++ with GC.

Go would be have an interesting language in 1986 [0], or in 1995 [1].

As it stands, it is forced to follow some of Java design mistakes by not integrating modern features and then being forced to actually adopt them in a half-baked way due to market pressure, while striving not to break backwards compatibility with existing code.

Modern C++ also uses GC, even it is opt-in.

And several modern C++ features actually originated in D.

D has the benefit of not being constrained by C copy-paste compatibility like C++.

But yeah, it suffers from having a tiny community.

[0] - https://en.wikipedia.org/wiki/Oberon_(programming_language)

[1] - https://en.wikipedia.org/wiki/Limbo_(programming_language)

> But yeah, it suffers from having a tiny community.

And feature bloat.

Being a modern language not stuck in the 60's language design is not feature bloat.

Orthogonal concepts.

Modern languages can be bloated.

Or stuck in the pre-history of language design.

If Go's design was perfect, its eco-system wouldn't feel like Java 1.0, full with libraries to replicate what should be language features to start with.

The first time I saw "go generate" it was on Borland C++ 2.0 for MS-DOS, released around 1990.

Can't lie. It's entertaining to watch people like you get emotional over a piece of technology.

Not really, passional about language design and safety, indeed.

Some of us care about advancing the state of art, instead of being stuck into the ways of the past.

There it is. :)

Zig's comptime is a very simple and minimalistic but still incredibly useful and strong approach to generics. I think that could fit into a language like that. I many ways I find Zig as keeping the minimalism trait that Go has (which they both take from C). But I get that people want a gc sometimes.

Zig is beautiful, I'm having high hopes for it.

You may, or may not, be aware of this - https://blog.golang.org/why-generics

I believe it's still in the roadmap for Go 2.0

Go is garbage.

I really like the idea of implementing mutability control at the level of a collective as opposed to a single object. A great many transactions are multi-object.

Love the idea that a Netscape-legacy language has traction there. I hope they don’t return to their pre-Nadella practices.

Actually in Rust you have a problem where you can't express partial access to a struct at a function level. This means that you can't put some code into a separate function right now, making use of closures/iterators harder. There are attempts to fix this ([1] [2]). If borrow checking is done on collections of objects instead, the problem can be tackled more easily I think.

[1]: https://github.com/rust-lang/rust/issues/53488

[2]: http://smallcultfollowing.com/babysteps/blog/2018/04/16/rust...

There's some friction there, but in practice it's easy to work around most of the time. I'm not sure extending the type system there is worth the weight.

This is great news. Microsoft is adopting/forking Rust. That means Rust will be supported for all eternity.

It appears to not be an actual fork - the slides say the compiler isn’t implemented

It's just a new, separate research system which has somewhat similar goals to Rust. The headline is basically wrong.

There are also Microsoft teams starting to use Rust, e.g.,

https://msrc-blog.microsoft.com/2019/11/07/using-rust-in-win...

Or at least Microsoft Visual R++

Exactly, for anyone that recalls Visual J++, this should send a shiver down the spine. No, they haven't changed much, yes they do better PR now.

That will be very sad if it's the case.

One reason of why I'm using Rust is because it's built by a group of people that I like, and Microsoft is not on that list.

However, I always keep a open-mind, I mean, I don't see anybody will be hurt if Microsoft become a direct contributor of Rust language itself. In fact, I could like Microsoft a bit if they did invest in Rust. I hope they do that <delete>instead of trying to fork things/build something alike (if that's the case here)</delete> (I watched their intro, their design is different than Rust and I somehow like what they did there).

I'm about as old-school anti-Microsoft as it gets (I had a 4-digit slashdot ID!) but even I have to admit that they've been pretty serious in offering olive branches to the broader open source community in the past decade. I'm prepared to give them the benefit of the doubt.

If someone had told me ten years ago that my favourite code editing environment on the Linux desktop ten years later would be browser-tech-based, MIT-licensed, and made by Microsoft, I'd have stared at them like they had just grown a second head. But here we are. Interesting times, man.

R, perhaps?

Just like Windows on ARM is supported for all of eternity! Or google anything, or any one of a million failed and dead projects.

Cool that MS is using something Ruat based. In no way does that opinion lead to a conclusion of ongoing support.

If they’re rewriting Windows core bits with it, that’d seem a fairly strong indicator their involvement with it is serious. That’d be unnecessary technical debt otherwise.

Windows on ARM is probably fine. Windows Phone and the like eventually lost (losing? I haven’t kept up) support, but phones are traditionally a 2ish year supported device and then they’re not targeted (specifically in the Android OEM arena). Windows proper they have business clients and if they don’t support it for a reasonable amount of time, Microsoft is basically hosed. It is, I imagine, why once they decided to kill off older IEs everything prior to latest and greatest was killed at the same time: they had supported them for far too long and it required killing them all Off in one move.

It is not like that. C was supported before GCC project also but it was not of any use because it wasn't widely used. Either we need open source alternatives or there must be competition based on open standards.

> C was supported before GCC project also but it was not of any use because it wasn't widely used.

I’m pretty sure you’ve got your history backwards. GCC was created specifically to fill the need for a free C compiler for GNU. By that time C was already popular by association with Unix.

Found the article to be somewhat vague and found this slideshare presentation which was...a little less vauge.

https://www.slideshare.net/KTNUK/digital-security-by-design-...

It seems like they want to do something like Rust, but with a new focus on regionalized memory management.

What does "Rust-based" even mean? Inspired by Rust? Does it transpile to Rust or something? Very confusing phrasing to me...

Historically it means they would start with Rust and then add in just enough Windows proprietary stuff to make it not run on any other platform.

Given their past years of behavior and focus on dev tools, what in the world makes you think that would be the case? They ported their chromium browser to every platform from day 1.

Two words: Steve Ballmer.

The former CEO who retired five years ago?

Yes. That's why people are still super nervous whenever Microsoft dares to embrace something new. Past experience.

I'm not saying they're like that today, but that's why some people get all on-edge when Microsoft does things like this.

But he’s not the CEO any longer and he hasn’t been for years. So why is what he did more than a decade ago relevant absent of evidence that he has any direct control of the company today?

One CEO doesn't make an evil empire. Bad influence remains. Many evil minions that were forged from Bill Gates and then Steve Ballmer are still in the company. And ontop of this, Microsoft is still a big money-driven Company, so some natural evilness is always there.

Microsoft has become better in the last years, but they still do bad things. So why should people trust the wholeheartly?

Many developers and entrepreneurs had numerous very bad experiences with the Microsoft of the 1990s-2000s and you're expecting them to just move on like nothing happened?

Remember Microsoft tried to kill the internet and could have succeeded if it wasn't for the efforts of many, the US DOJ included, to prevent them from obtaining total control through their operating system monopoly.

You can't go through that and not be skeptical.

Given MS history, EEE was the first thing I thought about too. Take something, extend, then claim it's superior and everyone should stop using the original.

But if it simply means they are making a new language using lessons from Rust - then why not.

Though I didn't quite get what problem they found with using the idea of scope based lifetimes per object, that they needed to redefine it in context of groups.

It's probably what they did with C#, starting from Java. I don't think there will be any compatibility, only high level similarity.

Alternatively it could be what Microsoft Research does a lot which is take some subset of a language and add capabilities, like software verification with F*.

Which is pretty much what the posts you replied to said.

On the road to R# I guess.

I guess shipping Windows API cargo crates makes too much sense. Does anyone have any context for gaps in Rust they are addressing?

In TFA it mentions that ownership will be based on groups of objects, but I’m not sure I understand what this solves that a struct doesn’t.

> I guess shipping Windows API cargo crates makes too much sense. Does anyone have any context for gaps in Rust they are addressing?

I haven't finished digging through the OP, but it looks like a bunch of Microsoft employees (already aware of Rust's safety benefits) have started recognizing the commitment to FFI as well. My last project had a feature that depended on a bind to win32, which turned out to be the most time consuming aspect - as it demanded a bunch of tooling that was otherwise unnecessary (valgrind, etc). If they were to take stewardship of that interface, lots of unsafe{} would disappear overnight.

https://kennykerr.ca/2019/11/05/rust/

It’s described as a completely new thing, that borrows some ideas from Rust.

Seems like Microsoft really needs Rust. They've completely gutted their prized aggressive prerelease testing, and the quality of the software they expose users to has declined dramatically.

I heard 70% of their bugs are related to memory handling or off-by-one errors. About 7 severe bugs per year. It can cost them from anywhere between 100k to 10M to fix the bugs and problems caused by these bugs.

This so reminds me of when I hear of J#, and again when I heard of C#. Will it be called R#?

What a huge validation of Rust. Here’s to hoping this improves Windows.

Lol, if they wanted to make it better they'd adopt some practices and tools from Linux to get common-sense developers interested instead of looking for MS drones that don't know why they do what they do.

They did: https://docs.microsoft.com/en-us/windows/wsl/about

Linux tools run on Windows 10 just fine. WSL 2 even uses an actual Linux kernel.

Unfortunately, they didn't make the far more compatible step of getting Windows to run on Linux.

WSL performance is terrible not to mention WSL 2 is still pre-release with lots of bugs and so is their updated terminal app. I don't even think WSL 2 will support Docker, and it is using a broken VM and Plan 9 to share files so you lose most of the performance benefits of Linux. It appears MS is trying to get people to try Linux on Windows and make it bad so that they get a negative first impression.

I think it's gonna be something good from the creators of Typescript, the most flexible and object oriented language. Microsoft created too many languages compared to any other company and they really one step ahead in this field.

Impossible! Java-heads consider this solved! /s

How long before redox will run on my surface?

embrace, extend, extinguish once again?

For the hating Microsoft crowd, here are the projects where they are also using Rust,

https://msrc-blog.microsoft.com/?s=rust

And the talks done about the internal adoption,

https://www.youtube.com/watch?v=qCB19DRw_60

https://www.youtube.com/watch?v=o01QmYVluSw

And the author from C++/WinRT is now working on Rust/WinRT.

https://kennykerr.ca/2019/11/05/rust/

So lets wait a bit before going to the castle with the pitchforks and torches.

As a big proponent of F# it annoys me how much one still needs to fight "but M$" arguments if I point out a thing that F# does well. The same thing seems to happen when discussing Haskell with people who know just enough to recognise the influence MSR employees have on it.

It almost makes me wonder how they/we can work around that sentiment now. Either hope for generational shift to eventually kill it, or perhaps have them make a point of landing projects outside of MS and hoping nobody notices(GitHub R++ or whatever).

Tips on how others approach these discussions with Microsoft haters greatly appreciated!

“Fool me once, shame on you. Fool me twice, shame on me”

I try to be objective as much as possible, but having witnessed almost all of Microsoft’s behavior through history, we have been fooled 100s if not 1000s of times. How many times do you let the fox back into the hen house?

The only thing I think when I read recent “Microsoft is so great” comments is that the person is either too young to have any real knowledge, or they have simply not been paying attention for the past few decades.

For anyone who has seen what they have done through all of history, it will take decades to believe they have truly changed.

Big companies are not autonomous and do not make their own decisions, individual people working at those companies do. I think it’s safe to say that anyone working there today has nothing to do with the time periods you’re referencing, so I don’t know why you would consider decades old issues to be relevant today.

As part of the BSA, they still lobby for software patents today.

The OOXML Office format they used to continue pushing Office lock-in is very recent: https://wiki.documentfoundation.org/LibreOffice_OOXML

They tried their best to keep the list of their Android patents secret, so that they could not be worked around, and they abused their patent on the FAT filesystem as recently as 2012: https://www.howtogeek.com/183766/why-microsoft-makes-5-to-15...

They also still lobby against open standards: https://www.computerweekly.com/blog/Public-Sector-IT/Microso... https://www.theguardian.com/technology/2015/may/22/microsoft...

And lets not forget all the spying in Windows 10.

MS is as hostile as ever - it's a fantastic success of propaganda to make people think it's limited to "decades old issues".

Less propaganda that the whole "do no evil" stuff.

Windows 10 telemetry is a child's game compared how much Google and FB spy on people's lives, yet most MS haters just jump of joy to use any tech that comes out from them.

Legions of US parents just put their kids under Google surveillance getting them Chromebooks.

OS spying is so much more invasive than application or service spying because you can’t opt out as easily. You can go without Facebook but a lot of people just need windows (for their jobs if nothing else, though I sure wish unity3d ran better on Linux and that more games ran smoothly on Linux)

The OS is also theoretically able to watch what you do in other services by monitoring keystrokes etc, where Facebook merely dreams of such things

I am not one of those MS haters - I dislike Google just as much.

https://azure.microsoft.com/en-us/blog/microsoft-joins-open-...

Serious question: are there any major closed-source software companies (so like, not Red Hat or Canonical, etc) who don't lobby for or use software patents?

I consider using patents to extract payment a far lesser evil than lobbying for them. And an even lesser evil if the patent has some merit to it, and is licensed openly (i.e. no confidentiality terms to prevent revealing which parts of Android they claim to have patented).

As for your question - Cloudfront springs to mind - they're pretty loud about going after patent trolls, which implies they might not use patents aggressively. I'm sure there are many others, but a company not using patents to extract payment isn't something you hear about, so it's hard to tell. That said, despite filing for many patents, I haven't heard of Facebook actually using them against others. Which isn't to say they haven't done so (and possibly, like MS, kept the agreement confidential), and of course Facebook is hardly ethical itself.

Another poster says Microsoft joined the Open Invention Network, so perhaps in that area, they've reformed. Though they could still be lobbying for patents, which does much more damage to user freedom.

There was a medium post about Microsoft's culture and their inability to move on past Gates and Balmer about 6 weeks ago [1]. According to that article you are objectively wrong in saying "it’s safe to say that anyone working there today has nothing to do with the time periods you’re referencing". The article claims that the majority of the power within Microsoft still lays precisely in the hands of people who worked for the company during the times referenced.

1. https://onezero.medium.com/speaking-truth-to-power-reflectio...

I know you referenced that article to prove you point but it ultimately does just as good of job as saying the opposite.

One example: "Microsoft is killing it. Revenue is up. Stock is up. Industry stature is up. The places where Microsoft finds itself thriving all have one thing in common: key made-men were pushed aside for better people."

I was contradicting the clearly false claim made by OP, not trying to give the nuanced portrayal from the article. The thesis of the article I posted is that Microsoft continues to be haunted by the vestiges of Gates' and Balmer's influence. I think your cherry picking of a single quote praising some positives the author provides to balance his polemic is purposefully misleading.

The original argument was: "Microsoft still has the elements of its previous bad behaviour in its DNA." The counter claim was: "No one from Microsoft during that time is still in the company". The article clearly supports the first claim and shows the second claim is at its face false. I encourage everyone to read the article and not to take speculations and misleading quotes as support for false ideas.

Does the fact that some Microsoft employees, even those in positions of influence, remain from that time matter? Does the fact that there are new successful employees, with entirely new ideas about products and management, matter?

The article demonstrates that Microsoft is a complex organization with both good and bad and is changing for the better even if it has a way to go.

Supporting the good and praising Microsoft for what they're doing well is going to make Microsoft better. Crapping on what they're doing well because of actions from 20 years is not rational or helpful.

If you are asking: "Should Microsoft get some credit for the positive things it has done" then the answer is clearly yes. Even during the time periods where Microsoft was universally (and legally) perceived to be engaged in unfair business practices my own feeling is that their overall contribution to IT was a net positive.

That does not change the fact that Microsoft is a risk. Google is a risk since they have a habit of shutting down projects. Oracle is a risk due to their insane licensing and consulting fees. Open Source is a risk since the contributors can just decided to drop support. Everything has elements of risk. I guess I just won't back down from someone claiming there is no risk in Microsoft because all the bad people are gone. That is an absurd claim that also happens to be false.

That's arguing against a straw man. Nobody is claiming all the bad people are gone. But the claim that Microsoft is all bad was the source of this whole thread.

I am not claiming you are making that argument. I'm responding to the original poster, relevant part quoted here: "I think it’s safe to say that anyone working there today has nothing to do with the time periods you’re referencing, so I don’t know why you would consider decades old issues to be relevant today."

As demonstrated, people working during the time periods he referenced are still working for Microsoft, contrary to this claim. This also addresses why someone should consider the risk of "decades old issues" when making decisions today.

All those people who worked at Microsoft in the 90's and 2000's now work for at hundreds of other companies throughout the industry. And a whole bunch of people who weren't even born in those times now work for Microsoft.

I don't think your opinion is objective at all. It's based on treating a collective as a single mind.

Collectives and companies can keep the same culture and habits even if all people who worked there left. Because people come and leave not in the one go - they do it gradually, so every new employee is "indoctrinated" into the company culture, then indoctrinating new people themselves, even if their mentors left.

Obviously ms doesn’t have a candidate must be ruthless two faced bad person interview assessment. I think you are missing a very important ingredient to a company and that is its culture. Company cultures get diluted to the better or to the worse. As in either the company changes the newer employees or the new employees change the company

Name me any other big company with great ethics and all nice and fluffy. For example look at how Google had started and what it has become.

Not really trying to protect Microsoft here but them companies are all the same, just different degree of "success".

I think that is exactly the point.

The argument is that if a language is developed/mainly contributed by a single company there is an inherent risk of that language being suddenly discountinued or lacking features that are needed by other people/companies.

At least that's how I understand the critics against microsoft in this case.

> lacking features that are needed by other people/companies.

Funny how nobody seems to give pile on Google for how it handles Go here...

I am an older fart and my preference for my own products is C/C++/Delphi/FreePascal for servers/desktop and JavaScript for web front. I program in many other languages as well but mostly because clients require them. In the latter case it is a consulting job and the last thing I care about is how their favorite languages are managed. It is their choice and I am here to take their money, not to judge their preferences. Advising client to use particular language instead of their favorites is straight road to disappointment.

I don't know where you got that impression -- every new Go proposal document posted to HN garners a significant amount of Google criticism. The most recent example I can think of is the fairly widely-argued criticism of the "go mod" proxy. Not to mention all of the criticism over Google's consistent mishandling of community concerns.

It's hard to be nice and fluffy in a market where there's a lot of competition, but there's degrees. When you deliberately attempt to sabotage other people's software that has to run on your OS, but competes with an MS Product (e.g. Lotus vs Excel) then it's stepping over a line.

Thanks goodness for Linux and the web (and later mobile computing which MS failed to dominate) to pull us away from the brink of an MS monoculture.

Or you are just so bogged down in history that you have a difficulty changing your opinion. Few decades is a long time in our line of work.

Microsoft didn't change out of charity or ethics. They were forced by the direction industry was heading as a whole. Cloud, opensource software, Google, AWS started making Microsoft irrelevant unless they changed.

Bogged down in history. One has to admire at least a little bit this attempt at gaslighting someone into not trusting their own experiences and Microsoft's long negative track-record which they're still adding to.

The telemetry scandal which has been reported on everywhere proves that Microsoft just changed into another Google. They're still collecting telemetry today, in spite of all the protests. A few hours isn't a long time in our line of work...

“A few hours(...)”

Are you referring to this?

https://www.infosecurity-magazine.com/infosec/atom-community...

The telemetry in windows is ongoing so I’m just wondering if I missed something new

This is from MSR, which mostly functions independently of MS the company.

My only beef right now with Microsoft is their insistence on having creepy telemetry in everything. As someone _very_ interested in F#, I encountered this recently with both Visual Studio Code and .NET Core.

https://github.com/dotnet/cli/issues/3093

You can always switch to the original - the OCaml language.

I spent a while looking at OCaml, but I'd like to use more than one cpu and not have to deal with four standard libraries...

The linked thread discusses the telemetry and if you follow it through telemetry is now off by default, opt-in only.

https://github.com/dotnet/cli/issues/10816

I followed the linked threads and I don't see where it says telemetry is off by default. I just see people saying that it _should_ be off by default. Am I missing something?

Sorry, I misread the threads, I think you're right. There's notification when you install it, but the notification is that it's on by default. The notification also explains how to switch it off (with an environment variable).

Microsoft is actively collecting billions of dollars by patent suing (or threatening to) Android providers despite contributing nothing to Android. That's what kind of company they are. They also make some great stuff, esp MS Research. I'm hesitant to use anything made by a company that patent trolls other companies, though. I don't feel safe in long term.

Why F# was needed in the first place? OCaml[1] is vastly superior, and doesn't require .NET since can be compiled into the native code. Just in the need of the better Windows platform support. And they add more features with time than F# devs.

I can add F# projects to existing solutions and use F# in some places, C# in others, and C++ in still others, heck even VB.NET can come by for a drink if I'm feeling shameless and not needing to keep up appearances.

OCaml cannot do that. I say this as someone who currently is finishing a year of F# study with plans to study Rust in 2020 and OCaml in 2021.

OCaml has FFI, so C++ is not a problem. .NET is trickier, but can be integrated through RPC or another kinds of remote communication

They could have ported ocaml to the clr instead of doing their own ms thing. They could have promoted ocaml instead of splitting the community interested in a practical ml derived language - with the consequence that today neither has a relevant user base.

And they did initially, but OCaml.NET had its own set of issues regarding interoperability with .NET code.

Has MS ever been a member of the Ocaml Software Foundation?

The access to .net framework libraries is a huge asset. If I recall correctly, Ocaml standard library never nearly that complete, and the language was a bit moribond few years ago.

> It almost makes me wonder how they/we can work around that sentiment now.

From my perspective, the issue ultimately is - why? What do I gain from using Microsoft software?

I worked at a Microsoft shop for a short period. All of the 'new MS' stuff I've personally worked with has certainly been Windows first.

Take C#. It might work on Linux, sure, but you have stuff like the .NET runtime taking forever to start, the reliance on Visual Studio, .NET Framework isn't open source because.... why?

Or perhaps you have Microsoft Teams - for which, despite it effectively being a web app - there is no Linux client and in Firefox half the features are disabled. Even on Windows it's literally a shit version of Slack which presumably exists solely because it's bundled with other Microsoft stuff or because the name has appeal to some PHBs.

For the most part from what I can tell it's all still either Windows first, or a crap version of something else, or both. There might be some minor researchy fun bits, but anything that seems to actually see wide use is all Windows stack.

What's the point? I read the article, and it pretty much feels like they want to Windowsify Rust. Why should I care about that?

Literally everything I read about Microsoft seems to be from people who want an excuse to use Windows, or something. I want Windows to burn and die in a fire; so what is there for me?

Argh, they couldn't just contribute to the existing project.

Argh, you couldn't just take the time to read the actual article.

"The ownership model in Verona is based on groups of objects, not like in Rust where it's based on a single object.

I did read that. So it's not a straight clone, but still, Rust has enough of an uphill battle as it is to reach wide adoption, without having its target market fragmented. So I would've been excited to see Microsoft embracing it instead of building a competitor. Not that I can necessarily judge them for that, but it's still disappointing.

Having rust as the only low level language with ownership concept isn't ideal either.

Sure, it's just that right now it's trying to bootstrap that category in the first place

I understand the frustration but this is from Microsoft Research. There is a long way before they validate the concept (or not).

If you're looking for a memory-safe language today or in the next couple of years, I don't think anybody will ditch Rust for Verona.

Fair enough

>> Having rust as the only low level language with ownership concept isn't ideal either.

I dont agree. Proliferation of languages has it's down side. Very few are self hosting, with most being built with C++. Rust is a safe C++ replacement. We dont need a bunch of those.

Not ideal isn't necessarily worse.

It is objectively worse for there to be two such languages, one of which is poorly funded and the other funded by Microsoft than have one such language that is cross platform.

Also the Java oxygen is sucked out of the room by C#. All the OCaml oxygen is sucked out of the room by F#. A world where all the rust oxygen is sucked out of the room by R# and tied to the windows ecosystem is a bad one.

They've tried this shit with a dozen other languages and besides C# being better than Java, (even though the .NET ecosystem sucks) it's always ended terribly. C++/CLR, IronPython, IronRuby, J#, etc.

Having your tech embraced by Microsoft is the kiss of death.

Until C# runs in half of the platforms that Java does, there is hardly any oxygen to suck.

> IronPython, IronRuby

"IronRust" would be amusing

Microsoft already contributes to the Rust project; for example, Azure sponsors our CI.

Lol, they host our data so therefore they contribute. That is some next level Stockholm Syndrome.

They're not "hosting the data" they're donating hundreds of CPU cores and infrastructure.

So does GitLab and it actually has an open source version.

We use a lot of CI; those resources are not cheap. And it is central to the way we develop the language, so it really really matters.

(And this is just the most obvious and clear way that they support Rust, it’s not limited to that.)

RScript.

EEE strikes again? Why not just use and contribute into the Rust itself? Why creating one more copy? They could have extended C2Rust[1][2] to support C++[3] and C# to ease their migration instead.

[1] https://c2rust.com

[2] https://github.com/immunant/c2rust

[3] https://github.com/immunant/c2rust/issues/162

Oh no, I bet it's gonna be a C# flavored Rust. None of Rust's terse syntax and functional influence. It's going to be full-blown Java-style OOP with plenty of Wnd handles to be thrown around. Yikes, I certainly hope I am not right.

Rust#

I would gladly accept C# styled system language which has same safety and borrowing features as Rust.

Why not a F# flavored Rust?

> plenty of Wnd handles to be thrown around

That is not really a language issue, is it?

this is what I'm hoping for. Introducing memory safety is enough I dislike Rust because of how different it decided it needed to be compared to most other systems languages.

Reply on news.ycombinator.com