Metasyntactic

Hi there! I'm a developer on the .Net team, and I heavily work on our IDE offerings. You can absolutely write a small program that is only a CLI, and our tooling is heavily tailored to make that a great experience. First off, you don't need to use an IDE for this at all (if you don't want to). You can just do `dotnet new ...` from the command line to spit out what is needed to do CLI development.

If you do want to use an IDE, there are many choices available. First party options include Visual Studio itself (which has varying skus depending on what you're interested in). For just CLI development, the Community sku would work great. Then there is VSCode, which has both the open-source "C# Extension" (also built by us), and the closed-source add-on "DevKit" which enhances that further with more features".

Regardless of which environment you use, writing a CLI is extremely simple, and the language and environment cater to it. A simple 'Hello World' for C# literally is just:

    Console.WriteLine("Hello World!");

And you can grow on that as you want to flesh out whatever your CLI needs to do. If you're interested in doing anything web/server related, then ASP.NET Core also fits into this very simply, allowing you to stand up a web server from your CLI app trivially.

We def want .Net, including the language, runtime, and tooling to scale all the way from these sorts of experiences to the "enterprisey" space, in a clean and consistent fashion.

If you do run into issues with any of the above, def let us know. You can see all the work we do in .Net over at github.com/dotnet/... Including what's being worked on now, and what we're continuing to invest in for future releases.

Thanks!

Hi there. I'm the language designer who created the 'Collection Expression' design/specification: https://github.com/dotnet/csharplang/issues/5354

You can see the entire history of the proposal there. To answer you specific question, we went with `..` because that's what the language already uses for the complimentary 'pattern matching deconstruction' form for collection patterns.

In other words, you can already say this today:

    if (x is [var start, .. var middle, .. var end]) { ... }

So the construction compliment to that is:

    M([start, .. middle, end])

We very much want 'construction/deconstruction' to have this sort of parity, and we will be continuing to follow that principle with new features we are continuing to invest in.

--

Now, if your next question is "why was .. picked for collection deconstruction?" the answer is "because we considered that the nicest syntax from the choices we considered". Syntax is often very subjective, and we often come up with numerous forms to consider (along with examining other languages to see what they've done). In this case, we simply preferred `..` over `...`. The extra dot didn't add anything for us, and we also felt like it might be an operator we might want to use in the future for other language features.

--

Finally, if you're interested in these sorts of questions/designs, def participate on github.com/dotnet/csharplang. We do all our design in the open over there, and are always interested in community perspectives on these sorts of things.

Thanks!

Hi there, C# Lang Designer here. :)

We're always thinking about the bloat concern when it comes to language development. However, our philosophy on it is that bloat primarily comes when you add replacement systems that are expected to supersede the previous mechanisms, not compliment them. So we try to do the former sparingly. In the history of C# there are very few times we've actually done this, and we do view those times as unfortunate cases where we likely rushed a feature too early and then regret having to live with those features forever.

To help combat this, we tend to go through long periods of design and experimentation, where we propose features, create prototypes of them, and then interact with a large set of diverse community groups to try things out. The feedback from this is tightly bound into our design process and allows us to refine (or even jettison) designs rapidly.

We also normally will both break up work into lots of smaller pieces (composing large language changes into small orthogonal, complimentary, composable blocks), and do designs over many years if appropriate. We think this approach has helped us create a language that is 25 years old, while being both very rich, and still very cohesive. There are a few mistakes we've made along the way ("anonymous-delegates", i'm looking at you), but we're very happy that our ratios here are very good given our continued investment in this space.

Hey there! Language designer of Raw Strings here.

The use of whitespace to affect the meaning of strings was actually a big ask from the community and was due to a lot of confusion and frustration over the years from customers who didn't like that if they had a multiline string that it would then not indent properly with all the rest of their code and would cause things to look cluttered and unpleasant.

Users participated in the design here and we got feedback from thousands in multiple venues about this design. The behavior around whitespace here was viewed as being both very beneficial and intuitive.

Finally, to help out here, the VS ide will also draw a line showing what part of the code is content and what is not.

You feel this is overcomplicated, but this was the result of a lot of cooperative design with a lot of the user base to something that was near universally felt to be desirable over not having this behavior. :-)

> (What happens if the closing quotes pass some of the text?)

That's an error. Called out here: https://github.com/dotnet/csharplang/blob/main/proposals/raw...

>And the code sample you show differs only in that closing quote isn't indented. You don't explain why and how that change would affect the generated string.

Hi there. This is explained in the spec in a few places. In the examples section it explicitly states:

> To make the text easy to read and allow for indentation that developers like in code, these string literals will naturally remove the indentation specified on the last line when producing the final literal value.

> If the indentation behavior is not desired, it is also trivial to disable like so:

I thought that was clear as the prior explanation says that we remove the indentation from teh last line. And then i show how you can disable it. Specifically, as you noted because the closing quote line is no longer indented. Cheers!

> I just really dislike reasoning about trimming the leading whitespace

Note: this feature is entirely optional. You can absolutely not have leading whitespace trimming at all. Indeed, this is a requirement of the proposal as we have to make it possible to actually represent text that has leading whitespace :)

Hi, I'm one of teh C# language designers, and I work on the compiler implementation as well.

C# has never had a "simple tokenizer". Indeed, even the first language has complex lexical constructs that are part and parcel of the language. For example, our comments can store structured data in them (like xml).

> A simple loop that would have worked with the 70s era of programming languages

Yes. But 70s era compilers had to deal with things like not having enough memory to even store basic amounts of data. It also had to work in spaces where things like a 'stack' was just not tenable. We're literally 50 years from that point, and having a compiler do stuff like keeping a stack is not an issue anymore :)

Hi there! I'm the lang designer and i wrote up that spec. Could you clarify what you didn't understand about the indentation examples? I can work on clarifying them. Thanks!

Hi there! I'm one of the C# language designers. I'm working on a proposal for that right now: https://github.com/dotnet/csharplang/issues/5354

Thanks!

Hi there, I'm the lang designer and implementor here.

That would violate a core goal of the feature which is that the content itself doesn't need escaping. This sort of approach would require all users to have tooling that would make that pleasant, instead of providing a feature that was easy to use across any editor.

Thanks!

Hi, i'm the lang designer and implementor here.

We absolutely do not normalize newlines as that would defeat the purpose of raw literals. The point here is that your content is not interpreted as that's the pain area that people are hitting today. How you write your literal is what you get at the end of the day.

Note: if the content needs to be `\n` then just use that actual newline in teh code. WRT to the file line endings and whatnot, my recommendation is that you never use tools that arbitrarily change that behind your back as it does already have impact today in C#. For example, that will break standard `@""` strings today.

If your line endings are important, then your tools should be setup to respect what you wrote and not change them. All editors can be setup this way, as can git. And that would absolutely be my recommendation on how you should structure things for your code if newlines are relevant.

Hi. I'm the lang designer and feature implementor.

To your question of "why?", we tried to cover the reasoning in teh proposal. But, the core reason is that today people do use strings a ton. And in many cases it's unpleasant to do so because you always end up with reasons that you need to escape the content. This escaping serves to satisfy the compiler, but really doesn't buy value to teh user the majority of the time. The idea here is that you can just use a raw-string and say: here's the content, exactly as i want it.

>Now we're adding {{ and }} into the equation. Yay.

Hi, i'm the lang designer and feature implementor here :)

The complexity of lexing/parsing did not get worse here. We actually just lex/parse this stuff the same way that interpolated strings have always been lexed/parsed. This has been supported in the language for almost 10 years at this point :)

Hi, I'm the lang designer here.

We looked into this. However, there didn't seem to be any benefit to this above just the N-quote version (which fits into how C# does strings everywhere else). In the above case, the `SQL(` and `)SQL` tokens are just akin to N-quotes. Since there's no additional benefit, we went with the simpler approach that solves all these needs, but will look the same across all codebases.

> but can't they use a symbol before the string like they do with interpolation `$` or literals `@`?

Hi! I'm the language designer here :)

I know it says design decision to go with 1 more " than the longest sequence of " in the string, but why ?

Because if we use a symbol before the string, then there needs to be some mechanism to escape it within the string. e.g. if you use `@` literals, you still need to escape quotes within the string literal. The point of this feature (which we try to spell out in the spec) is so that you can have content without the need to escape anything at all.

Hi. I'm the language designer behind this feature :)

A few points.

> but the following would generate the same string, since each line begins after the """:

That's not a virtue here. The point is to be able to write clear literals that never need escapes and which allow for easy grokking of what the content actually is.

All current string forms in C# require some amount of manual (or tooling) help to fix them up to be legal. That's not the case with this literal. The content can always work as-is without having to touch it at all.

Hi. I'm the designer of this feature. The reason for this is so that we can potentially have fenced string blocks in the future. for example:

```c# var s = """xml <Book><title/></Book> """; ```

and the like. Thanks!

Hi. I'm the designer of this lang feature. The specification covers this. However, to be clear, neither new line after the first `"""` is not part of the literal, nor is the newline before the last `"""`. Thanks!

FYI, i work at MS (on a compiler team). The work-life balance is fantastic. I'm not sure where you got the idea that that isn't so. Thanks! :)

> it bothers me that the keyword in the class declaration is "data"

The keyword is the declaration is `record`. So you would write your record:

   record Person(string FirstName, string LastName);

Source: I am one of the language designers on C# :)

> but hypothetically this is the kind of thing that could have an impact

It's not hypothetical :) We've measured, and moving to 64bits is a serious issue and would directly affect many customers who could not take the RAM hit.

> But I also "know", and you also maybe secretly "know", that you will eventually move to 64-bits

At some point we probably will. but it certainly isn't now. We have ample information on the types of machines that people use for development and we've measured extensively the different approaches that are possible. Right now 64bits would be a bad decision, and going the multi-process route turned out to be quite good.

> I mean come on, even iPhone programs are 64-bits now.

That's not a reason to move. We should move to 64bits if it delivers a quality improvement and does not dramatically degrade the experience for many customers. That's not what would be the case today.

> There seems to be some people in the IDE team who believe that a 32-bits only IDE is a feature and not a bug, including for reasons as fun as because it crashes sooner in case of memory leaks...

To be clear. There are zero people on the IDE that think this. The IDE team has to deal with the reality of the situation that there are humongous solutions, and very resource constrained machines. And we've been hearing from huge numbers of developers that they absolutely do not want memory requirements to go up. Just moving to 64bits is extremely problematic. As i've already mentioned that can easily double the memory requirements for many components in VS. That's going to make VS2017 a complete non-starter for many customers.

We do not haphazardly make changes "just because". We measure measure measure, and we're loathe to do anything that we've got enormous real data on on how negative the impact could be.

The approach we've taken has actually extremely improved throughput, scaling and latency, all while actually decreasing memory usage. We're going to continue making the changes that support those goals. If/when we can have a 64 bit architecture that supports those same needs, and gives an acceptable impact on the vast majority of user machines, then we can move there.

> are you satisfied with this solution?

Yes. This approach allows for far more interoperability in this space. Instead of having language features be locked into specific compilers/toolsets. You mentioned 'simplicity' and we've traded off one sort of simplicity for another. The approach you would like (which we used in the past) used to not be simple for the customer that wanted the scenarios to work that we're enabling now.

> Would you expect to have to go to a package manager to use tuples in python?

I could definitely expect that new language features might require library updates, yes.

> My opinion is that simplicity matters a lot to the success of a platform.

I think a lot of things matter to the success of a platform. For every developer who wants the type of simplicity you mention, there are developers who want other sorts of things to be simple.

> And by the way nothing in the error that you display when using tuples in VS2017 suggests a nuget package or an assembly name that can be searched.

Yes. We could certainly make this experience better, and that's on me. However, as i mentioned already, there were difficult constraints to balance. We're hoping that our work moving things Out-Of-Process will help make it so that we can just light up this scenario by default. Then, you'd get this error, and the lightbulb would be right there to fix it up.

However, like with all things in development, you can't always get everything you want complete for every release. In this case we did not feel like it was justified to hold back all the rest of great feature work and performance improvements in VS just because users would have to do one manual step with one language feature when working with C#. You are free to disagree with that assessment on our part. But we're always going to end up having to pick a set of things we don't think will make it into any given release, and it's quite likely that for any given release there will be some things that you'd want (and which would make things better) that won't make it.

A great benefit of the new VS is that it's now much simpler for us to ship updates very rapidly. Instead of needing to wait literally years for updates, we can patch things immediately and we can complete features and get them in the hands of users in a matter of weeks. In that regard, i'm ok if this one particular experience isn't perfect. We can improve things as we move forward and continue delivering better and better experiences.

Thanks!

> So with c# 7 all I need is VS 2017?

All you really need is the new C# compiler. You can get that with VS2017, or standalone. But the programs produced by this compiler should be runnable on pretty much every runtime out there.

> It'll work with existing .net 4.5.x and 4.6.x projects?

Definitely.

> I tried tuples and VS complained

What was the complaint? in order to use Tuples, you need a reference to add the System.ValueTuple NuGet package as that's the type under-the-hood that packages up the tuple values so other people can consume them.

This is a nice approach because it means your APIs can use Tuples, while people using C# 6.0 and earlier can still use them. effectively.

> In order to compile on a build server do I need an updated toolchain?

If you use C# 7.0 features, then use. You always need the appropriate compiler to use the latest language features. But you shouldn't need to really 'upgrade' anything else if you don't want to. (You can, of course, if you do want to).

Hi Xorblurb :)

I'm a dev on the "IDE team" :)

We've actually done a huge amount of work investigating and addressing perf issues and working to create an architecture that can scale well. 64bits is not a panacea. And if we had simply moved to that, most people would find that their IDE was using much more ram AND behaving more sluggishly.

We decided to invest our energies in work that would actually benefit the vast majority of customers. This led to efforts that we were able to demonstrably measure as producing better experiences for people. If there's a point that 64bit will actually produce better results for people, we'll gladly move to it. Thanks!

Hi Douche,

I'm Cyrus, a developer on the C#/VB IDE team.

One of the areas we invested a lot in (and will continue working on) is moving a lot of our analysis and processing work out-of-process. It turns out this is a much effective way to get improved performance while taking advantage of the available RAM in the system.

There are several reasons why this is, and why it's a better solution for performance than just moving to 64bits. For one, moving to 64bits substantially increases the memory requirements to the system. For the C#/VB compiler/IDEs, it can easily double the amount of ram necessary, which can be a substantial burden on many systems. For another, when you are in a single process, you massively increase the pressure on the GC, which can lead to exacerbated GC-pauses (which are one of the single worst contributors to the IDE feeling slow or sluggish).

By moving out of proc, we can actually use less ram, have far less chance of hitting 32bit limits, and greatly improve perceived and actual latency of operations (as GCs can happen in one process without affecting the other).

We, and other teams have been using this approach with great success, and we expect to continue moving more in this direction with future updates and releases. For example, I'm doing work right now to get our indices for 'Navigate To', 'Find all References' and 'Add using' to be computed and queried outside of the main VS process. The results have been hugely successful, with the features actually running better than before, VS being even more responsive, and no excess memory usage (like we would get with 64bit).

There has been significant investigations of 64bit, and the actual empirical results of those investigations have driven our decisions. Thanks!

Hi CM, i'm Cyrus, a developer on the C#/VB IDE.

First: The benefit of this approach is that people can now use this sort of feature down-level. i.e. you can interoperate with this code even if you're on a previous version of C# or VB. Also, it means that the libraries can be rev'ed independently of compiler and IDE releases. There's a lot of value in having this sort of thing. And in the past people would rightfully complain about the lockstep nature of wanting to adopt a language feature, but having to switch over an entire toolchain to do so.

Second: We actually do have a feature to help you out here. It's available in C# in RTM and will be in VB in the next update. If you enable: Tools | Options | Text Editor | (C#/VB) | Advanced | 'Suggest usings for types in NuGet packages'

then we'll offer to add the NuGet package for this for you when you use a tuple.

We'd like to eventually make this option on by default. However, there is a memory cost to it, and we'll need to win back that memory usage in some way so that we can abide by our commitment to VS using less memory and being more lightweight by default than previous versions.

Hey DMarlow, could you clarify your question? A C# 7.0 program should run on pretty much any version of .Net after 2.0. Similar to C# 2.0-6.0.

The only thing we ever really adopted in C# that needed a new runtime version was Generics.

Hi CM2187. Can you file these bugs over at https://github.com/dotnet/roslyn We can take a look and hopefully get fixes out for you soon!

Hi Eitland!

I'm a dev on the C#/VB IDE experience (and i've written and maintain many of the Refactorings for those languages). C# and VB do support refactorings like 'Extract Method' and 'Move to Separate File'.

We've also exposed a full analysis and code manipulation API through 'Roslyn' so that community members can contribute even more refactorings through extensions.

One reason this may not have been clear is that previously we didn't strongly indicate to you that a refactoring was available. i.e. when you selected some code to extract a method, you would then have to use ctrl-dot to get the list of things you could do. Now, in VS2017 we pop up our 'Lightbulb' whenever refactorings are available. This helps make the refactorings much more discoverable and we've seen a very large uptick in people invoking them now that it's much clearer that they're available.

If you use VS2017 and find issues with our fixes/refactorings, or you would like us to add more, please file feedback at https://github.com/dotnet/roslyn Thanks!