Live data from Hacker News

Phil Haack quit Microsoft for GitHub

haacked.com

111–120 of 127 posts

Re: Phil Haack quit Microsoft for GitHub

#111
post #4

Earlier quoted context omitted.

It could be a net gain for Microsoft if the Windows developer community begins to embrace github. As long as the most talented in the community don't leave the Windows platform, it could lead to a more vibrant and productive Windows developer community.

Unfortunately, its been my experience that the Windows developer community rarely embraces anything outside of Microsoft. I hope your right though.

I've been using git & git-svn for all my c# projects and for committing to Lucene.Net. The msys version of git has come a long ways. I also prefer using github when possible. Some of us do branch out and embrace outside Microsoft technologies.

Its possible to sway the windows developer community to branch out and hopefully more people in the community will take initiative to sway others to do so.

Re: Phil Haack quit Microsoft for GitHub

#112

For anyone curious about any background on Phil Haack. Here are his notable accomplishments. - MS Lead on ASP.net MVC framework vers. 1 through 3 (current) - Lead on the NuGet package manager framework for Visual Studio - This Developer's Life Podcast with Scott Hanselman

I think I owe this man some kind of expensive liquor for MVC--especially MVC3. I truly loathed ASP.NET projects until MVC3. Some will argue that people use it wrong and/or the traditional Web Forms have their advantages, but I can't really think of many situations where I'd rather do it the old way.

One situation, when the CMS you are working with doesn't support MVC yet

Re: Phil Haack quit Microsoft for GitHub

#113

Earlier quoted context omitted.

git GUIs on windows are all pretty weak, but the git command line and git bash work perfectly well. my experience with git GUIs in general (regardless of the OS) is that you should just give up and use the CLI.

Powershell + msysgit work just fine. It puzzles me why people still keep referring to ye olde command prompt as "the windows command line" when Powershell has actually been around for years now and (while significantly different to bash) is extremely capable. My only complaint really is the lack of dynamic resizing without first consulting the options box.

Use Powershell ISE for dynamic resizing and other niceties.

Re: Phil Haack quit Microsoft for GitHub

#115
post #105

Earlier quoted context omitted.

I've been a staunch .Net defender for a long time, but have almost entirely thrown in the towel at this point. MVC is awesome, C# is awesome, F# is awesome... but, unfortunately Mono just doesn't cut it (Boehm GC? Really? s-gen is a nightmare too, before you counter with that) and Windows isn't a realistic option for a lot of people.

Can you explain what your concerns are with Mono? I haven't used it but as .NET developer hoping to deploy some apps on Mono to cut costs I'd like to understand your criticism better. Are your concerns regarding performance, and within which area? Is it poor memory management and what consequences do you have in mind?

We went guns-blazing from .Net on physical Windows servers to Linux/Mono/EC2. Mono performance is okay -- we still run a lot of C# utility stuff on Linux with it, no problem (build on windows, push to s3, servers self-deploy).

Forget about web stuff though. Mono fastcgi is not production ready (lots of little things, the interplay of nginx and Mono's fastcgi server 'lost' some routes, particularly scriptmethods).

Mod_mono is better... until you start getting OutOfMemoryExceptions. My understanding of the problem is that the Boehm GC is non-compacting, and thus, unless you (somehow) craft your application memory use patterns perfectly, will run out of memory if you churn through enough allocations.

From the mono ASP.NET FAQ:

Why does the memory consumed by the Mono process keep growing?

Mono currently uses a conservative, non-moving, non-compacting garbage collector. This means that the heap is not compacted when memory is released. This means that applications can produce memory allocation patterns that will effectively make the process grow, just like C, C++, Perl, Python applications would.

It is hence important to not get into patterns that would create these holes, for example such a hole could be created if you create a block of size SIZE, release it, and then create two blocks of size SIZE/2+1.

ASP.NET in Mono is particularly vulnerable to this kind of memory problems because it is easy for developers to define APIs that transfer large blobs of data like entire image files, these would allocate a lot of memory that can easily be fragmented.

A simple solution is to try to write your software in a way that large data blocks are not allocated, but instead your application handles them in blocks (like writing a "copy" command).

So the new GC, S-Gen is available, but for us at least, ~6 months ago it was really buggy. Some of our code would inexplicably cause mono crashes in the allocator. We couldn't run our apps with it, at all.

So ultimately we were left with restarting our webserver process every 30 minutes or so, or we could switch back to Windows web servers. Mono was decently performant, but going back to Windows we had a slight but noticable performance increase.

Don't get me wrong, Mono is awesome for a lot of things, and it kicks fuckin' ass to run my C# on Linux. But the ASP.NET side of things is just not mature enough. It's possible I'm just a bad programmer and if I'd taken the time to re-architect our allocation patterns to play nice with Boehm this story would have a happier ending, but alas :)

P.S. None of this stuff is fresh in my mind right now, so shoot me an email you have more questions or run into any specific situations or whatnot.

Re: Phil Haack quit Microsoft for GitHub

#116
post #105

Earlier quoted context omitted.

Can you explain what your concerns are with Mono? I haven't used it but as .NET developer hoping to deploy some apps on Mono to cut costs I'd like to understand your criticism better. Are your concerns regarding performance, and within which area? Is it poor memory management and what consequences do you have in mind?

We went guns-blazing from .Net on physical Windows servers to Linux/Mono/EC2. Mono performance is okay -- we still run a lot of C# utility stuff on Linux with it, no problem (build on windows, push to s3, servers self-deploy). Forget about web stuff though. Mono fastcgi is not production ready (lots of little things, the interplay of nginx and Mono's fastcgi server 'lost' some routes, particularly scriptmethods). Mod…

Very interesting, thanks.

I would want to deploy ASP.NET MVC3-based web applications so restarting the web server sounds like it'd be my only option (I'm not going to waste my time re-architecting things if it's eventually likely to run out of memory anyway).

Then again, I haven't tackled switching away from MSSQL (aside from learning to use a new DBMS, I'm a fan of stored procs too so I'd have to learn a new SQL dialect), either. Since my time is probably worth more than Windows licenses, it looks like sticking to Windows is the logical choice for now.

Thanks for the offer to pick your brain... I may take you up on it some time :)

Re: Phil Haack quit Microsoft for GitHub

#117
post #98

I really hope this leads to better Git tools for Windows developers. I've attempted to host several C# projects on GitHub in the past, but I always end up giving up and using either CodePlex or BitBucket because it's so much easier to get up and running with HG and SVN. Edit: Git tools, not GitHub tools.

Try TortoiseGit. It's like TortoiseSVN, but for Git.

Yes, but you still have to install MSysGit or whatever, which is a ridiculously huge download just to do version control requests. Plus, running the commands to generate public and private keys and all that junk is super counter-intuitive, and the default steps recommended on GitHub won't work on my work machine, as Cygwin can't write to the location it wants to create the key files, and once I got to that point, I just decided to use HG.

Re: Phil Haack quit Microsoft for GitHub

#118
post #98

Earlier quoted context omitted.

Try TortoiseGit. It's like TortoiseSVN, but for Git.

Yes, but you still have to install MSysGit or whatever, which is a ridiculously huge download just to do version control requests. Plus, running the commands to generate public and private keys and all that junk is super counter-intuitive, and the default steps recommended on GitHub won't work on my work machine, as Cygwin can't write to the location it wants to create the key files, and once I got to that point, I j…

msysgit is like 18mb download, you sure you didn't download the full source tree?

You don't need to use SSH either, Github (and bitbucket) supports https.

Re: Phil Haack quit Microsoft for GitHub

#119
post #83

Earlier quoted context omitted.

git GUIs on windows are all pretty weak, but the git command line and git bash work perfectly well. my experience with git GUIs in general (regardless of the OS) is that you should just give up and use the CLI.

Cool, great. Except that the Windows command line sucks and bash is uncomfortable to the point of unusability on Windows. I will use a shell (not bash) on Unix platforms where it is properly integrated and meshes with the rest of my workflow; this is not Windows, and attempting to attach it to Windows with baling wire does not work for me. My experience with source control systems--you know, including ones that aren'…

I use M-x eshell in Windows to get a somewhat comfy command line.

Re: Phil Haack quit Microsoft for GitHub

#120
post #102

Earlier quoted context omitted.

Seriously, it's easy to work with and doesn't get in my way. The fact that it may take a few more ms to do some things that probably aren't my bottleneck doesn't matter.

A few more ms != The slowest ORM, that's a factor of times slower. Unless you've got a free ticket onboard the MSFacts Train.

...free ticket onboard the MSFacts Train

I didn't realize I was having a discussion on Slashdot. My mistake.

Post reply on HN