Locke1689

That's just because you don't understand Google.

It was a ML company going from building ML for the internet to building ML for a car.

After re-reading I think I see that point, but I still don't understand the overall comment...

Is the author saying his standard language is C++? Everything I know about Midori said that it was competitive with C++ on performance in almost every way. Regarding error handling in particular, Midori used a combination of returning values and safe exceptions, both of which seem similar to C++.

It also explicitly doesn't have the aforementioned conflation of bugs and runtime errors.

I'm not really clear what this comment implies?

What system do you work with that doesn't have null pointers but also cares about eliminating as many fine-grained locks as possible?

> Because really, you don't really need to check whether something is an instance of "List<int>" at runtime, in a static language, unless your language sucks ;-)

So, I hate reflection with a burning passion, but this is wrong. You may not like doing it, but there are tons of legitimate use cases for RTTI.

My primary case is for runtime "light-up" of advanced features. For instance, if you deploy an application to a series of platforms that provide non-overlapping sets of capabilities, a fantastic way of dealing with this problem is to use RTTI to check whether the instance of the object is some specialized case at runtime, then cast to the specialized object to use the specific features (e.g., GPS, touch screen) that are only available on that platform.

The problem with .NET reflection is not that this dynamism exists, it's that everything is bundled together without an opt-out. I would love to have reflection split into small pieces that I could pick and choose from -- maybe I get RTTI, but I can't instantiate arbitrary generic types at runtime, for instance. Or I can't do RefEmit to JIT dynamically generated IL.

These play havoc with the runtime, forcing it to support incredibly elaborate systems just for simple features, so providing some guarantees would make the runtime's job way easier while also providing developer flexibility.

IIRC, a potential confounding factor was that this building is much heavier and has a smaller footprint than standard.

It sounds like what you want there is RVMO?

Tuples are value types, so every new reference to a tuple is a copy. This avoids a lot of the situations you would normally get.

Well, let's say Line, Rectangle, and Circle are reference types.

Which case does null match?

If you match the first type, that's somewhat unsatisfying. But if you only match with default, that's also unsatisfying because now we would have a problem with completeness -- if the match doesn't succeed then you have a potentially unassigned variable.

So now every match expression would have to have a default case just to handle null, but you also don't gain the advantages of static matching because everything matches default, so if you do legitimately forget a case you get no warning.

Existing switch statements are much more resilient to these matters simply because they aren't expected to be exhaustive right now. People are used to the fact that they have to deal with unassigned variables or completeness failures.

The match expression, however, I want to be more like ML where you can get strong guarantees on the "irrefutability" of a match.

Regarding switch-as-expression -- the semantics of pattern matching as an expression can be subtle, especially when paired with nullability, so I think there's more support for introducing a new "match" expression that does what you describe.

Switch is more of an effort to integrate patterns in the way C# is used right now.

The C# LDM takes inspiration from good ideas from everywhere, including Scala.

This is actually not the case -- none of the members of the language design team are MSR employees.

It is quite confusing (sorry) but the format of the project files won't change the command line interaction -- you'll still do

   dotnet build
   dotnet run

It's still in preview, but you can build .NET Core apps with the .NET CLI tool: https://www.microsoft.com/net/core#windowscmd

The Washington Post[0] has it broken down by demographics since June. As you can see, as of October 13th, Trump's only lead in education is among voters who have completed "some college", with Clinton having a huge lead among those with college degrees and postgraduate degrees. She even has a narrow lead among those with a high school education or less.

[0] https://www.washingtonpost.com/graphics/politics/2016-electi...

Link [0] States that they're not lower-income, not that they're educated.

That article is from the April primaries. Donald Trump's demographic support is much different now.

The problem with sharing is that you can inadvertently keep a massive string alive by only holding on to a tiny piece of it.

Span<T> conveniently side steps this issue by only existing on the stack, meaning that you can't stash away the span somewhere and accidentally keep the underlying buffer alive longer than necessary.

Oh, just clarifying for people that it's not just unusual apps with large blocks of memory that will benefit. Even mundane apps that do a little string manipulation will see the results.

The main use cases are actually way more mundane, but also much more impactful. Consider some of the most common string manipulation code you see: grab a substring, compare it to some stuff, branch based on results.

Since strings are immutable and non-sharing, all substring calls will create copies of the substring. With Span<T>, you could instead simply request a span of the string and, with unification in the underlying typing, you can perform all of your string manipulation with no allocations or copying.

Right, ultimately it will be enforced by the CLR type system, much the way most types are in .NET, but practically it will be enforced by the compiler.

You can already see this in the "ref parameters" feature in C# today: they can be parameters to methods but cannot be stored in fields. This implies that they can only exist on the stack.

Similarly, when we add support for ref-locals and ref-returns in C# 7 that will still disallow ref fields, so ref variables will still only be allowed on the stack.

> They aren't going to move the kernel to a microkernel type design

Food for thought: the Windows Subsystem for Linux proves that it's possible to implement the Linux kernel ABI without actually being Linux.

I'm not sure how far you could go re-implementing the ABI on top of a microkernel architecture.

Probably. I don't really consider it settled, anyway.

You're both missing the point. They're talking about kernel security -- when they refer to "usability" they mean compatibility and ease of programming for user-mode applications interfacing with the kernel ABI.

This has nothing to do with non-programmers.

Lambdas are supported in the debugger as of Visual Studio 2015 :)

What's the problem with ECDSA?

What I'd like to see addressed more is his decision to outsource judgement to the news outlets. It seems that there is a qualitative difference between choosing to out sensitive information yourself and letting someone else ostensibly more qualified make the decision.

Even if we concede the improper revelations, how do we characterize this lesser culpability?

Buy treasury notes, actually.

If you haven't already pinged one of my colleagues I'd be happy to hear your rants regarding .NET :) ( angocke @ msft )

This is great work! Congrats to Jon Skeet and the other Google people who made this happen!

In a low-inflation, sparse investment landscape it's actually quite likely that people will hoard cash.