151–160 of 188 posts
Earlier quoted context omitted.
Relative to what? Assembly?
C/C++. Java. Python. JavaScript.
It took me about 60 seconds on a new EC2 ubuntu instance
I mean, top-level programs are nice, I guess? IMO it's more of a means of attracting non-.NET developers into the fold. I work in a .NET shop and we probably won't use this in our production code. The benefit of target-typed expressions IMO is that it changes property syntax from: public List Foos = new List (); to simply: public List Foos = new(); It may seem subtle, but if you write C# you see this pattern constant…
Earlier quoted context omitted.
> top level is mostly going to be nice when teaching new programmers. You can just get on with hello world Yeah it seems like kind of a weird thing? “Here’s marginally less boilerplate once , if someone is going to learn to use the language, they may as well learn how it actually works instead of hiding stuff that they’ll soon see anyways...
.NET was designed from the get-go for creating large programs. There is of course some overhead/boilerplate to this. So you could not do a Write("Hello world"); without wrapping it in a method. In a class. In a namespace. In an assembly. After all, why optimise the language for "Hello world" ? How important is that case? language designers rightly decided that supporting large programs was more important. In the code…
Earlier quoted context omitted.
I can't see var going anywhere, many times you aren't directly creating a new object, but getting a generated object from something ( like linq) which tends to have more complicated type signatures.
I hate hate hate var. Sure, in your own IDE, and reading the code you just wrote, no problem. But when doing code reviews and jumping all over, I want to see the type right there. Nothing more frustrating than reviewing a PR with var's all over. This isn't even up for debate anymore... No more var! It is frustrating to still see var as the recommended way by Microsoft... You can even put in a rule to format the docum…
I mean, top-level programs are nice, I guess? IMO it's more of a means of attracting non-.NET developers into the fold. I work in a .NET shop and we probably won't use this in our production code. The benefit of target-typed expressions IMO is that it changes property syntax from: public List Foos = new List (); to simply: public List Foos = new(); It may seem subtle, but if you write C# you see this pattern constant…
That’s not that compelling on its own given that you could already use var to avoid repeating the declaration.
Earlier quoted context omitted.
Agreed that `var` isn't going anywhere, but this feature's best use case is with complex generics/enumerables and things like anonymous tuple types. For example: // old: var x = new List > { new KeyValuePair ("a", 1), new KeyValuePair ("b", 2) }; // new var x = new List > { new("a", 1), new("b", 2) };
Wow, when I (only a C# dabbler) read about this feature in the article I thought it sounded incredibly silly, but this really sells it. Was there really no better way to create tuples before?
Here are some other options for code like the grandparent post. I tend to either live with the boilerplate or use a local function.
1. Use a collection initializer extension method (https://news.ycombinator.com/item?id=26641997).
2. Define a local helper function.
KeyValuePair KeyValue(string key, int value)
{
return new KeyValuePair(key, value);
}
// new w/local function
var x = new List>
{
KeyValue("a", 1),
KeyValue("b", 2)
};
4. Use generics to infer the argument types à la Tuple.Create. This technique can be helpful for using anonymous types with collections.
//KeyValuePair.cs
internal static class KeyValuePair
{
public static KeyValuePair Create(TKey key, TValue value)
{
return new KeyValuePair(key, value);
}
}
// new w/helper class
var x = new List>
{
KeyValuePair.Create("a", 1),
KeyValuePair.Create("b", 2)
};Earlier quoted context omitted.
How so? .NET is 2-4x faster than Scala in benchmarks ( https://www.techempower.com/benchmarks/#section=data-r20&hw=... ). Do you just prefer the syntax and language features?
I like the expressibility, its easy to improve performance in the compiler later.
Earlier quoted context omitted.
> MS really made a grave mistake by coupling the evolution of the C# language to the .NET version. It’s not directly coupled, but each version of C# has a minimum .NET version it can support, due to the requirements of the features in the language itself (like LInQ in the past). And MS has been very up front about .NET framework being legacy and not getting any future upgrades for years now. Keeping every new C# feat…
> Keeping every new C# feature compatible with every obsolete .NET version obviously has a big technical cost Strawman there. The problem is not "every obsolete .NET version", the problem is .net in reality have two incompatible platforms at this point, but newer C# versions are only supported on one of them. Going from framework to core will require (risky, expensive) rewrites, which means lots of real-world code wi…
But that’s fairly consistent right? An old platform not getting updates and a new platform getting updates?
Why would you expect the SDK of the officially deprecated platform to get updates with the latest compilers and technologies, but at the same time in every other way remain stagnant?
Microsoft has been very clear that what you have will keep working, but you won’t get any new toys.
If you want those, you have to put in the effort to upgrade your projects, and in worst case rewrite the portions you can’t.
> So for the foreseeable future, .net will have these two platforms in parallel.
Yeah. The old one not getting updated, used by those who won’t put in the effort to update their tools.
And the new one where all the nice things are happening, which really should act as a nice carrot, not a source of bitterness.
> Microsoft have forgotten how important developer enthusiasm is for the success of a platform.
99% of the old ASP.NET stack was terrible and unpleasant to work with.
The new stuff is nice (enthusiastic!) to work with exactly because they decided to not carry all that stuff forwards.
The new APIs was a nice fresh start for the current kind of apps one writes today.
I mean, top-level programs are nice, I guess? IMO it's more of a means of attracting non-.NET developers into the fold. I work in a .NET shop and we probably won't use this in our production code. The benefit of target-typed expressions IMO is that it changes property syntax from: public List Foos = new List (); to simply: public List Foos = new(); It may seem subtle, but if you write C# you see this pattern constant…