Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

First C# 7 Design Meeting Notes

github.com

Post reply on HN
Print view View original

41–50 of 82 posts

Re: First C# 7 Design Meeting Notes

#41

Post by MichaelGG »

coldtea wrote: post #30
MichaelGG wrote: post #16

Earlier quoted context omitted.

That's not different than some open source projects and has no bearing on it being open source. Some project leads call attempted contributors idiots and refuse to even fix security bugs. Some have differing visions for their project. Which projects run by a strict vote, and how would you even decide who gets to vote? Most likely you'd elect leaders that will vote in the benefit of the project... Which is what MS has…

> That's not different than some open source projects and has no bearing on it being open source. I didn't say it's different, or that it's not open source for that. I asked because the parent said: "If you want to contribute actual code and have it actually incorporated into the language, then all you need to do is follow the contribution guidelines here"

And the parent is right .. Right? That's all you gotta do. If your contribution is accepted, you're all set. Same as every other project I've seen.

Anyways, maybe I misunderstood the that, so my apologies if I came off rude.

Re: First C# 7 Design Meeting Notes

#42

Post by MichaelGG »

pjmlp wrote: post #33
MichaelGG wrote: post #25

Earlier quoted context omitted.

In general, overall tooling is not at the same level. Code gen is focused on a C#-like model, designers aren't there, debugging isn't the same (immediate window, for instance). Last i checked (which was a while ago), VS testing didn't work with F#. Even Intellisense is not as complete. I'm happy with F#, very happy indeed. But it lacks the resources that C# gets thrown at it. And it suffers from MS not having the hon…

> Instead, we get lines like "F# is for scientific computing" or similar spin. You will never sell the typical VB.NET/C# enterprise .NET developer into F#. I find very commendable what Microsot has done so far, even if it feels too little. It rises the visibility of the language, specially to managers and drives CLR design decisions that help FP implementations, like TCO. Let me know when Oracle gives at very least t…

F# doesn't (or didn't) use tailcall in CLR in general, because it was too slow. It only does so as a last resort. Or did that all change? Same with stuff like tuples. We get tons of heap allocations because the CLR did poorly with structs. F# had to even go back on their design because of this, and match the BCL tuple type.

MS doesn't need to sell the typical enterprise dev. They just need to not sour-coat things and be honest and complete in their statements. It'd also be nice if MS viewed shipping actual language independent code, instead of stuff that takes dependencies on C# compiler details.

MS gained a huge amount from the F# folks by getting CLR generics from them - that's one major benefit over the JVM. Just on that alone perhaps they owe them that (maybe, I've little clue of internal politics, except that there is some resentment towards F#, and at least a bit of censorship on publishing things that make C# look poor).

Let me know when Microsoft starts shipping Rust-level features, so we can deal with memory safely and reduce bugs without losing perf.

Re: First C# 7 Design Meeting Notes

#43

Post by phatboyslim »

MichaelGG wrote: post #2

Good start, finally adding records, patterns, tuples, non null, would be a good first step to making C# not feel so heavyweight compared to F#. If the F# team ever gets enough resources to complete with C#'s VS features, perhaps we'd get some serious adoption. As is, F# comes across second class both in tooling and MS marketing - that's not really competing fairly ;) But without making things expressions, it's still…

I believe c# has had tuple support since .net framework v4.

Re: First C# 7 Design Meeting Notes

#44

Post by MichaelGG »

jarcane wrote: post #36
MichaelGG wrote: post #25

Earlier quoted context omitted.

In general, overall tooling is not at the same level. Code gen is focused on a C#-like model, designers aren't there, debugging isn't the same (immediate window, for instance). Last i checked (which was a while ago), VS testing didn't work with F#. Even Intellisense is not as complete. I'm happy with F#, very happy indeed. But it lacks the resources that C# gets thrown at it. And it suffers from MS not having the hon…

This is something that does rub my the wrong way a bit as well. F# is a fantastic language, easily my favorite non-Lisp FP language, and possibly period, but it was very clearly second-class in the field of actually building full apps with it. MS just flat does not seem to believe that anyone would want to build full apps with F#, so support for doing so is a bit of a wild frontier. Hopefully with F# in open source h…

It's a self fulfilling prophecy. F# is weak at designing full stack apps because it lacks tooling because it is weak at designing full stack apps.

Even now, doing MVC websites is far more difficult out of the box if I code F#. MS still lacks JS backends, so we need third party compilers for that model... Maybe because they don't want to upset or look less than 1000% behind typescript.

I will say though otherwise I'm happy. In using F# to run my server apps with smooth pinvoke into my Rust code, which is expressive enough to offload a lot of logic. And with VS soon to be free, and Mono working fine, MS might not get any money from it. (Why deploy any sort of scale on Windows when it's line $35/core/month?) So, in that sense it's selfless and I'm quite grateful.

Re: First C# 7 Design Meeting Notes

#46

Post by MichaelGG »

seanmcdirmid wrote: post #22
rjbwork wrote: post #15

Earlier quoted context omitted.

If you mean what I think you mean by "manually currying", it's likely because behind the scenes, there is a proxy class created for most (all?) lambdas that contains everything it needs to execute, including any scope variables maintained. So there's some extra overhead there, though not as much as you'd expect since everything, even value types, are pulled in by reference in the context of lambdas.

I did not know that! That explains a lot of the memory performance problems I was having (structs being moved to the heap...icky); lambdas are sneaky little turds. I solved the problem by avoiding lambdas altogether in code where performance is a concern, using delegates instead and ensuring all arguments are passed in rather than closed on (so structs would remain structs, GC pressure is avoided).

Imagine if the CLR allowed optional borrowing annotations ala Rust. Then safe non leaking functions would no longer need their callers to use the heap. Even APIs like String.Split could be actually efficient. In fact you might even get away with zero alloc for it, for some small cases.

Re: First C# 7 Design Meeting Notes

#47

Post by seanmcdirmid »

MichaelGG wrote: post #46
seanmcdirmid wrote: post #22

Earlier quoted context omitted.

I did not know that! That explains a lot of the memory performance problems I was having (structs being moved to the heap...icky); lambdas are sneaky little turds. I solved the problem by avoiding lambdas altogether in code where performance is a concern, using delegates instead and ensuring all arguments are passed in rather than closed on (so structs would remain structs, GC pressure is avoided).

Imagine if the CLR allowed optional borrowing annotations ala Rust. Then safe non leaking functions would no longer need their callers to use the heap. Even APIs like String.Split could be actually efficient. In fact you might even get away with zero alloc for it, for some small cases.

Lambdas kind of mess that up, since they are indirect and dynamic by their nature and basically require GC to work. Heck, GC was originally invented to support Lisp.

There was, maybe is, some work being done on systems C#, not sure about the status though.

Re: First C# 7 Design Meeting Notes

#48

Post by pjmlp »

MichaelGG wrote: post #42
pjmlp wrote: post #33

Earlier quoted context omitted.

> Instead, we get lines like "F# is for scientific computing" or similar spin. You will never sell the typical VB.NET/C# enterprise .NET developer into F#. I find very commendable what Microsot has done so far, even if it feels too little. It rises the visibility of the language, specially to managers and drives CLR design decisions that help FP implementations, like TCO. Let me know when Oracle gives at very least t…

F# doesn't (or didn't) use tailcall in CLR in general, because it was too slow. It only does so as a last resort. Or did that all change? Same with stuff like tuples. We get tons of heap allocations because the CLR did poorly with structs. F# had to even go back on their design because of this, and match the BCL tuple type. MS doesn't need to sell the typical enterprise dev. They just need to not sour-coat things and…

> Let me know when Microsoft starts shipping Rust-level features, so we can deal with memory safely and reduce bugs without losing perf.

Is Rust 1.0 out yet?

They are on Microsoft research.

While the world still isn't ready for the likes of Singularity and IronClad, Spec# and Dafny, at least part of the technology has landed on Windows Phone 8 and .NET Native compilers.

Re: First C# 7 Design Meeting Notes

#49

Post by mvitorino »

phatboyslim wrote: post #43
MichaelGG wrote: post #2

Good start, finally adding records, patterns, tuples, non null, would be a good first step to making C# not feel so heavyweight compared to F#. If the F# team ever gets enough resources to complete with C#'s VS features, perhaps we'd get some serious adoption. As is, F# comes across second class both in tooling and MS marketing - that's not really competing fairly ;) But without making things expressions, it's still…

I believe c# has had tuple support since .net framework v4.

I believe tuple support in v4 is a simple set of classes. There is no language construct specific for the use of tuples, which means it's just a library instead of a programming language feature.

Re: First C# 7 Design Meeting Notes

#50

Post by theflagbug »

Cakez0r wrote: post #12
Rapzid wrote: post #9

I would LOVE for C# to get language support for go style channels complete with select and friends. C# already has the fantastic Task stuff, and while they aren't as cheap as go's go-routines they work very well. Channels would just ice the cake so well. :D~~~ And while I'm at it. I did some testing recently and realized that manually currying in a for loop is faster than using function composition with delegates by…

You can already get a long way towards channels by using reactive extensions (E.G. http://pastebin.com/h1xteunX ) Some syntactic sugar a la await could be nice though.

Not sure if you're aware, but your Rx example has a few problems:

1.) In the StartSenders method, you're violating the Rx grammar by calling channel.OnNext concurrently. Wrap it on a lock statement.

2) In StartReceiver you're missing out messages the way you handle the channel. Replace the loop with a call to channel.Subscribe

Post reply on HN