Hacker News new | comments | show | ask | jobs | submit login
Building a Startup - Defending .NET (nashcoding.com)
84 points by tansey on Apr 10, 2011 | hide | past | web | favorite | 87 comments



.NET is great. It's fast, clean, and the framework libs are incredibly good. C#, IronPython, and F# are amazing.

I still haven't found an IDE that compares to VS in terms of productivity and usability.

Despite all the things going for it, it's decidely un-trendy and people hate on it. I'm guessing it's primarily because it's from Microsoft.

Software trends are silly.


It's true. .NET, and C# especially, is one of the few things Microsoft really got right. Anders H is a genius -- he showed it when he did Turbo Pascal, he showed it with Delphi, and he continues to show it with every new release of C#.

Did you know that C# has: lambdas, closures, optional duck typing, first-class functions, better generics than Java, and type inference that is sometimes spooky?

Really, the only flaw I see in C# (and clearly this is my own subjective opinion) is that I now believe dynamically (duck) typed languages are so much more empowering than strongly typed ones. To me, it seems you can get so much more done, faster, and you choose where to expend your energy to get "automated correctness". But even there, C# has the new "dynamic" keyword that allows for duck typing, so it is moving in the right direction.


"Did you know that C# has: lambdas, closures, optional duck typing, first-class functions, better generics than Java, and type inference that is sometimes spooky?"

I did know that, and these things heavily factor into why I default to C# for most projects these days! .NET 4 is awesome.

C# is an excellent language. It has all these great things, yet doesn't feel polluted or bloated at all. I absolutely love lambdas, closures, and generics. They help write concise and clear code. Generic support in C# and F# and the CLR itself is brilliant.

Writing event-driven, asynchronous IO code in .NET code is a breeze. It seems like the current programming trend around these parts is focused on "iterating fast" and having async IO. C# gives me both of these things, with the bonus of having the compiler catch most of my errors.

I disagree with the general notion that duck-typed languages are more empowering or let you iterate faster than strongly typed languages.

If you think that a language that is lazy (or worse, unspecific) about types lets you write code faster, I think that you have some fundamental problems with how you approach development.

The whole dynamic languages = faster code production is an unsettling school of thought, in my opinion.


"If you think that a language that is lazy (or worse, unspecific) about types lets you write code faster, I think that you have some fundamental problems with how you approach development.

The whole dynamic languages = faster code production is an unsettling school of thought, in my opinion."

Well, that's what I used to think too. The million dollar question is ... have you tried it?

I did a heavy Javascript project recently, and I was amazed at how much faster I could go from a vision of a complex solution to having that solution implemented.


Writing event-driven, asynchronous IO code in .NET code is a breeze.

It's about to get even breezier: http://msdn.microsoft.com/en-us/vstudio/gg316360


Oh, one other flaw -- C# isn't homoiconic. But every other language but you-know-what fails that one :)


Prolog is another that passes. The Pure language - interpreted but not compiled - should count. Compile time self modification is still there though. In terms of macros for code generation, syntactic extensibility, runtime+compile time reflection and staged computation without homoiconicity; Nemerle is one on .NET.

C# is one step closer with its upcoming compiler as a service. Available in mono now.


    .NET is great. It's fast, clean, and the 
    framework libs are incredibly good.
Having worked with .NET, I beg to differ -- .NET framework libs are a mess.

    C#, IronPython, and F# are amazing.
It's not the languages that keep people away from .NET -- to put it simply -- community, tools, price.

Microsoft does a good job at playing catch-up, but unfortunately (for them) when it comes to web development, innovation happens somewhere else.

And sure, Visual Studio compensates for a lot, but it's just an IDE, the least important part of the stack.


I am just curious. What .Net libraries do you find messed up?


I agree, C# is awesome developer experience in terms of the IDE, but the rest of .Net ecosystem has never really materialized.


Software stasis aka Java, seems to me more silly than software trends. I can't see any good reason reason to stay with Java when Scala exists.

I recently started using C#, VS and TFS after many years with Java and Python, SVN, and IntelliJ/Eclipse.

I can see why people prefer C# to Java, C# is better than Java.

TFS for version control I have more trouble liking. It seems to be inefficient across slow WAN's and is far below GIT etc. But if everyone is local and your needs are simple it can work.

Visual Studio for me (with Resharper installed) is slow, buggy and just dumb. In Eclipse or IntelliJ code updates during debugging worked ok, better if Zero Turnaround was installed, VS not so much. Navigating with IntelliJ was just better, with visual clues about how to get to implementations etc. And Visual Studio hangs for me regularly.

But worst of all clicking any of the Test buttons results in 15 seconds of waiting before I see a pass or fail. This just kills me.

I see a strong pro Microsoft bias in the .Net development community and I think this is a strong negative. It reminds me of the days before log4j beat Sun's util logging when inferior Sun technology won in the Java community.


When I switched from .net MVC to Rails after a few years with Microsoft, my biggest pain was from missing VS. Rock solid variable renaming, autocompletion and method look up saved so much time.


I use Eclipse a lot, as well as a sprinkling of other IDEs. I tend miss autocompletion too (support for generics and polymorphism? yes please) but the thing I tend to miss the most is the debugger. Nothing else even comes close.


Well, I don't agree about polymorphism (but that's a whole different conversation) :) I forgot about the integrated debugger though. I sure do miss variable inspection without littering code with puts.


I still haven't found an IDE that compares to VS in terms of productivity and usability.

The elephant in the room here is cost. I work in various flavors of Visual Studio every day, and it is a nice IDE, but if I was bootstrapping a company, I'm not sure I'd want to shell out the money for an MSDN subscription[1]. I get the impression from the post that the toolset was already in place (paid for).

[1] I haven't looked at subscription options recently, so perhaps there is a start-up friendly level these day?



IDE's are for _lusers_. Vim FTW! And Emacs is cool too. Vim can do more than any IDE (fantastic built by the community plugins). And imho one needs to be retarded if one uses something else than hjkl or C-n, C-p, to navigate within a text document.


As far as I can tell the author's reasons for deciding to use C# can be summed up as "I'm used to it from previous work, and some useful libraries related to my project are available."

Those are perfectly valid reasons, but they aren't really much use to anyone who doesn't share those circumstances, and don't really have anything to do with upsides and downsides of the language itself. That would have been far more relevant to us outsiders.

Also, "I'm buying a MBP" translates to "I'm serious about startups"? Who says image isn't everything? Besides, everyone knows serious hackers use IBM-era Thinkpads!


> Also, "I'm buying a MBP" translates to "I'm serious about startups"?

Well, that was tongue in cheek.

But really, just the opposite-- I'm saying that I'm a total tool who's caved in to the trendy peer pressure of the startup culture. That culture shuns .NET on principal and there's lots of pressure to never use it for a startup.

And if you don't believe there's peer pressure to use a MBP, try going to Red Rock or the Dojo with an Acer laptop. You can just feel people judging you. ;)


And if you don't believe there's peer pressure to use a MBP, try going to Red Rock or the Dojo with an Acer laptop. You can just feel people judging you.

And? Unless you're trying to sell them something, who gives a rats-ass what they think? :-)


Again, tongue in cheek. :)

Though I am really buying a MBP tomorrow. I'm doing it because I need a new laptop and I like the new MBP-- but you can be sure I'll have it setup to do Windows 7 in dual boot from day 1.


but you can be sure I'll have it setup to do Windows 7

Eeeeeewwwwwwwwwwwww..... boo, hiss. Windows?!??

Sorry, when you mentioned a PC based laptop, I assumed it would have been running Linux (or BSD or Plan9 or Minix or some other proper operating system.) :-)


So his point about people judging him was not way off the mark ;)


Not at all... my point isn't that people won't be judging him, my point is that it doesn't matter. And my previous response was intended to be thoroughly TIC as well, FWIW.


And if you don't believe there's peer pressure to use a MBP, try going to Red Rock or the Dojo with an Acer laptop. You can just feel people judging you.

Try going to something that's a bit more unixy and it's just the opposite: you can feel people judging you when you pull out your MBP. Pull out an iPad and you may be asked to leave :)


You'll be much better off if you're well-practiced in ignoring those people. I think choosing your tools solely out of trends and peer pressure would also send a message, but it wouldn't be a favorable one.


> try going to Red Rock or the Dojo with an Acer laptop. You can just feel people judging you.

I have gone to equivalent places/events with my Acer laptop, without anyone judging me. (It is running Ubuntu, mind).


I see some of the .net hate starting to seep into the corporate world as well. I work as a .net developer for a very large corporation and there is more and more talk of re-implementing production applications in Python. The perceived problem is poor code quality. It is an uphill battle to convince people that this problem is not going to be fixed by switching to Ruby if we continue to produce code by lowest bid.

I think there is a difference in .net developers and Ruby or Python developers. There is a much higher demand for .net developers so many people who had some aptitude for computers picked it up to get a job. Seems to me, people who went through the effort and sought out Ruby or Python take extra pride in the craft of programming. I would say there are just as many .net developers who care about the code they produce, but they are background noise in the sea of mediocre talents. The prospect of finding them in that sea is pretty daunting.


If both of those are true, then doesn't that mean a whole wave of sub-par Ruby and Python developers are coming our way in the next few years?


Yes, I'm pretty sure I will see the staffing firms send me back the same developers, but now they will be Ruby experts.

Maybe this is less about .net/other languages and more about what makes development so terrible in large corporations. But keep in mind most .net developers, of which I am one, are products or large corporate development .


I can't talk for Python, but from my limited experience the Ruby community started to get the submerged in a wave of sub-par developers when Obie Fernandez et al. started to promote the meme, that attending a Ruby/Rails related conference puts you in the top 5% bracket of software developers.


This is what pg called "The Python Paradox"

http://paulgraham.com/pypar.html


Existing expertise

If the goal is to get to a minimum viable product quickly (like most startups) then existing knowledge is a pretty good reason to go with a certain stack. He even mentions having the main algorithm already implemented in C# so at that point it's pretty much no contest. He can always go the route similar to StackExchange in using Linux & Open Source on utility servers (Caching/Load Balancing) and keeping the MS-centric App/Database server.


How far do you take it though? What if someone knows c+cgi? I forget the exact quote, but something along the lines of 30 years experience doesn't mean much if it's the same year 30 times.


> 30 years experience doesn't mean much if it's the same year 30 times.

Your quote is apt, but it cuts both ways. Using the same old tool indefinitely, even when newer tools can do the job better and much faster, might be foolish. On the other hand, learning to do the same task over and over again using different tools, each only a modest improvement on the last, might also be foolish.

In the case of your C+CGI example, I would agree that it makes sense to prefer any of the more modern "scripting" languages, which typically have both good library support for networking protocols and much more powerful integrated string handling than C.

On the other hand, there is little offered by any mainstream language ecosystem today that can't be achieved at least reasonably proficiently using tools from the .Net world as well (ignoring the obvious limitation of having to run on a .Net platform).


Everything in life is a trade-off. And the 30 x 1 years quote nicely illustrates why you should always strive to learn new things.

However, if you already know how to do something well in one particular stack, then you should just stick with that if the objective is to ship.

The operative word is of course that you know you can do it well in that stack. If you start thinking "there has to be a better way" then you should seriously look into alternative stacks or whether you are using your current one correctly.


That's an interesting dilemna. I'm a Java web developer, I know the platform / libraries / tools really well, and know how to get things done with it. I've dabbled with more powerful languages in my spare time, but I've been using Java 8+ hours a day for the last 3 years.

If I were to launch a startup, should I go with the "cool shiny powerful" language, or should I stay with the boring verbose language that I know well? Would the fun factor of using Clojure / Scala / Ruby / Python / Blub++ be worth it? Would the language "power" offset the time "lost" gaining experience with a new platform? What about hiring? Hackers love powerful languages.

So many tradeoffs.


> If I were to launch a startup, should I go with the "cool shiny powerful" language, or should I stay with the boring verbose language that I know well?

I think the danger with this decision is that we tend to get a "grass is always greener across the street" mentality. I have yet to find a programming language that has no serious warts.

Certainly different languages have different warts, and thus suit different jobs better. However, just because we haven't used a language enough to appreciate its warts, that does not mean we will not discover them to our cost at exactly the wrong moment in our new project.

Moreover, with newer or more recently popularised languages, there is sometimes a tendency for the community to bury its head in the sand. Some defenders might claim that we "just don't understand" if we identify a serious shortcoming. Sometimes the individual or group that defines/specifies a language will have a blind spot and make seemingly arbitrary decisions that we don't agree with. In contrast, with longer-established languages, the shortcomings tend to be well-known and acknowledged, and the emphasis in the community is often on sharing the most effective workarounds or alternative techniques.

Obviously these generalisations aren't necessarily universal. We find helpful people in otherwise intransigent communities and awkward people in otherwise helpful communities. Still, I have seen the pattern repeat over the years for many different languages as they evolve from the Newer And Better Thing to a mainstream tool and ultimately to an older tool that is superceded by the next newer and better thing.

When I'm choosing the tools for a project, I usually favour the middle of that spectrum over either extreme. Out-of-date and underpowered is bad, but tried-and-tested is good. YMMV.


Very good points.

In contrast, with longer-established languages, the shortcomings tend to be well-known and acknowledged, and the emphasis in the community is often on sharing the most effective workarounds or alternative techniques.

Exactly. A good example of this is dependency injection. In Java, it was hard to mock dependencies, like you would do in a dynamic language. This forced the Java community to look into dependency injection / interface programming, to make the code testable. Dependency injection then lead to better componentization / modularity (some could say that one shouldn't have to use dependency injection if one were using a "better" language, though ;) ).

I also like established languages, because there are also established best practices. You don't have to reinvent the wheel.

Certainly different languages have different warts, and thus suit different jobs better. However, just because we haven't used a language enough to appreciate its warts, that does not mean we will not discover them to our cost at exactly the wrong moment in our new project.

That's the reason why I'm leaning on using a JVM language. I know the platform and the tools, and I can always "fall back" to Java if needed (for performance critical code or whatever).

Maturity is important, but I don't want to miss out on the power and expressiveness of higher level languages ( http://www.paulgraham.com/avg.html ). Using powerful languages is also useful when hiring good hackers ( http://www.paulgraham.com/pypar.html ).


This is not actually an "either-or" question.

For a minimum viable product, you need to do the minimal amount of work, whatever that turns out to be for the startup you are building.

Is it something like DropBox? In that case, you need to write at least part of your product as a Win32 Shell Extension, and regardless of how well you know Java, it is MORE work doing that in Java than in C++

Is it the new GoogleDocs/ZohoOffice? In that case, about 90% of your work is in JavaScript or a language that compiles cleanly to JavaScript. This might be Java (by way of GWT), but probably isn't.

Is it a new "enterprise software system"? Java is probably a good choice, even if Java wasn't your strongest point.

And if it HAS to be java for some reason, there's Clojure, Jython, Mira, LinJ and a few others that let you switch slowly and incrementally, without having to decide or make a tradeoff.


Personally I would say do not make your first big project in a new language your startup, it'll take a lot longer. It's hard enough just getting the thing out the door without having to also deal with the pain of learning new paradigms, new dev tools, constantly having to look stuff up and wondering if you're doing something fundamentally wrong.

Force yourself to start writing other things with the language you want to use TODAY. I would start writing utility stuff in something else until you're comfortable with it.

It's also a little funny to see Python and Ruby described as more powerful that Java! I guess powerful is a mutable word, but personally I'd consider them less powerful but faster to develop in (for a dev at the same skill level in both languages).


It's hard enough just getting the thing out the door without having to also deal with the pain of learning new paradigms, new dev tools, constantly having to look stuff up and wondering if you're doing something fundamentally wrong.

Yes, but it's also more fun :) I think fun and passion are important for a startup. But I agree that one needs to strike the right balance, and pragmatism is good when you want to ship.

Force yourself to start writing other things with the language you want to use TODAY. I would start writing utility stuff in something else until you're comfortable with it.

I think that's indeed the best course of action. I've read about people who started using Groovy for unit testing at first. Another good example is my colleague who built a small customized issue tracker in Grails for the Java project they were working on.

"It's also a little funny to see Python and Ruby described as more powerful that Java! I guess powerful is a mutable word, but personally I'd consider them less powerful but faster to develop in (for a dev at the same skill level in both languages)." By "powerful", I didn't mean "performant". Due to the JVM, Java is faster than Python / Ruby. I used the word "powerful" in the same sense as Paul Graham did in his essay on Lisp ( http://www.paulgraham.com/avg.html ), that is, a higher level, more expressive language. With today's hardware, using a high-level, slower language is not a problem anymore: we now optimize for human time (development time) instead of machine time.


Have you done anything with Grails or Groovy yet? My experience is that it's probably the easiest transition for Java devs, because Groovy is something that can be interchanged in each file with "plain old Java".


I haven't mentioned Grails / Groovy, because it always seemed to me like some kind of a "hack" to improve Java with some nice syntactical sugar / DSLs / dynamic programming. Scala / Clojure seemed more interesting, and I focused on them.

I've only tried a small "create-your-blog-in-15-minutes" Grails tutorial, and it was actually quite effective. I haven't revisited it since then. Thinking about it, my Groovy avoidance is absurd, and I WILL look at it again with an open mind. I remember "dismissing" Groovy a while ago, after reading a few articles raving about Scala being the next JVM language. I think it was quite dumb of me actually.

A colleague of mine used Grails to build a small issue tracker for a client, and he loved it. The only drawback, according to him, were some of the plugins: when the default plugin configuration wasn't what he needed, it was sometimes hard to change it. Since they were open source, he simply forked them / hacked at the code / submitted patches to improve them. These drawbacks are expected, though, since the language is still young, and plugins will mature.

Spring Roo also looks interesting, for those who want to keep using Java. It's inspired by Rails / Grails, and uses code generation to speed up development: http://www.infoq.com/interviews/roo-ben-alex


I've been a bit annoyed at Roo - more precisely, Spring, because they seem to give Roo more love/attention than Grails.

Personally, yes, I think perhaps it was a bit 'dumb' of you to dismiss Groovy. ;) Yes, it's 'syntactical sugar', but having that in Java is great. You can say 'hack' or whatever, but it's still effective and bringing productivity and reduced boilerplate to otherwise plain-old Java.

Scala and Clojure - I've nothing against them, except that they do seem to split the attention on 'alternative JVM' languages. That dilution hurts the chances of any one platform taking hold as the 'next thing' in the Java world, and personally, right now, most of my eggs are in the GR8 world, for many reasons.

I do think Scala is different enough from traditional Java development that broad migration from existing Java developers won't happen, whereas Groovy is so potentially similar that there's little reason for an existing Java dev to have trouble adding Groovy as they learn it. It's not an 'all or nothing' proposition.

If you have any further interest in Groovy/Grails and have any questions, I'd be happy to help if I can - email me directly if you want.


That's interesting. I definitely need to check Groovy out. Plus, the lead developer is a fellow French, so there is one more reason to try it ;)

I agree with your views regarding Scala. It's a really interesting language with a ton of cool concepts, but I fear it might be "too powerful" for the "standard entreprise Java programmers". Java is good, because it is simple. With Scala, you use different paradigms, which might be harder to grasp. It's easier to shoot yourself in the foot / write complicated code. But I guess that's the price to pay for using a high level programming language?

Here is Martin Odersky's take on this debate: http://lamp.epfl.ch/~odersky/blogs/isscalacomplex.html

Gosu also looks interesting as a Groovy contender, though you won't like it, since it dilutes the alternative JVM languages even more ;) http://gosu-lang.org/ http://news.ycombinator.com/item?id=1881924


We've had our share of surprised faces when we told people our company is based on .Net as well. There were a lot of reasons for us to use the Microsoft stack. One of them was also existing expertise. My CoFounder and I previously worked as C# developers for years before working on IActionable.com full-time. And yes, Visual Studio is that awesome.

"AppHarbor - It's Heroku for .NET. You simply can't beat it."

I agree with most things in the article except for this. Its definitely my personal opinion, but I don't think AppHarbor is quite 'there' yet for a lot of companies. At least it wasn't for our company's specific needs. The .Net community is very unique and has very different expectations from other service providers. We typically eat what Microsoft feeds us and trust it. Microsoft is definitely putting a lot of weight behind Azure and it made sense for us to use their platform. I saw the level of support behind Azure first hand when our company was invited to Redmond to meet the dev teams as part of an early adopter program.


> was invited to Redmond to meet the dev teams as part of an early adopter program.

I think that's the problem I see with Azure. AppHarbor needs no early adopter program. It's great for the same reason that Heroku and Rails were great for people: if you want to get an MVP up and running, it's almost instantaneous. I want to focus on my core product first and delay thinking about seriously scaling and the other major benefits of Azure over AppHarbor.


In their defense, Azure's target is not startups or 'hackers' with a toy app. In fact, it makes no sense at all pricing-wise if you only run a single webserver and database. Their pricing covers a large and growing set of features.

Microsoft's programs exist because of the insane amount of features and support that have to go into their products for their enterprise customers. And its those features that really make us stick with Azure for now. Specifically, I'm talking about TableStorage, Queues and AppFabric's Distributed Cache Service. I've already had a small chat with the AppHarbor guys before. I'd definitely love to move if it made sense.

Don't get me wrong though. I definitely have my gripes with Azure too.


Azure can make sense pricing wise for startups that have been accepted into their Bizspark program (which doesn't take much). Bizspark gives basically a single web server and database free and you can easily scale from there if you are willing to pay.

On the downside, deploying to Azure is a bit of a pain and its 15-20 minutes per deployment gets old, especially early on when you are deploying more often.


And yes, Visual Studio is that awesome

To me, that's only true once you have Resharper installed too,


Resharper is fantastic for speeding up programming and refactoring, I like to add vim to the mix (something like http://www.viemu.com/) for "simple" text editing as well.


I do not even see the need for justification : After LINQ and Rx and the maturing of Mono, .NET is now far ahead of the Java ecosystem, even including Scala 2.9, in terms of developer productivity. The only reason I am having to learn Scala is that I am already quite familiar with the Java ecosystem (having used it at work for many years before I started doing something on my own) and do not wish to start from scratch in the .NET world.


I am also quite familiar with the Java (and Ruby and pre iPhone Objective-C) ecosystem and invested quite a lot time in getting proficient with Scala since 2007 but recently got hooked on F#.

My experience has been, that the available documentation on .Net (and F#) is so much better compared to the other stacks I know, that after three months or so of dabbling in my free time with .Net I already feel like having a much more solid base in .Net than the other platforms (where I have 4, 3 and 6 years experience).

Granted this might be due to me either suck at Java, Ruby and Objective-C or me not yet having real world experience with .Net and being oblivious to ugly corner cases, warts etc. you only come across on a big real world project.

But honestly my first contact with some of the books and online resources available for the .Net ecosystem and comparing that with what I was accustomed to was shocking.


I object the "VS" is the best IDE statement. For C#, maybe that is true. But I used Intellij IDEA and VS. VS still looks like glorified notepad against IDEA. I think most developers are living under their language bubble. Also, unlike ruby-python, C# and Java are IDE languages. You cannot program without one.


So very true, IntelliJ IDEA is miles ahead of any other IDE I've ever used (including VS). For Java development, I started out with NetBeans, then switched to Eclipse and finally to IntelliJ.

Recentely JetBrains has also released IDEs for Ruby/Rails (RubyMine) and Python/Django (PyCharm). It will be interesting to see if they gain any momentum within their respective communties.


Have you used Resharper with Visual Studio? Made by Jetbrains who make Intellij, it brings a lot of the same refactorings and other features across. No serious .NET developer should be without it, though Visual Studio 2010 has added a lot of new features that previously were only available through Resharper.


ASP.net MVC is maybe quite similar to Rails (it actually is 'inspired by it' i.e. a rip off). But the difference between .NET and Ruby is that Ruby has a culture of hackers, and most of the innovative things re web dev are born in Ruby e.g. Haml, Capistrano etc,and then get ported to other langs e.g. { :Haml => 'PHaml', :Rails => ['many PHP frameworks', 'ASP.net MVC'], :Capistrano => 'Fabric' }


As a long time .NET developer converted to Ruby and Node.js, you hit the nail on the head. The innovators and creative types are on the open source side.

That is not to say I have not worked with talented .NET developers but for the most part the culture of .NET developers is to find a corporate job and wallow in an enterprise process. Don't do anything outside of Visual Studio and heaven forbid use anything not built by MS.

The same can be said about Java which needs to be redefined in the dictionary as THE language of over-engineering.


I think it's safe to say that .NET doesn't need defending. People who use it tend to continue using it whenever they have a choice in the matter, and quietly get good results from it every time.

It doesn't need defense because it's not being attacked. It's not being attacked because it just plain works. Granted it's a bit boring, but really that's one of its advantages.


I don't think this should even be a discussion. If it covers costs well and your solutions work, discussing this doesn't matter.

I started with using .Net for a startup four years ago. Back then there were no Redis, NoSQL wasn't even a invented as a term, cloud servers were just a concept and scaling wasn't anybody's primary concern. In four years the only optimizations I ever did were done via SQL Server profiling or just by modifying a bit of code. I pretty much learnt .Net during this time and the sites I work for get pretty hammered at their peak times and handle well.

So yes from experience .Net is a good starting point. If you know the internals you can probably write and architect code that scales well too without falling back on NoSQL services. You won't need to go looking for complicated PHP cache solutions etc, you won't need to get in the trouble of selecting complicated frameworks. The whole setup gives you ease of mind.

No arguments against LAMP or other environments. Just that I always found .Net to be easier to work with!


I don't think many people actually dislike the .Net family but it's more the parent company of .Net that causes a lot of dislike to filter down onto ASP.Net and C#.

I have this weird twisted hatred with Microsoft. I think .Net is great but as an iOS dev working inside a Microsoft based team I've founded solutions such as TFS to be just terrible lock ins.

I'd probably love Microsoft more if just this once they would of assessed the current source control versions, chosen a popular standard (Git) and then deeply integrated it into VS. What they instead did was give you TFS with a lack of client end Rest API documentation and wrote a terrible cross platform command line tool. You didn't see Apple creating XSourceControl.


a Microsoft based team I've founded solutions such as TFS to be just terrible lock ins.

The majority of .net development that I have seen is not done on TFS. I've used many source control sustems for .Net code.

SVN is far more common. a ".Net dev shop" is far from being the same thing as "a Microsoft only" shop. Typically you see software in use like NUnut, SVN, jQuery, Castle Windsor, TeamCity, Resharper, etc. If you're lucky, you may even get Git or Mercurual.

MS could not have standardised on Git even if they'd wanted to - TFS pre-dates Git by a few years. The driver for MS making TFS was two-fold:

1) get people off MS's previous source control system, SourceSafe, which dates back to about 1995. And it shows. SourceSafe is one of the few version control systems that I do not hesitate to say "avoid! Run! Use anything else!" about. TFS is actually a large improvement.

2) To try to prevent them from going to SVN instead, which was the new thing then. Since SVN is lightweight and free, so TFS took the opposite route of being heavyweight, kitchen-sink, ALM, etc.


Same as most other posts defending one technology choice versus others. It's what I know best...I like the tools...can't we all get along...

The only interesting point is also the vaguest...The AI that's already available in .NET (and, by the way it's stated, apparently not in others).

I also have to counterpoint that ASP.NET MVC is "conceptually" the same as Rails/Django. Conceptual similarities are pretty meaningless. My RC plane is conceptually similar to a fighter jet because it relies on the same four forces. Actual coding-wise, ASP.NET MVC is closer to WebForms than Rails.


> Actual coding-wise, ASP.NET MVC is closer to WebForms than Rails.

How so?

I've never worked with WebForms, but I have done a few Rails projects. I don't see any real differences except for ActiveRecord, which does have a .NET port: http://www.castleproject.org/activerecord/

Also, I wasn't trying to start a fight (really!). I just think that more .NET hackers should be motivated to do startups. IMHO, I think this is the year that .NET startups begin to take off. All the pieces are in place, it's just about motivating the community.


I have several years of experience in ASP.net webforms, MVC, and Rails, and I also don't see the argument that webforms is closer to .net MVC than Rails. Sure, the syntax is more similar because both can be C#. I'm guessing this is what you mean, but the philosophy and architecture of MVC presents such a dramatic difference from webforms that I would argue it is strikingly different.


I have no problem with .net, but what od you mean about "all the pieces are in place"?


I mean the barrier to entry has been lowered drastically. I used to do my projects in Rails because I didn't want to go through the hell of renting and setting up a server for ASP.NET. Also, MVC 3 has really flattened the learning curve and the expert community is finally putting together seriously good OSS and tutorials. Finally, MVC 3 development is also highly decoupled from a lot of the uglier MS attempts at making a totally proprietary stack (MS AJAX -> jQuery, Codeplex -> Github, Azure -> AppHarbor).


It's certainly much better than a few years ago, and an order of magnitude improved over webforms. In some respects, I think the OSS ecosystem has much room to grow to catch up with Rails and Django. Although Rails and Django could also learn some tricks from Microsoft.


I wish I could understand why you feel Asp.Net MVC is closer to WebForms than Rails. Unfortunately I have barely any Rails experience. But as a developer who did WebForms for years and made the switch to MVC, I will never go back.

Edit - I also see you're the founder of badg.ly? I remember checking out your site not too long ago. We seem to be some-what in the same space with our startup http://www.IActionable.com. I'd love to learn more about how that's going for you.


> ASP.NET MVC is closer to WebForms than Rails.

Could you please elaborate on this? I've written many websites in all three technologies and I don't see how standard ASP.NET is at all like ASP.NET MVC. Standard ASP.NET is a train wreck and a simply abysmal environment to be stuck in. People managed to make successful websites in spite of it, not because of it. ASP.NET MVC may be a bit behind the times and a total rip off of Rails and MonoRail, but it's one of the best things Microsoft has ever made.


I guess I owe an explanation.

Most significantly, much of the Rails magic comes from Ruby. So when you say the two (WebForms and ASP.NET MVC) aren't alike, its like you are forgetting that they both use C#. The DLR is a small step, but it isn't in the same league. We can disagree that Ruby is such a significant productivity boost over C# - that's fine. But, if you think language is completely irrelevant, then imagine an MVC framework like ASP.NET MVC where you had to code your HttpModules, HttpHandlers, controllers, models and data access code in C. Concrete example? You don't do DI in a Rails app...yet it permeates through any WebForms/MVC app you write.

Then there's the tooling. WebForms and MVC share the same deployment and package management. Both are young and inferior to Cap and Gems (but they are young and they've done a good job with it so far). They are both hosted on IIS and essentially deployed/configured/managed the same. WebForms and MVC share the same IDE.

Then there's community. ASP.NET MVC and WebForms generally have access to the same libraries (nUnit, NHibernate, JSON.NET), the same resources, and the same community leaders (hey, I was one of them!)

So far, ASP.NET MVC and WebForms share: Language, Community, Tools, Libraries and deployment story. None of these are shared with Ruby.

Let's talk about code. Neither ASP.NET MVC nor WebForms have a cohesive model/data access story. Microsoft doesn't really provide an "M" with ASP.NET MVC. You can pick DataSets (oh wait, we don't like that anymore), or Linq2Sql (oh wait, we don't like that anymore), or Entity Framework (lolz) or NHibernate. Or, you can use Castle's ActiveRecord. None of these are very similar to Rail's ActiveRecord. So, when it comes to modeling and persisting your data, WebForms and MVC are exactly the same - which happens to be quite different than Rails.

WebForms and MVC share HttpHandlers and HttpModules/Global.asax. These are pretty nice (especially managed HttpHandlers in IIS 7). They also share the same built-in configuration management. But those are, yet again, something they share with each other, not with Rails.

Controllers? Ya, ASP.NET MVC shares more in common here with Rails than it does with WebForm's page model. And I agree this is pretty substantial..but even under the covers, things aren't all the similar. Email sending is very different (in Rails it builds on top of the controller core, which is why I include it here). Routing, model binding, validation...ASP.NET MVC and Rails are more similar than ASP.NET MVC and WebForms...but they still aren't that similar.

Views? ASP.NET MVC shares some stuff with Rails, but easily as much with WebForms. Asset management (or lack thereof), nested layouts...

Honestly, the only thing the two share in common is a controller with actions. And, when you look at typical ASP.NET MVC code, controllers/actions tend to do a lot more than than an equivalent Rails actions.

ASP.NET MVC shares more with Silverlight or WinForms development than it does with Rails.

EDIT: Somehow in all that I forgot to mention that WinForms and MVC share the same framework (.NET) and runtime (DLR/CLR). Neither of which is anything like what Rails runs on.


Your argument is mostly that ASP.NET classic and ASP.NET MVC are similar because they come from the same technology stack. The same argument suggests that WinForms and WPF are similar to ASP.NET MVC too. Everyone was surprised by your initial comment because hardly anyone expected anything different from this. Of course ASP.NET MVC uses the CLR, C#, IIS, etc. That's entirely to be expected. It's also a technical detail and doesn't get at the heart of what ASP.NET MVC is really trying to be and the type of development model it is putting forward. Which I would argue is far more important and pertinent than the fact that ASP.NET MVC still uses web.config files.

ASP.NET MVC was written to be flexible, testable (this was paramount), and focus on separation of concerns. Even well written classic ASP.NET applications are very difficult to test. To accomplish this MVC was forced to use a lot of interfaces and yes dependency injection. But that's an artifact of the language and again not a surprising fact at all.

Ruby is capable of things that C# can only dream of. And when C# 6 or 7 finally make it possible, it will come with awful syntax and more stuff thrown into the kitchen sink language. So yes, Rails can win big things here because of Ruby. ASP.NET MVC can't win big things here because of C#. Although it's not as bad as you make it out to be. But again, no one is surprised by this.

Don't forget a major focus of Rails 3 was to decouple things and make them more modular -- Make it easier for developers to choose a data access layer other than ActiveRecord if they wanted to. I'd strongly argue Microsoft looked at Rails 1 and 2 and wisely made the choice to not strongly couple a data access layer into MVC.


"ASP.NET MVC shares some stuff with Rails, but easily as much with WebForms."

It's pretty simple to make ASP.NET MVC to use a different view engine (I prefer String Template, but there are plenty others) - arguably that pretty much removes any lingering flavor of the WebForms.


I see how changing the view engine addresses the 10 bigger points that I made.


When did hacker become a synonym for programmer?


Fair enough. I changed the link to the "don't hire .NET programmers" article.

I stand by the rest of the references, though. All the guys I mention in my last point are as much hackers as anyone I've ever met or worked with.


Wow, that article is full of all sorts of stupid. Someone should tell the author that .NET is not a language (not that it'll make a difference).

I find this part particularly hilarious:

"However, if you need to make a 1.7 oz burger, you simply can’t. There’s no button for it. The patties are pre-formed in the wrong size. They start out frozen so they can’t be smushed up and reformed, and the thawing machine is so tightly integrated with the cooking machine that there’s no way to intercept it between the two."

Pure silliness. Perfect example of an irrational language bias.


In the author's defense, it's not like he outlandishly says ".net is a language" -- it's fairly common to refer to the framework when discussing stacks because of specificity. Saying "I program Rails apps" is clear, and Ruby is assumed. Technically, I don't "program in Rails" is if it was a language, but since the knowledge needed to effectively work with a framework is so involved, it's worth stating.


I had a lot of problems with that article as well. But I'd still like the give the author the benefit of the doubt. I assume he has very narrow experience with some framework like webforms or ran into some developers who did. With a lot of microsoft's frameworks it is easy to get stuck at a simple problem with no obvious solution, and conclude that there is no possible way to do it within that framework. Most of the time if you keep digging , you will find that there usually is a simple, elegant way to solve your problem but many people just give up, and decide that Microsoft just sucks.


I've had a lot of the problems of the sort that you describe (particularly with ASP.Net MVC), and I've found that while there are always solutions, the solutions are often very difficult to find. And even harder to find (at least for my company) are people who have the experience to already know what those solutions are.


The problem with the Microsoft stack is not technical -- it is financial. Why pay M$ license fees when other platforms are free? Especially as you scale?


Please grow up and stop using 'M$'. It's not cool or clever anymore (if it ever was) and it undermines any good points you might be making.


Noted. Consider my point undermined.


"Can't we all just get along?"

Beauty of it, you don't need to get along with anyone. People will remember your product not your technology stack.


Ex .net dev here, keep learning python brother, the promised land is close!


Do you need help picking up all those names you dropped?




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: