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.
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.
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.
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?
It's about to get even breezier: http://msdn.microsoft.com/en-us/vstudio/gg316360
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.
C#, IronPython, and F# are amazing.
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 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.
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. I get the impression from the post that the toolset was already in place (paid for).
 I haven't looked at subscription options recently, so perhaps there is a start-up friendly level these day?
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!
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? Unless you're trying to sell them something, who gives a rats-ass what they think? :-)
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.
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.) :-)
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 :)
I have gone to equivalent places/events with my Acer laptop, without anyone judging me. (It is running Ubuntu, mind).
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.
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 .
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.
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).
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.
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.
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.
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.
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 ).
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 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.
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).
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.
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
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.
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 ;)
"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.
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.
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.
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.
To me, that's only true once you have Resharper installed too,
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.
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.
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.
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 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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
Beauty of it, you don't need to get along with anyone. People will remember your product not your technology stack.