Hacker News new | ask | show | jobs
by ghuntley 3711 days ago
It has been super exciting watching this all unfold over the last year, for those wondering where to get started in the new world of .NET open source - start here:

.NET CLR Managed Runtime - https://gitter.im/dotnet/coreclr

.NET Framework - https://gitter.im/dotnet/corefx

.NET Compiler as a Service ("Roslyn") - https://gitter.im/dotnet/roslyn

.NET Orleans Actor Framework - https://gitter.im/dotnet/orleans

Mono Framework - https://gitter.im/mono/mono

Xamarin iOS, Watch, Mac Bindings and Framework - https://gitter.im/xamarin/xamarin-macios

Xamarin Android Bindings and Framework - https://gitter.im/xamarin/xamarin-android

Everything is licensed under the MIT license w/patent pledges.

5 comments

Somewhat echoing what spriggan3 said, it seems odd that you suggest going straight to chat to learn about a piece of software rather than trying to find answers to your questions before bothering other people. To me (and this may be a function of where I'm from), it seems very rude to ask for help with something when you don't absolutely need said help (RTFM Noob!).

It's entirely possible you meant your comment for people who already have experience with the source in question, in which case I've misunderstood you.

Let's be clear, this isn't left-pad we are talking about - these are MASSIVE projects which are in some cases 16+ years old. Personally, I find the fastest way to get up to speed is on projects of this size is to usually jump into IRC, find a mentor and start sending in documentation patches. Here the engineers for the runtime, framework, compiler teams are hanging out in Gitter and engaging with the community out in the open instead of being hidden behind closed doors. Why would you ignore an opportunity like that? They are there soliciting the advice from the community and if the there is no uptake/reciprocal energy then that's a problem. I agree on RTFM but at this stage, there is minimal documentation for the majority of these projects and that internal domain knowledge needs to be dispersed into the community. Code only tells you about the implementation, it does not tell you about the why and information about trade-offs which were made.

http://dirkriehle.com/publications/2014-2/the-five-stages-of...

So I followed the gitter link to Orleans. I see a bunch of people talking. I'm not going to write "hey so what's this all about" so they can link me to the readme.

I went to the repo. The "homepage" includes the readme, which includes enough detail and code examples that I'm all set as far as knowing what Orlean's is "about".

This is how I learned Haskell. I literally went to #haskell on freenode and asked "hey so what's this all about", and many veterans of the community helped me get my feet wet.

I'm not sure what kind of toxic communities and work environments you are apart of, but if a newbie to the community can't ask questions, that's not a community that will survive or flourish in the long run.

Whilst I would never be rude to a newbie, isn't it reasonable that they at least read the FAQ, README or an I tried before asking such basic questions?
Sure. But ask in gitter first. You'll receive an answer suggesting you go read the README.md as it covers this info.
> I'm not sure what kind of toxic communities and work environments you are apart of, but if a newbie to the community can't ask questions, that's not a community that will survive or flourish in the long run.

Our definitions of toxic obviously differ a bit. I wouldn't flame anyone but (in a non paid setting of course, paying customers have the right to be wrong) I would tell them (politely) that we were there to help them when stuck, not to pull them up to speed.

Before reading this I wouldn't have believed anybody would seriously suggest that.

As others have pointed out going straight to the chat without even trying to read up on the docs first comes off as extremely entitled and lazy.

I'm maybe to hesitant, I wont bother anyone before I've read the relevant docs twice, possibly also looked quickly into the source.

I think a lot of people misunderstood my comment. I obviously understand that there are basic questions that can be answered by documentation.

But my point was that for any community to survive, it should be welcoming to newbies and have an environment where people shouldn't be afraid to ask questions, even if they are "dumb" by some arbitrary metric. It's also a good way to convince someone of using your particular framework, programming language, etc.

A newbie may ask why should I use X, and if experienced veterans of the community give set Y reasons to use it, I feel that's way more convincing than "RTFM scrub". It's way less elitist too.

How do you start documenting software that you don't know well? That seems like a very good way for bad documentation to get out, damaging the project.

Perhaps this is my impostor syndrome talking, but I for one would be hesitant to tempt the wrath of the Great Unseen Masters that make open source software with potentially inane questions.

> That seems like a very good way for bad documentation to get out, damaging the project.

Read the code, try your best to understand it, and then get the documentation reviewed by someone who does know the software well. This works for code, too. Bonus points: Explicitly enlist feedback ("Anything I'm missing here? Any edge cases I forgot to note? Is my understanding of this correct?")

> I for one would be hesitant to tempt the wrath of the Great Unseen Masters that make open source software with potentially inane questions.

http://www.catb.org/esr/faqs/smart-questions.html

But if you're making an effort to contribute, that already counts for a lot. There might be some gruff redirection towards more effective means of contributing, if you're being a significant time sink and not helping that much, but hopefully that's a win/win in the end.

Overtime, common repetitive questions will surface in conversation. Identify these patterns, write up FAQ/documentation and submit them via the pull-request process. The Great Unseen Masters will typically be grateful and respond with dumping their brain or corrections as they would normally do so in a code review. Eventually, over time, this will build up into something they can point newbies towards to RTFM so the community does not burn out answering the same questions over and over.
I think the idea is that FAQ/documentation is normally easily accessible from the repo's page, but not necessarily as obvious to find inside of gitter. I have to confess to having read all your responses but still find your linking to gitter instead of the actual repos to be bizarre.
If there is a FAQ it probably points to something that needs to be fixed or streamlined.
I have to say I agree. My only question in the chat would be "where do I find the documentation outside of this chat?"
You find a mentor even before knowing what the project does? Weird.
Why do you link to gitter when you should actually like to the repos instead ?
Depends on how you learn. Some learn by being around others, social interaction, asking questions and absorbing knowledge. It's clear you fall into the latter category which likes to learn by diving right into the code, so here it is:

.NET CLR Managed Runtime - https://github.com/dotnet/coreclr

.NET Framework - https://github.com/dotnet/corefx

.NET Compiler as a Service ("Roslyn") - https://github.com/dotnet/roslyn

.NET Orleans Actor Framework - https://github.com/dotnet/orleans

Mono Framework - https://github.com/mono/mono

Xamarin iOS, Watch, Mac Bindings and Framework - https://github.com/xamarin/xamarin-macios

Xamarin Android Bindings and Framework - https://github.com/xamarin/xamarin-android

Usually what I look for is a description of the project. I don't know what an "Orleans Actor Framework" is. The GitHub link gives me a README with a description and links to examples. The Gitter link is a bunch of people who already know about the project talking about details of it, which is harder to learn from I think. (Right now there are people comparing it with "SF". Not sure what that is.)

If there were something like Gitter that showed README.md and the chat room and not the code, then yeah, that's probably a better home page.

> Some learn by being around others, social interaction, asking questions and absorbing knowledge. It's clear you fall into the latter category which likes to learn by diving right into the code, so here it is

Props for how you dealt with negative feedback in this thread, and this positive re-frame.

Certainly you'd want to peruse the README before asking questions in a chat?
You seem to be dodging the question. The question is why -you- are linking to gitter.
He answered it, he linked to gitter because he assumed people wanted a social link instead.

He's not dodging the question at all, he answered it directly. He obviously likes gitter and chatting with others.

He's obviously a shill for big chatroom
Presumably, they prefer to learn by talking to people rather than browsing repos.

The .NET community was, until recently, decidedly not-open-source, so the learning workflow of "open the repo, read the readme, browse the code" might be a new thing for them.

Losen up, linking to something may be subjective. If it's not correct, HN mods can change the URL ;)

Perhaps it's not a bad idea for widening the community ( linking to gitter). I'm actually wondering if they ever used jabber, a not-well-known community for chatting about .net

I don't see that response as dodging anything. He did answer the question - he think that chatting is a decent way for newbies to learn.

You or I may not fully agree, but this is subjective. And it's an answer, even if it might not satisfy you!

> Why do you link to gitter when you should actually like to the repos instead ?

Before I clicked the link I imagined it to be some sort of annotated source code thing. (imagine the inline code with yellow "sticky notes" applied)

Turns out it's just an IRC type chat client. Still interesting.

I was _just_ about to type this exact string before I read yours. Linking to Gitter is _wrong_ IMO.
So, what's the story if I want to build a C# application that runs on Windows, OS X, and Linux? Do I use "regular" .NET for Windows and Mono for OS X and Linux? Or will everything eventually be unified into one common platform?
It can be complicated, but if you want to see an example, you can look at MonoGame samples [1]

The simple platformer has one source, but you should be able to compile it with Mono on Linux/OSX/Win or with Visual studio after you do the setup.

With Xamarin in the mix, your build targets can include Android and iOS.

Most of the time when I built with mono on linux, I was able to run the binary on windows, but I was creating smallish projects so far, so I don't know how well that works for larger projects.

But with libraries, there are often built in such way, that you have shared interface, that will be usable no matter the target and during compilation the correct platform version would be linked, but my memory is kind-of hazy on the details.

[1] https://github.com/MonoGame/MonoGame.Samples/tree/develop/Pl...

Basically write in whatever is comfortable, they both run the same format binaries. Some .Net features are not available in Mono (yet). Other than that, the two seem fairly interchangeable
Roslyn is cool, but there doesn't seem to be a standard way to tell Visual Studio to use a custom/roslyn C# compiler rather than the framework one. That kind of limits its usefulness.
Yes! We need more frameworks!

And links that contains no source code! A chat room with a broken image!

http://imgur.com/RF61z6Y