Unapologetically build your startup technology in C#(sirchristian.net)
sirchristian.net
Unapologetically build your startup technology in C#
http://www.sirchristian.net/blog/2014/06/21/unapologetically-build-your-startup-technology-in-c-net/
151 comments
I agree "get all the free Microsoft goodies when you start, and once you really need the paid versions you're probably successful enough that the cost doesn't matter much" is one fair conclusion to the article. However I don't believe that's the only conclusion. Mostly I want .NET to be a consideration as an option when building out the technology in a startup.
I'm concerned about vender lock-in as well, just less concerned then I used to be. Microsoft's gone to great lengths to reduce some of my concerns. The fact that you are using C# with Postgres demonstrates that there doesn't need to be complete lock-in.
Do you mind sharing more about what your C#/Postgres app looks like? This combination is one option I'll be looking at for my next venture.
I'm concerned about vender lock-in as well, just less concerned then I used to be. Microsoft's gone to great lengths to reduce some of my concerns. The fact that you are using C# with Postgres demonstrates that there doesn't need to be complete lock-in.
Do you mind sharing more about what your C#/Postgres app looks like? This combination is one option I'll be looking at for my next venture.
OK, here goes. I'm not saying that we made the right choice all over, but this is what we currently have:
For the API we use ServiceStack (v3, because v4 is paid and has a ridiculously high license fee). It is the best-designed REST API library I've ever seen, in any language. Its focus on data and not on verbs makes it easy to build well-designed APIs and difficult to build crappy ones.
The API is the executable, self-hosting an HTTP server (using ServiceStack's support for the .NET HttpListener). We'll probably switch to FastCGI soon. In any case, we have an Nginx in front to serve all static assets, which proxies API calls through to our API.
The database layer is very lean: we rely heavily on Postgres stored procedures for much of our data logic. This way, we avoid a lot of roundtrips to the DB and back. We go as far as using Postgres's multiple cursor feature to return hierarchical data without repeating lots of data in a giant single JOIN. We then use C# to tie the pieces back together (e.g. imagine a blog example, if we'd have a query for certain posts AND their top 5 comments, we'd get one cursor for posts and one for all comments, in order, and then we tie each post to a set of comments in C#-o-world while mapping it to DTOs).
The queried data goes from what the stored procedures return straight into the DTOs that ServiceStack returns, so we have no "domain model" class structure or a heavy weight ORM. We use Dapper for easily mapping stuff to simple classes.
We insert/update data with ServiceStack.OrmLite - just simply adding rows. Often, an API DTO matches a DB table close enough that this just works without any extra mapping.
I general, we're convinced that heavy-weight ORMs don't make sense for backends which are little more than data-stores for single-page web apps.
We manage DB schema changes (and all stored procedures) using hand-written SQL scripts, much like how the Play framework does this (1.sql for the initial DB, 2.sql for changes since v1, etc). This works amazingly great, and gives us far greater control than any ORM ever gave me.
We host it all with Docker containers: one for the DB data (Docker's "data-only container" pattern), one for Postgres itself, one for the backend (running Mono 3.2.something on ubuntu 14.04), one for Nginx, and one for our static assets (so we can redeploy frontend code without restarting the nginx container). Currently, we're host it all at http://orchardup.com but we're not too happy with their very slow (but friendly) customer support. Docker has given us a bunch of headaches (for example, that data only container pattern is a lot less easy to set up in practice), but none .NET/Mono related.
Our frontend is a single-page web app, optimized for mobile, built with React and TypeScript.
For the API we use ServiceStack (v3, because v4 is paid and has a ridiculously high license fee). It is the best-designed REST API library I've ever seen, in any language. Its focus on data and not on verbs makes it easy to build well-designed APIs and difficult to build crappy ones.
The API is the executable, self-hosting an HTTP server (using ServiceStack's support for the .NET HttpListener). We'll probably switch to FastCGI soon. In any case, we have an Nginx in front to serve all static assets, which proxies API calls through to our API.
The database layer is very lean: we rely heavily on Postgres stored procedures for much of our data logic. This way, we avoid a lot of roundtrips to the DB and back. We go as far as using Postgres's multiple cursor feature to return hierarchical data without repeating lots of data in a giant single JOIN. We then use C# to tie the pieces back together (e.g. imagine a blog example, if we'd have a query for certain posts AND their top 5 comments, we'd get one cursor for posts and one for all comments, in order, and then we tie each post to a set of comments in C#-o-world while mapping it to DTOs).
The queried data goes from what the stored procedures return straight into the DTOs that ServiceStack returns, so we have no "domain model" class structure or a heavy weight ORM. We use Dapper for easily mapping stuff to simple classes.
We insert/update data with ServiceStack.OrmLite - just simply adding rows. Often, an API DTO matches a DB table close enough that this just works without any extra mapping.
I general, we're convinced that heavy-weight ORMs don't make sense for backends which are little more than data-stores for single-page web apps.
We manage DB schema changes (and all stored procedures) using hand-written SQL scripts, much like how the Play framework does this (1.sql for the initial DB, 2.sql for changes since v1, etc). This works amazingly great, and gives us far greater control than any ORM ever gave me.
We host it all with Docker containers: one for the DB data (Docker's "data-only container" pattern), one for Postgres itself, one for the backend (running Mono 3.2.something on ubuntu 14.04), one for Nginx, and one for our static assets (so we can redeploy frontend code without restarting the nginx container). Currently, we're host it all at http://orchardup.com but we're not too happy with their very slow (but friendly) customer support. Docker has given us a bunch of headaches (for example, that data only container pattern is a lot less easy to set up in practice), but none .NET/Mono related.
Our frontend is a single-page web app, optimized for mobile, built with React and TypeScript.
We've recently started down this C#/Postgres route. One of the main decisions to use C# was static typing, so I wanted to keep this with the data access layer as well. I've decided to use dotConnect for PostgreSQL so I can use EF. I figure I can use dapper or another micro ORM after I get into performance issues.
Our biggest problem with Postgres is actually the lack of a good GUI. I'm using 0xDBE for the amazing auto complete and PgAdmin for everything else.
Our biggest problem with Postgres is actually the lack of a good GUI. I'm using 0xDBE for the amazing auto complete and PgAdmin for everything else.
LINQ to DB (not LINQ2SQL; it's an OSS library) is also a good option to talk to Postgres while keeping type safety and performance.
Why do you want .NET to be considered?
Likewise, we are running our SaaS product's backend with full C# -based stack (built from scratch without using any PaaS specific technologies for IPC/RPC etc.etc. so can be run on any provider) on top of Windows VMs, but database is running in Postgres. The licensing being one of the major reasons for that and avoiding SQL Server, even though it was a technology I had lot of experience from before when I was doing IT administration in MS environments. But Postgres is not that dissimilar, at least when you tend to do lots of operations in the code and not inside the DB as storprocs..
Our client/agent piece is also written fully in C# (we support only Windows workstations at the moment so it was no-brainer decision) and recently I have been looking into Xamarin to leverage that investment when moving into other client platforms.
This has worked great as I have a history purely in Microsoft technologies so the administration is lot less of a burden compared to trying to figure out everything for some other stack. If you are fluent in one technology, why not use it, right? And besides, with Mono there's at least theoretical path for running parts of the backend on Linux, but in the big picture the licensing costs for Windows vs. Linux in managed hosting is peanuts.
Our client/agent piece is also written fully in C# (we support only Windows workstations at the moment so it was no-brainer decision) and recently I have been looking into Xamarin to leverage that investment when moving into other client platforms.
This has worked great as I have a history purely in Microsoft technologies so the administration is lot less of a burden compared to trying to figure out everything for some other stack. If you are fluent in one technology, why not use it, right? And besides, with Mono there's at least theoretical path for running parts of the backend on Linux, but in the big picture the licensing costs for Windows vs. Linux in managed hosting is peanuts.
The problem with c# + postgres is you still have to run it through Npgsql which is much, much slower than the native SqlServer drive microsoft ships with the .net framework.
Isn't ServiceStack(.OrmLite) a commercial product nowadays? Did this affect your choice in any way?
v3 is still pretty good though. I was hoping that some eager people would fork it to keep it going, but it looks like the interest is smaller than I hoped. Maybe I'll pick it up myself one day.
The core of ServiceStack (services, messages, routes; that part) is so well designed that I simply refuse giving up on it. I think that if I were to use a different language for whatever project, I'd probably rather spend many evenings reimplementing those core concepts than going with something less good (such as the common one-method-call per URL pattern of MVC WebAPI, Rails controllers, Sinatra, Flask, etc etc etc).
I'd probably buy ServiceStack v4 if it wasn't so outrageously expensive.
The core of ServiceStack (services, messages, routes; that part) is so well designed that I simply refuse giving up on it. I think that if I were to use a different language for whatever project, I'd probably rather spend many evenings reimplementing those core concepts than going with something less good (such as the common one-method-call per URL pattern of MVC WebAPI, Rails controllers, Sinatra, Flask, etc etc etc).
I'd probably buy ServiceStack v4 if it wasn't so outrageously expensive.
There is a fairly active fork of ServiceStack v3 at: https://github.com/NServiceKit/NServiceKit
Woa cool! Missed that, thanks!
There are two people talking in my head while I read this post. One says :
Too many people obsess about backends. Yes, build your startup in C# and a .NET stack if that's what your familiar with. The backend ultimately doesn't matter, and the faster you can create and then iterate on your product, the better off you'll be. The primary factor that will decide whether your startup is successful or not is if people like your product and actually use it. None of your users will know or care what you built it in, be it .NET, RoR, Django, Yii, whatever.
The other person in my head is saying. "OH MY GOD NO". I've used the .NET stack and various OSS stacks to build complicated web applications. From this experience, I've concluded that the .NET stack sucks. Yes it works, but almost any OSS Framework will provide a much better developer experience. Better while developing the initial product, and better when maintaining and extending it.
Too many people obsess about backends. Yes, build your startup in C# and a .NET stack if that's what your familiar with. The backend ultimately doesn't matter, and the faster you can create and then iterate on your product, the better off you'll be. The primary factor that will decide whether your startup is successful or not is if people like your product and actually use it. None of your users will know or care what you built it in, be it .NET, RoR, Django, Yii, whatever.
The other person in my head is saying. "OH MY GOD NO". I've used the .NET stack and various OSS stacks to build complicated web applications. From this experience, I've concluded that the .NET stack sucks. Yes it works, but almost any OSS Framework will provide a much better developer experience. Better while developing the initial product, and better when maintaining and extending it.
If there's a good chance you are going to have other developers get involved in the codebase then other considerations come up. E.g. how easy it is to find such a developer, how competitive pay is for the platform, how well established coding standards are to ease collaboration, what type of developer you want to attract (likelihood of being full-stack, willingness to learn about new technologies, experience, ..).
Not to say .NET can't still be the right choice. Just that there are other points to consider other than strictly personal preference. You could argue for an MVP this isn't the case but honestly I think being in a position where you have to do a full rewrite a year later is in some ways worse than facing a (hopefully slight) learning curve when starting out.
Not to say .NET can't still be the right choice. Just that there are other points to consider other than strictly personal preference. You could argue for an MVP this isn't the case but honestly I think being in a position where you have to do a full rewrite a year later is in some ways worse than facing a (hopefully slight) learning curve when starting out.
"but almost any OSS Framework" - are there real choices that do not involve the dynamic typing maintenance nightmare while giving you a C#-quality language? Maybe just Scala + Play.
I really wanted to use Scala+Play to get away from the MS stack, but the documentation for Play was pretty hard to navigate due to the volume of documentation and the breaking changes in 2.
You can also do Java + Play. And Go's out there now, and it comes with most of the stuff you get from Play out of the box (and for the other stuff, getting it is easy enough).
> And Go's out there now, and it comes with most of the stuff you get from Play out of the box (and for the other stuff, getting it is easy enough).
Any link? That seems to be pretty much wrong.
Any link? That seems to be pretty much wrong.
Which part? The coming with most of what you get from Play? Look at Go's template/html and net/http.
If you don't like those, pango2 aims to provide django-esque templates for go; things like martini, gin-gonic, and negroki provide nicer routers; and Gorilla aims to provide a good deal of web-server-y things.
If you don't like those, pango2 aims to provide django-esque templates for go; things like martini, gin-gonic, and negroki provide nicer routers; and Gorilla aims to provide a good deal of web-server-y things.
Go is a narrowly-specialized language though (no cross-platform mobile, lack of generics is bad for some projects etc.).
or as good an ide as visual studio ...
hang on a sec....
Long time developer here, came from vs to eclipse and later Netbeans and Idea:
Tell me: don't you still have to buy resharper to get the same refactoring tools that I get for free in eclipse?
Long time developer here, came from vs to eclipse and later Netbeans and Idea:
Tell me: don't you still have to buy resharper to get the same refactoring tools that I get for free in eclipse?
What kind of refactoring tools do you get free in eclipse that aren't included in VS 2013 or 2014?
I'm asking the question: maybe vs has improved since I left.
Until recently the meme among tje fanboys seemed to be "VS is the best ide" (i.e.: after you have installed resharper).
Are all modern refactoring tools installed ootb with vs 2013 or 2014?
Until recently the meme among tje fanboys seemed to be "VS is the best ide" (i.e.: after you have installed resharper).
Are all modern refactoring tools installed ootb with vs 2013 or 2014?
the short answer is "no" not all "modern refactoring" tools are available in vs2014.
with the advent of roslyn and the compiler api i would be you'll be seeing more and more built into visual studio, or at the very least broken off into free community extensions as the 'guts' of writing these kinds of plugins will get much easier.
i still vastly prefer vs to eclipse just because of responsiveness alone; the core features are great, and i pay for resharper too because it's a great tool worth the money.
with the advent of roslyn and the compiler api i would be you'll be seeing more and more built into visual studio, or at the very least broken off into free community extensions as the 'guts' of writing these kinds of plugins will get much easier.
i still vastly prefer vs to eclipse just because of responsiveness alone; the core features are great, and i pay for resharper too because it's a great tool worth the money.
Great to know, thanks!
Better how?
C#'s one of the best languages in town and the IDE's the unchallenged best in town by a long way. And the SQL product is amazing, much better than MySlowQL.
So what bit is better? Deployment? Hosting? I'm genuinely asking here, you're just waving hands.
I've used both, the thing that puts me off .Net is the lack of choice when new stuff comes out (like elasticsearch, or a new language, or something like Docker) as it usually takes a year or so before it's easy to use on Windows, but that's about it.
C#'s one of the best languages in town and the IDE's the unchallenged best in town by a long way. And the SQL product is amazing, much better than MySlowQL.
So what bit is better? Deployment? Hosting? I'm genuinely asking here, you're just waving hands.
I've used both, the thing that puts me off .Net is the lack of choice when new stuff comes out (like elasticsearch, or a new language, or something like Docker) as it usually takes a year or so before it's easy to use on Windows, but that's about it.
I've used Visual Studio, XCode, Eclipse and IntelliJ - the thought that Visual Studio is the unchallenged king of them all never crossed my mind. Honestly curious - what makes it the best in our opinion?
I've used XCode and Eclipse before, so I have nothing to compare IntelliJ against.
The debugging experience is the key. The best thing a VS user can do to boost productivity substantially is learn how to use the debugging tools (navigating the stack, using Debug output messages, conditional breakpoints, the immediate window, autos and locals, etc.)
The plugin and extension community is awesome. There are two extensions every (web) developer needs - Web Essentials and Productivity Power Pack. These two are produced unofficially by MS teams as a platform for experimental features that may or may not make it into future VS versions.
Refactoring and code correctness is so much better in VS. Code Analysis, StyleCop, and third-party tools like Resharper make it a snap to analyze and correct code that may cause issues in the future.
This, and the planning tools that TFS gives us out of the box (whether you use git or the tfs vcs) is a boon to developer productivity.
Not to mention the great effort MS makes at backward compatibility. If you created an app in 2006, chances are it'll work on the latest version of .NET without much trouble.
The debugging experience is the key. The best thing a VS user can do to boost productivity substantially is learn how to use the debugging tools (navigating the stack, using Debug output messages, conditional breakpoints, the immediate window, autos and locals, etc.)
The plugin and extension community is awesome. There are two extensions every (web) developer needs - Web Essentials and Productivity Power Pack. These two are produced unofficially by MS teams as a platform for experimental features that may or may not make it into future VS versions.
Refactoring and code correctness is so much better in VS. Code Analysis, StyleCop, and third-party tools like Resharper make it a snap to analyze and correct code that may cause issues in the future.
This, and the planning tools that TFS gives us out of the box (whether you use git or the tfs vcs) is a boon to developer productivity.
Not to mention the great effort MS makes at backward compatibility. If you created an app in 2006, chances are it'll work on the latest version of .NET without much trouble.
Thanks for the detailed reply.
One nitpick though: I've recently learned that .NET apps created for version 1.1 - 3.5 do not run on .NET v. 4.0+ - as a Java developer that was kind of surprising. You have to install a separate runtime, which affects Windows 8+ I think, since only v. 4.0/4.5 is installed.
Sorry, I should've said you can usually recompile the source against the latest .NET versions pretty easily.
you can't have that discussion without talking about the tech stack you're working with.
Nothing beats the integration level between .Net and VS, and I don't care what tech stack you're using to compare.
But outside of .Net, for things like C++, javascript, etc, things get a lot murkier.
Nothing beats the integration level between .Net and VS, and I don't care what tech stack you're using to compare.
But outside of .Net, for things like C++, javascript, etc, things get a lot murkier.
Which IDE beats VS in C++ editing and debugging capabilities?
IntelliJ, VS, Eclipse, xCode in that order.
Obviously the technology of choice should be Node.js and Ember, duh!
but postgres compared to sqlserver, you won't go back.
Is your post about C# or the .NET stack? I can (somewhat) relate to using C# over some other languages. However what I cannot relate to is being trapped with the .NET stack.
And a trap it is. You need expensive Windows Servers to host your stuff and Windows just disqualifies itself as a server platform (my subjective opinion). Having to use a powerful latest-tech machine and very recent OS version (2012?) with loads of patches, newest .NET framework just to host a super simple REST service with the almighty IIS is OVERKILL in every sense of the word.
Some people even use this approach when all they do is run an AngularJS powered, single-page javascript web application.
And my bullshit-meter just spikes when I see this kind of (use your imagination).
I agree that Visual Studio is a good choice for Windows software development and that SQL Server is (maybe) a good choice, when you use VS.NET (or .NET at all). But that's just a dependency when you opt for the Microsoft world. Stay clear of it and save yourself some hair.
Just my 2 cents! ;)
Best regards and good look with all that you do, Steviee
And a trap it is. You need expensive Windows Servers to host your stuff and Windows just disqualifies itself as a server platform (my subjective opinion). Having to use a powerful latest-tech machine and very recent OS version (2012?) with loads of patches, newest .NET framework just to host a super simple REST service with the almighty IIS is OVERKILL in every sense of the word.
Some people even use this approach when all they do is run an AngularJS powered, single-page javascript web application.
And my bullshit-meter just spikes when I see this kind of (use your imagination).
I agree that Visual Studio is a good choice for Windows software development and that SQL Server is (maybe) a good choice, when you use VS.NET (or .NET at all). But that's just a dependency when you opt for the Microsoft world. Stay clear of it and save yourself some hair.
Just my 2 cents! ;)
Best regards and good look with all that you do, Steviee
"You need expensive Windows Servers to host your stuff..."
I guess that depends on your definition of expensive. I've hosted my .NET stuff with http://www.discountasp.net for years and yes, they're not free, they're cheap. There are cheaper alternatives than them for IIS, but I like them. They provide a good service. Free doesn't float my boat because I don't want to worry about platform installation, patching and so on. I don't want to do more than FTP to publish.
Also interesting is that I could move to Azure without making a single change to my code. So Azure doesn't lock me into anything either.
"But that's [.NET] just a dependency when you opt for the Microsoft world"
Yes. It is a dependency. If I used Node, then Node.js would be a dependency. If I used Rails, then Rails would be a dependency. I don't get that dependency problem - we're all of us always going to be dependent on something, somewhere. Unless you code up your own OS, stack and tools, and make your own hardware.
Lock-in to Micro$oft is also something I've yet to hear a commercially convincing argument against. Is it really so bad? They've been around since the 80's. They're not going to disappear soon either. They strike me as a safe bet. Why is lock-in such an issue?
If vendor dependence is really such an issue, then design (architecture, if you will) is your mitigation. Abstraction solves that problem (actually any problem, bar performance).
As ever, when I hear these arguments against Microsoft and the .NET stack I hear consistency bias. Our nearly obsessive desire to be (and appear to be) consistent with what we have already done. Once we've made a choice, we encounter personal and interpersonal pressures to behave consistently with that commitment.
Node.js is cool. So is LAMP, .NET, COBOL and GW BASIC. Your choice is the right choice. For you. For your situation. If you're going to throw stones at my choice (not saying you are), I'd like to hear how lock-in to Microsoft will burn me. And after 14 years of hosting my stuff on IIS and developing with the Express Editions of Visual Studio, I'd love to know how it is more expensive than something else that provides a comparable development experience and service.
I guess that depends on your definition of expensive. I've hosted my .NET stuff with http://www.discountasp.net for years and yes, they're not free, they're cheap. There are cheaper alternatives than them for IIS, but I like them. They provide a good service. Free doesn't float my boat because I don't want to worry about platform installation, patching and so on. I don't want to do more than FTP to publish.
Also interesting is that I could move to Azure without making a single change to my code. So Azure doesn't lock me into anything either.
"But that's [.NET] just a dependency when you opt for the Microsoft world"
Yes. It is a dependency. If I used Node, then Node.js would be a dependency. If I used Rails, then Rails would be a dependency. I don't get that dependency problem - we're all of us always going to be dependent on something, somewhere. Unless you code up your own OS, stack and tools, and make your own hardware.
Lock-in to Micro$oft is also something I've yet to hear a commercially convincing argument against. Is it really so bad? They've been around since the 80's. They're not going to disappear soon either. They strike me as a safe bet. Why is lock-in such an issue?
If vendor dependence is really such an issue, then design (architecture, if you will) is your mitigation. Abstraction solves that problem (actually any problem, bar performance).
As ever, when I hear these arguments against Microsoft and the .NET stack I hear consistency bias. Our nearly obsessive desire to be (and appear to be) consistent with what we have already done. Once we've made a choice, we encounter personal and interpersonal pressures to behave consistently with that commitment.
Node.js is cool. So is LAMP, .NET, COBOL and GW BASIC. Your choice is the right choice. For you. For your situation. If you're going to throw stones at my choice (not saying you are), I'd like to hear how lock-in to Microsoft will burn me. And after 14 years of hosting my stuff on IIS and developing with the Express Editions of Visual Studio, I'd love to know how it is more expensive than something else that provides a comparable development experience and service.
If I were to make a web backend of some kind I'd go with C#/F#, but NOT IIS, not SQL Server, and depending on the instance costs of hosting, perhaps not windows either.
This is a good list of frameworks, including NancyFx, ServiceStack
http://fsharp.org/guides/web/index.html
This is a good list of frameworks, including NancyFx, ServiceStack
http://fsharp.org/guides/web/index.html
> You need expensive Windows Servers to host your stuff and Windows just disqualifies itself as a server platform (my subjective opinion). Having to use a powerful latest-tech machine and very recent OS version (2012?) with loads of patches, newest .NET framework just to host a super simple REST service with the almighty IIS is OVERKILL in every sense of the word.
This is true, I definitely agree.
I am , however, excited to know that they are taking steps to change this. ASP VNext is the next generation of asp.net applications: standalone, framework bundled, cross platform.
http://www.asp.net/vnext
This is true, I definitely agree.
I am , however, excited to know that they are taking steps to change this. ASP VNext is the next generation of asp.net applications: standalone, framework bundled, cross platform.
http://www.asp.net/vnext
> newest .NET framework just to host a super simple REST service with the almighty IIS is OVERKILL in every sense of the word.
Then you are happy to read about Owin :-)
using (WebApplication.Start<Startup>(url)) { Console.WriteLine("Server running on {0}", url); Console.ReadLine(); }
Then you are happy to read about Owin :-)
using (WebApplication.Start<Startup>(url)) { Console.WriteLine("Server running on {0}", url); Console.ReadLine(); }
We'll see. Hopefully it is not as half-hearted as the other technologies Microsoft tries to establish and then forgets about. They will need to put a lot of effort into it to have something even remotely equal to Node (or other micro servers). And when they deliver, the Node hype could be gone already! ;)
I've been stuck working in MVC3. I started a MVC5 app recently, and haven't had time to wonder about Owin. I'll have to look into it more.
Yes, I'm also eager to see this in action. About time.
Regards, Steviee
Regards, Steviee
SQL Server is a great piece of software and it integrates very smoothly with other MS software. What I have done on more than one occasion, is to set up a nightly job that mirrors our main (MySql or Postgres) db to a small SQL Server. The finance people can then use this to do data mining through, using the fine suite of products from MS. No need to actually use it for a development platform just for that.
> You need expensive Windows Servers to host your stuff
no. For startups you get 3 years free server: http://www.microsoft.com/bizspark/default.aspx
no. For startups you get 3 years free server: http://www.microsoft.com/bizspark/default.aspx
I've tried to sign up for this about 5 different times and have been denied and ignored every single time despite providing plenty of documentation at every turn. Pretty typical of my experiences with Microsoft.
Well, that means it's only free if you have all the right papers and permits.
strange. For me it was no problem.
[deleted]
So here is my take:
I'm currently working on a SaaS product built on .NET running on Windows Server, IIS, and SQL Server. We're not really a "startup" anymore, but we're still very small. I wasn't here when the first version of the product was built so I wasn't part of that decision.
If I were building this product from scratch today as a money-poor startup, I would probably go with tech stack included Java or Python and PostgreSQL. The primary motivation being cost (as in money).
Each developer is technically required to have an MSDN/VS Pro license (renews for just under $1000 per year). This is not very expensive if you're generating revenue, but if bootstrapping it is not cheap. You could cheat and just share a single license; you definitely won't get caught.
Windows Server licenses, compared to other datacenter costs, are relatively inexpensive. Windows Server has a few advantages; particularly in it's easy to administer and there are plenty of sysadmins out there than know it well.
The elephant in the room, at least for a SaaS product, is SQL Server. The features of Enterprise Edition are so compelling for SaaS (HADR, unlimited RAM, online index operations, compression, and encryption) that it's practically a requirement. But this will quickly become one of the most expensive costs in your datacenter.
But in my experience, SQL Server has some real advantages that I haven't yet discovered for PostgreSQL. The "community" around SQL Server is huge and has a ton of great people who love to help (often for free!). For instance check out http://brentozar.com or http://sqlblog.com/blogs/adam_machanic/.
There are programs like Bizspark which can bring the initial software license investment down to nearly $0. But if you're not generating significant revenue after three years, the licensing costs could hurt.
So like everything in world, it depends. But the bottom line is that, in my opinion, if you're bootstrapping then costs matter and Microsoft products (SQL Server in particular) are a huge cost which have real viable alternatives.
I'm currently working on a SaaS product built on .NET running on Windows Server, IIS, and SQL Server. We're not really a "startup" anymore, but we're still very small. I wasn't here when the first version of the product was built so I wasn't part of that decision.
If I were building this product from scratch today as a money-poor startup, I would probably go with tech stack included Java or Python and PostgreSQL. The primary motivation being cost (as in money).
Each developer is technically required to have an MSDN/VS Pro license (renews for just under $1000 per year). This is not very expensive if you're generating revenue, but if bootstrapping it is not cheap. You could cheat and just share a single license; you definitely won't get caught.
Windows Server licenses, compared to other datacenter costs, are relatively inexpensive. Windows Server has a few advantages; particularly in it's easy to administer and there are plenty of sysadmins out there than know it well.
The elephant in the room, at least for a SaaS product, is SQL Server. The features of Enterprise Edition are so compelling for SaaS (HADR, unlimited RAM, online index operations, compression, and encryption) that it's practically a requirement. But this will quickly become one of the most expensive costs in your datacenter.
But in my experience, SQL Server has some real advantages that I haven't yet discovered for PostgreSQL. The "community" around SQL Server is huge and has a ton of great people who love to help (often for free!). For instance check out http://brentozar.com or http://sqlblog.com/blogs/adam_machanic/.
There are programs like Bizspark which can bring the initial software license investment down to nearly $0. But if you're not generating significant revenue after three years, the licensing costs could hurt.
So like everything in world, it depends. But the bottom line is that, in my opinion, if you're bootstrapping then costs matter and Microsoft products (SQL Server in particular) are a huge cost which have real viable alternatives.
If you have outgrown Bizspark but are still relatively small the Microsoft Action Pack Subscription may be suitable for you.
Right. Eventually your business grows, you're doing $3M in revenue, and have 8 employees with a total burden of $1.5M. How much will it cost to run with per core fees for various components? Was the ease of use and maintability worth it (at this point, one can start to calculate but it gets murky)? Will it add or subtract from the infratstructure costs? I don't know, but I'm not going to go down a proprietary path to find out.
EDIT: Of course, it always depends on where you are coming from. If you are in a large corp. with MS tech already entrenched or come from that environment, it makes sense (as it seems many are that are weighing in). Or, if you are building to flip, and are most productive in this ecosystem.
EDIT: Of course, it always depends on where you are coming from. If you are in a large corp. with MS tech already entrenched or come from that environment, it makes sense (as it seems many are that are weighing in). Or, if you are building to flip, and are most productive in this ecosystem.
The big difference is that Bizspark gives you "production" licenses. The Action Pack licences are restricted to non-production usage only.
We actually use the Action Pack today to get access to the latest VS Pro. But it's "limited to three developers", and the other MSDN software benefits are severely limited compared to MSDN pro (e.g. only certain editions of Windows Server and SQL Server).
We actually use the Action Pack today to get access to the latest VS Pro. But it's "limited to three developers", and the other MSDN software benefits are severely limited compared to MSDN pro (e.g. only certain editions of Windows Server and SQL Server).
Your analysis of SQL Server is spot on. It's the biggest expense going 100% on the MS stack.
new VS subscription licences don't seem to be well publicised, but I'm pretty sure that $1000 could be cut down: http://www.visualstudio.com/en-gb/products/visual-studio-onl... - Assuming I'm reading it correctly.
That's very interesting. But it's not clear if you get the other important MSDN benefits, specifically dev licenses for Windows, Windows Server, and SQL Server.
No, it doesn't include MSDN, its just Visual Studio itself + cloud hosted TFS. "Visual Studio Online" seems to have replaced the non-MSDN tier of retail, one-time purchase Visual Studio licenses with a monthly licenses.
I work at a company where we have built one of our products (a large distributed system that tracks television content worldwide) completely on .NET. I love C#, it's a very decent blend between a whole lot of languages and additions of LINQ and async/await kept it relevant. Visual Studio is the best IDE I've worked with, not because it's such a good editor but because it has a sane debugger that is actually helpful.
I still wouldn't run my startup on .NET though, for a number of reasons. Mono simply isn't there yet. Code that works fine on Windows mysteriously stops working on Mono due to threading or GC vagaries (yes, even in the latest version). This isn't a dealbreaker, but it is pretty annoying especially since debugging these kinds of problems are of precisely the kind that I don't want to debug.
The ecosystem is really quite poor compared to, say, JVM or Node. For all the faults of either, there is a LOT of stuff going on and there is a LOT of innovation that is sorely lacking from the .NET world. .NET usually catches up eventually but it's either late or half-hearted (just look at the progress of NHibernate vs. Hibernate).
I think ASP.NET vNext is a step in a very good direction and I hope to be able to change my opinion sometime next year.
I still wouldn't run my startup on .NET though, for a number of reasons. Mono simply isn't there yet. Code that works fine on Windows mysteriously stops working on Mono due to threading or GC vagaries (yes, even in the latest version). This isn't a dealbreaker, but it is pretty annoying especially since debugging these kinds of problems are of precisely the kind that I don't want to debug.
The ecosystem is really quite poor compared to, say, JVM or Node. For all the faults of either, there is a LOT of stuff going on and there is a LOT of innovation that is sorely lacking from the .NET world. .NET usually catches up eventually but it's either late or half-hearted (just look at the progress of NHibernate vs. Hibernate).
I think ASP.NET vNext is a step in a very good direction and I hope to be able to change my opinion sometime next year.
> This isn't a dealbreaker, but it is pretty annoying especially since debugging these kinds of problems are of precisely the kind that I don't want to debug.
It's understandable that you don't want to (or don't have time to) debug them. But filing bug reports in Mono's bugzilla is appreciated, at least (maybe the Mono team can debug the problems for you).
It's understandable that you don't want to (or don't have time to) debug them. But filing bug reports in Mono's bugzilla is appreciated, at least (maybe the Mono team can debug the problems for you).
> NHibernate vs. Hibernate
As a counter argument to that (specifically), we don't really need NHibernate when we have Entity Framework.
As a counter argument to that (specifically), we don't really need NHibernate when we have Entity Framework.
When you start from scratch I'd agree with you, but if you want to interface with a legacy database and you need some more esoteric mappings and user-defined types then I'm not sure how happy you'd be with EF.
> Mono simply isn't there yet. Code that works fine on Windows mysteriously stops working on Mono due to threading or GC vagaries (yes, even in the latest version).
I remember having to maintain a small C# SDK in my previous work. That was a bit of a headache given that we were a 100% OSX shop. I installed MonoDevelop and libraries in my Mac to try to make some changes there, just to find out that Mono has not implemented some .NET standard encryption libraries.
I really appreciate what Miguel and team has achieved with Mono, but it is still incomplete, so from my experience it is not really an option. We ended installing XP in a virtual machine to modify the code.
I remember having to maintain a small C# SDK in my previous work. That was a bit of a headache given that we were a 100% OSX shop. I installed MonoDevelop and libraries in my Mac to try to make some changes there, just to find out that Mono has not implemented some .NET standard encryption libraries.
I really appreciate what Miguel and team has achieved with Mono, but it is still incomplete, so from my experience it is not really an option. We ended installing XP in a virtual machine to modify the code.
> Mono has not implemented some .NET standard encryption libraries.
Good find! Did you file a bug report?
Good find! Did you file a bug report?
[deleted]
It's important to remember that C# does not imply .NET
Xamarin has done some great stuff lately, for example you can use C# to make a native 3-platform mobile app. This is still proprietary tech, but it isn't Microsoft and it isn't .NET
In my eyes the best thing about the .NET ecosystem is the tools, if you like me fancy a polished IDE like IDEA, then VS is definitely one of the best ones around. In my eyes tools are more important than platforms, languages and licenses. The productivity hit of poor tools is much more expensive than anything else.
Also, if you are looking at C#, don't forget to consider F#.
Compare a minimalist service built on Node/AWS with one built on F#/Azure and it's not too different in cost but a much nicer language and better tools.
Xamarin has done some great stuff lately, for example you can use C# to make a native 3-platform mobile app. This is still proprietary tech, but it isn't Microsoft and it isn't .NET
In my eyes the best thing about the .NET ecosystem is the tools, if you like me fancy a polished IDE like IDEA, then VS is definitely one of the best ones around. In my eyes tools are more important than platforms, languages and licenses. The productivity hit of poor tools is much more expensive than anything else.
Also, if you are looking at C#, don't forget to consider F#.
Compare a minimalist service built on Node/AWS with one built on F#/Azure and it's not too different in cost but a much nicer language and better tools.
C# does imply .net, just as it implies windows.
Yes, other solutions exist, no those solutions aren't hugely popular in the grand scheme of things.
Yes, other solutions exist, no those solutions aren't hugely popular in the grand scheme of things.
This has changed a lot, especially over the last couple of years, a lot due to the F# project.
You should look at self-hosted NancyFx or ServiceStack with F# as a good alternative to Node.js
The fact that the "other solutions" aren't popular is probably just because C# is the go to language in windows/.NET shops that already have knowledge and infrastructure. It's not that they are technically inferior.
You should look at self-hosted NancyFx or ServiceStack with F# as a good alternative to Node.js
The fact that the "other solutions" aren't popular is probably just because C# is the go to language in windows/.NET shops that already have knowledge and infrastructure. It's not that they are technically inferior.
IMHO the problem in not a programming language choice, but the entire ecosystem that you should support if you will use microsoft.
Today for ex. linode and digital ocean have a very cheap entry price around 5$, with the power of entire open source lib, and
the power of the community of every open source project.
there's nothing in that post that gives C# a measurable advantage over say, Java.
Visual Studio Express? still way behind JetBrains IntelliJ (the community edition is FOSS). Visual Studio is unusable without JetBrains Resharper, which isn't cheap.
Azure? AWS
Bizspark? not required for Java dev as everything's free and OSS anyway.
Popularity? most popular .net libraries/tools (NUnit, NAnt, NHibernate) are all clones of popular Java projects
Scalability? those Windows licenses will cost you a fortune once you're out of bizspark
Vendor lock-in? well it's still there with MS, just you're not paying them for three years (Bizspark)
Visual Studio Express? still way behind JetBrains IntelliJ (the community edition is FOSS). Visual Studio is unusable without JetBrains Resharper, which isn't cheap.
Azure? AWS
Bizspark? not required for Java dev as everything's free and OSS anyway.
Popularity? most popular .net libraries/tools (NUnit, NAnt, NHibernate) are all clones of popular Java projects
Scalability? those Windows licenses will cost you a fortune once you're out of bizspark
Vendor lock-in? well it's still there with MS, just you're not paying them for three years (Bizspark)
In my experience C# is just a better language than Java (which isn't suprising, as C# was made just to be a better Java clone). Things like
That said, I still prefer Java because of the ecosystem and newer JVM languages like Clojure and Scala might just make Java irrelevant.
* value types (instead of boxing)
* no type erasure
* runtime exceptions
* dynamic/duck typing
* operator overloading (try working with arbitrary length decimals in Java)
That said, I still prefer Java because of the ecosystem and newer JVM languages like Clojure and Scala might just make Java irrelevant.
I've worked with C# and .NET for years. I agree that C# is a great language. I prefer working with the JVM and Linux ecosystems, though. On my latest project I decided to use Scala for the backend. I have access to a wealth of great libraries and services, and I actually prefer working with Scala than with C#.
Scala has all of those things, plus typeclasses, for comprehensions and scoped duck typing.
C#'s a somewhat better language, but I'm not sure there's enough in it to justify the ecosystem deficit, and, yep, Scala is there if you want it.
Scala has replaced Java most of our new projects.
"Visual Studio is unusable without JetBrains Resharper" ... I used to think the same. But my coworker doesn't use resharper and in he still codes better then me. I've actually noticed that VS becomes unsuable with Resharper, it is always feeezing now.
Ya, where did this myth come from? I don't use resharper and feel more productive than I did in eclipse.
a measurable advantage of c# over java is LINQ.
Java now has lambda's and a stream API, with which you can do the same thing as LINQ: http://blog.jooq.org/2013/11/02/does-java-8-still-need-linq-....
LINQ has expression trees (or maybe I should say .NET has them). Libraries like autofac or moq would not be possible without them.
This is a very unpopular opinion among .NET advocates, but personally I think LINQ is the worst thing to ever happen to c#.
It leads to (in my opinion) grotesque, unreadable code that more often than not hides enormous performance problems. It offers so much expressiveness, seemingly so innocent of its cost, that it gets massively overused and abused.
As with all things in languages, one can argue "use it right", "don't work with bad programmers", etc, but I have found this to be a universal issue across a number of shops that I've been brought into: If the project uses LINQ to any degree, enormous performance problems almost always come along for the ride.
Often this simply doesn't matter, hardware or low utility masking the problem. But when it becomes a problem, and it is endemic across the solution, it requires major reworking.
It leads to (in my opinion) grotesque, unreadable code that more often than not hides enormous performance problems. It offers so much expressiveness, seemingly so innocent of its cost, that it gets massively overused and abused.
As with all things in languages, one can argue "use it right", "don't work with bad programmers", etc, but I have found this to be a universal issue across a number of shops that I've been brought into: If the project uses LINQ to any degree, enormous performance problems almost always come along for the ride.
Often this simply doesn't matter, hardware or low utility masking the problem. But when it becomes a problem, and it is endemic across the solution, it requires major reworking.
Linq is an opportunity to write slow code very quickly. Of course when you have to spell out a 1-line Linq expression as a 50 line method, you'll notice that you wrote a triple nested loop and avoid it. But the point is this: the longer code is MUCH harder to comprehend than a concise Linq query, and the developer that didn't see that their Linq query was going to be slow wouldn't have reacted on that the expanded version also looked slow. The single line query can be more easily refactored as it can be comprehended.
So I say write slow code so you can find what's slow early on. The problem is likely to be in the architecture and data structures rather than in the processing code. If Linq gives an opportunity to deliver a working example quickly, and that example shows that for large N the perf is horrible, then Linq was extremely useful! Change some collection type, demoralize something, add some caching etc. and then slightly adjust the Linq query to suite. Large query methods are inertia to such changes so when they DO become necessary it's a larger effort.
Note that I mean Linq to objs now not Linq to Sql or some other provider.
So I say write slow code so you can find what's slow early on. The problem is likely to be in the architecture and data structures rather than in the processing code. If Linq gives an opportunity to deliver a working example quickly, and that example shows that for large N the perf is horrible, then Linq was extremely useful! Change some collection type, demoralize something, add some caching etc. and then slightly adjust the Linq query to suite. Large query methods are inertia to such changes so when they DO become necessary it's a larger effort.
Note that I mean Linq to objs now not Linq to Sql or some other provider.
Absolutely agree. I can't count the number of times I've seen some horrendous LINQ thing when a simple for loop would have sufficed, would have been easier to understand, and would have been far quicker.
I always wondered why computer languages and economy becomes religion and dogma.
We use multiple languages and multiple OS in my company.
When you have a company you have your own interest and your customers interest in mind.
Some times those interest are not the same of Microsoft, Apple, Google, IBM or Oracle.
Just developing on a single proprietary language from a single company on a single OS (and yes I know Mono and I don't have a good opinion on it) is a huge red flag for me.
We use whatever is necessary for solving our customers problems. Some times it means using C#, most most of the times we use better alternatives.
We use multiple languages and multiple OS in my company.
When you have a company you have your own interest and your customers interest in mind.
Some times those interest are not the same of Microsoft, Apple, Google, IBM or Oracle.
Just developing on a single proprietary language from a single company on a single OS (and yes I know Mono and I don't have a good opinion on it) is a huge red flag for me.
We use whatever is necessary for solving our customers problems. Some times it means using C#, most most of the times we use better alternatives.
I agree. My experience (and please tell me when I'm wrong) is that Windows developers for the most part stick to their choice of framework while multi-OS (Windows included) developers are more open to the wonders of the world.
So statistically the .NET guys may be more narrow-minded regarding development stacks.
Steviee
So statistically the .NET guys may be more narrow-minded regarding development stacks.
Steviee
> So statistically the .NET guys may be more narrow-minded regarding development stacks.
While true, .net developers don't need to venture out very far, I don't believe its solely because of narrow-mindedness (sure you'll find these developers everywhere, I can argue that node developers are narrow minded with node + express + mongo for example... hell people still write PHP =) ).
With .NET the reality is that there is no reason to consider anything else within the stack. Everything is standard, and most companies have them as part of MSDN. Majority of established .net enterprise environments use SQL Server with either ASP.NET webforms or MVC.net running on IIS + Win Server. What open source considers "vendor lock-in" is considered "standardised technology" in enterprise environments. When considering client work the first question is: "right what do you need to do?" and not "right, what stack are you using".
With Java, one client I have to learn Struts, another client I have to learn Play, then another client I have to learn JEE. I know Gradle in and out, but another contract requires me to know Maven, while another contract requires me to know Ant. Standalone server? Or Tomcat / Apache / WebSphere?
With Node, everyone has their own templating language (Jade or Handlebars or other). Some use CoffeeScript over plain Javascript. Some use SASS/LESS/ or just plain CSS. Some forward proxy using Haproxy, others NginX.
The point is: while the .net stack is pretty narrow, we know it works in the majority of use cases. And that's usually enough.
While true, .net developers don't need to venture out very far, I don't believe its solely because of narrow-mindedness (sure you'll find these developers everywhere, I can argue that node developers are narrow minded with node + express + mongo for example... hell people still write PHP =) ).
With .NET the reality is that there is no reason to consider anything else within the stack. Everything is standard, and most companies have them as part of MSDN. Majority of established .net enterprise environments use SQL Server with either ASP.NET webforms or MVC.net running on IIS + Win Server. What open source considers "vendor lock-in" is considered "standardised technology" in enterprise environments. When considering client work the first question is: "right what do you need to do?" and not "right, what stack are you using".
With Java, one client I have to learn Struts, another client I have to learn Play, then another client I have to learn JEE. I know Gradle in and out, but another contract requires me to know Maven, while another contract requires me to know Ant. Standalone server? Or Tomcat / Apache / WebSphere?
With Node, everyone has their own templating language (Jade or Handlebars or other). Some use CoffeeScript over plain Javascript. Some use SASS/LESS/ or just plain CSS. Some forward proxy using Haproxy, others NginX.
The point is: while the .net stack is pretty narrow, we know it works in the majority of use cases. And that's usually enough.
I'm a multi-stack developer, who has to use for his job. Honestly modern windows + .net development is pretty good.
> I know Mono and I don't have a good opinion on it
Can you add the URL of the bugs you found, to backup your statement? Thanks
Can you add the URL of the bugs you found, to backup your statement? Thanks
Man, 6 months ago I would have agreed with you. Hell I even have a year old BizSpark membership.
I just couldn't get over the thought in the back of my head that I'm making the wrong decision investing in Microsoft's development platform. C# is literally my favorite language, but I felt trapped and missed open source... Both the freedom it brings and the community. Maybe I spend too much time on HN.
I even tried to go 'indie' .NET. I moved to RavenDB (fuck MSSQL and it's overpricedness, and EF) and stuck with Azure, so really my only costs after my 3 years would be an MSDN license per developer. But in the end I just gave in to my worries.
One weekend I just rewrote the damn thing in NodeJS and I'm pretty happy. No need to boot up my Windows VM anymore either.
I think the talent pool is also what put me off. There seems to be - in London at least - a lot of career developers who pick .NET.
I just couldn't get over the thought in the back of my head that I'm making the wrong decision investing in Microsoft's development platform. C# is literally my favorite language, but I felt trapped and missed open source... Both the freedom it brings and the community. Maybe I spend too much time on HN.
I even tried to go 'indie' .NET. I moved to RavenDB (fuck MSSQL and it's overpricedness, and EF) and stuck with Azure, so really my only costs after my 3 years would be an MSDN license per developer. But in the end I just gave in to my worries.
One weekend I just rewrote the damn thing in NodeJS and I'm pretty happy. No need to boot up my Windows VM anymore either.
I think the talent pool is also what put me off. There seems to be - in London at least - a lot of career developers who pick .NET.
running 30+ windows servers
Microsoft has become much better, but still not sexy. Don't ever think they can fix everything for you, find out what they do well and what suxx and then do workarounds. Still too much microsoft and too little webstandards.
They upgrade more and fix more bugs, but this also break more stuff. Asp.MVC upgrades can be a pain..
.Net Core, C#, Linq, etc.. all very cool. Can make some stuff that performs very well, but can be very tricky to scale.
Asp.net i still too slow and too heavy.. taking >1min to start a asp.mvc site? It feels like some old grandpa compared to Node.js, Go and even PHP.
Powershell is still behind
Window Server administration can be very slow, .. how can it take 30seconds to draw an Event log ? Really miss ssh or even telnet.
Windows Services and schedules can be a pain. How can "access denied let the service run forever without notification??"
The license system is crap, they make their costumers feel stupid when they cant figure out how to renew they Action Pack's, etc..
And their crappy sales ppl, trying to push Sharepoint because they hear the word software and web.
So I really regret working with microsoft, althought I like some of .Net and C#, but what does one do for a good project and a salery.
Next project will not be .net for sure..
Microsoft has become much better, but still not sexy. Don't ever think they can fix everything for you, find out what they do well and what suxx and then do workarounds. Still too much microsoft and too little webstandards.
They upgrade more and fix more bugs, but this also break more stuff. Asp.MVC upgrades can be a pain..
.Net Core, C#, Linq, etc.. all very cool. Can make some stuff that performs very well, but can be very tricky to scale.
Asp.net i still too slow and too heavy.. taking >1min to start a asp.mvc site? It feels like some old grandpa compared to Node.js, Go and even PHP.
Powershell is still behind
Window Server administration can be very slow, .. how can it take 30seconds to draw an Event log ? Really miss ssh or even telnet.
Windows Services and schedules can be a pain. How can "access denied let the service run forever without notification??"
The license system is crap, they make their costumers feel stupid when they cant figure out how to renew they Action Pack's, etc..
And their crappy sales ppl, trying to push Sharepoint because they hear the word software and web.
So I really regret working with microsoft, althought I like some of .Net and C#, but what does one do for a good project and a salery.
Next project will not be .net for sure..
>> "Node.js"
If you need an HTTP Reactor pattern implementation in .NET, there is one coming soon. Patterns are not hot or old, they are just different for different needs.
If you need an HTTP Reactor pattern implementation in .NET, there is one coming soon. Patterns are not hot or old, they are just different for different needs.
the article seems to be saying C# is cheap and fast because it has a really good set of libraries. i have no problem believing this. the question in a startup is, is it more important to have good libraries or a powerful language? e.g. lisp is the most powerful language, but its library ecosystem isn't reliable enough. whereas java is a weak language but has great libraries. (that's why clojure's awesome!)
i'm not trying to start any kind of religious war here, but this is personally why i (and i suspect many others) code their web apps in python. it's a reasonably powerful language with an excellent set of libraries to go with it.
i'm not trying to start any kind of religious war here, but this is personally why i (and i suspect many others) code their web apps in python. it's a reasonably powerful language with an excellent set of libraries to go with it.
I did my Masters thesis in Computer Science in C# (data visualization). No apologies. A couple of people around the Institute have looked at me funny, but it's turned out to be a very good choice.
I'm currently working on my own startup. But didn't go the full Microsoft stack route.
I use C# and Visual Studio for development. I think right now nothing beats VS for pure production output. I do all development on a Windows box.
All frameworks work on Windows and Linux.
I use C# and Visual Studio for development. I think right now nothing beats VS for pure production output. I do all development on a Windows box.
All frameworks work on Windows and Linux.
Nancyfx - web framework
Cassette - asset optimization
Mongodb - database
Production server uses Ubuntu + Mono + Nginx.
$20 VM on Digital Ocean.
[deleted]
By all means, unapologetically build your startup with C#/.NET.
Every Linux/OSS based startup you will be competing with agrees with this recommendation.
Every Linux/OSS based startup you will be competing with agrees with this recommendation.
When you're choosing a tech stack in a startup there's a very important factor to consider that this article neglects to mention. It's likely, if you have any measure of success or you go down the investment route, that you'll be expanding your technical team quite early. The availability and cost of developers is critical at the beginning. Building in languages like PHP, JS, Java, and to a lesser extend Perl and Python, means you have access to lots of cheap devs. Especially in the case of PHP and JS. Those languages will scale reasonably well to the tens of thousands of users, by which time you'll probably be raising a Series A and you'll be able to afford to shift the important bits of the code to a more appropriate language.
While it might be 'right' to build in C# or Erlang or Haskell or Brainfuck or whatever, if you have to pay a premium to get your first engineer you'll be shortening your runway, and that's pretty much the worst thing you can do. It's much better to build in the 'wrong' stack to start with and give your startup time to get traction. At the end of the day, no one using your product gives a damn what it was built in.
While it might be 'right' to build in C# or Erlang or Haskell or Brainfuck or whatever, if you have to pay a premium to get your first engineer you'll be shortening your runway, and that's pretty much the worst thing you can do. It's much better to build in the 'wrong' stack to start with and give your startup time to get traction. At the end of the day, no one using your product gives a damn what it was built in.
man, I agree with your recommendation, but strongly disagree with your reasoning.
Cheap devs don't pay off. Seriously, I have hired a lot of developers and one good dev (at twice the rate of a cheap one) can easily do 10 times the work, while minimizing technical debt.
If you're doing a prototype with the full intention of throwing it away, that's one thing but please don't go cheap. Get less devs and pay them more.
As for languages, a startup wants to be cheap. Most of them are doing web stuff. Unless you have a specific need, go ruby or python. People who are interested in either generally are passing on php / javascript for a reason i.e. they're not good languages. Maybe pick go if you want to do systems stuff or performance is critical.
The reasons NOT to pick C# are 1) cost 2) lockin 3) flexibility
Cheap devs don't pay off. Seriously, I have hired a lot of developers and one good dev (at twice the rate of a cheap one) can easily do 10 times the work, while minimizing technical debt.
If you're doing a prototype with the full intention of throwing it away, that's one thing but please don't go cheap. Get less devs and pay them more.
As for languages, a startup wants to be cheap. Most of them are doing web stuff. Unless you have a specific need, go ruby or python. People who are interested in either generally are passing on php / javascript for a reason i.e. they're not good languages. Maybe pick go if you want to do systems stuff or performance is critical.
The reasons NOT to pick C# are 1) cost 2) lockin 3) flexibility
In my experience, in the case of people wanting to work in a startup, cheap usually means 'lots of competition for the job' rather than 'is bad at code'.
Absolutely true, and so often missed. While it may be true that a good programmer can learn any language the cost of this is time, and nowhere is the phrase 'time is money' more true than in a startup.
> Building in languages like PHP, JS, Java, and to a
> lesser extend Perl and Python, means you have access to
> lots of cheap devs. Especially in the case of PHP and JS.
I imagine 'coding in PHP' is quite a lot way down the list of requirements to work at FB. There are much more important skills, like being able to write code that works at scale. That isn't the case for most startups - prior experience of the tech stack is right at the top.
Another equally potent idea is to build products which integrate with Microsoft's own, popular products. For example, the popularity of Excel caused me to build this: http://activemesa.com/x2c
I had a hard time getting past:
> In reality Microsoft doesn’t want your money until you can afford to give it to them.
Building your business on that premise seems very dubious at best.
> In reality Microsoft doesn’t want your money until you can afford to give it to them.
Building your business on that premise seems very dubious at best.
I use C# for work and it is a nice language to work with. However mono runs dog-slow compared to C# and is practically unusable. So you are locked in.
> However mono runs dog-slow compared to C# and is practically unusable
Did you file a bug about this? What version of Mono were you using?
Did you file a bug about this? What version of Mono were you using?
I'm getting a 404 error. Is there a cached copy out there?
EDIT: The blog's front page has a full copy of the article at the top. (As I write this at least.)
EDIT: The blog's front page has a full copy of the article at the top. (As I write this at least.)
But it still being DoS'ed by HN traffic. Google cache: http://webcache.googleusercontent.com/search?q=cache:http://...
[deleted]
Not saying it is the case here, but blogs praising ms tech always raise some flags with me, as with http://www.pcworld.com/article/2365060/microsoft-caught-astr...
The throwaway comment is this: who cares about backends? Go make something people want. Every second you spend chatting tech is wasting your time. Make something people want even if you have to do it with a pencil and paper. Worry about the tech when you've figured out step one. 99% of startups don't do this.
So for all of the armchair startup warriors out there, the guys eager to hear if Facebook is really running MongoDB or what their sharding plan looks like, let's look at the tech.
I'm a MS hound from way back. I made a bet -- a very good one -- back in the 90s that MS was going to own the PC market. And it did. And life was good. Microsoft sold tools and apps, I came in and programmed using those tools and apps. Many times I came in after the local yokels had already screwed things up. This meant a higher bill rate. Life was nice.
But I started noticing something: there was a certain arrogant-jerk-inbred-echo-chamber feeling to the MS community. MS pimped tools to the developers. Developers ate it up. MS pimped new servers to their MVPs. The MVPs sold them to corporations, consultants came in and collected. It was all fine and dandy, but over time there just got to be more and more tools and apps, and more and more servers and experts. Any small reasonable thing you'd like to do, like set up an email server, involved books, certifications, special servers, learning the acquisition history of all these small companies, and so on. It was ludicrous that any one person could be an expert enough to maintain the small set of tools that most folks would need. Microsoft was adding complexity -- unneeded complexity -- into everything it touched.
More troubling, once I started learning more about startups, I saw developers obsess over new Microsoft tools or third-party components instead of making things people wanted. Microsoft's interests was in creating and maintaining this ecosystem of selling servers and tools, not in helping people make things other people want. So I'd see these projects that were supposed to be solving a simple problem. They'd use all kinds of fat, bloated, feature-laden junk strung together in a huge pile of tech. Then somebody would start down the "happy path" of making a "hello world " app work. Very soon, however, developers ventured off the happy path, and then they had to learn javascript, html, SMTP, SQL, and so on.
So development consisted of salivating over new stuff, eagerly installing it, and then wandering around in the weeds trying to hook all the pieces together. And oh, by the way, the user was supposed to like it. But, let's face it, screw the user. We're here for the tech, right?
I still love the CLR and several other things Microsoft has created. But I'm not part of the ecosystem any more, and I won't spend any time at all learning whatever new version of Silverlight they'll have out next year. I'll also stick to my command line and bash, thank you very much. I've been burned too many times, and I've seen too many development teams destroy their productivity by getting lost in the Microsoft ecosystem.
So for all of the armchair startup warriors out there, the guys eager to hear if Facebook is really running MongoDB or what their sharding plan looks like, let's look at the tech.
I'm a MS hound from way back. I made a bet -- a very good one -- back in the 90s that MS was going to own the PC market. And it did. And life was good. Microsoft sold tools and apps, I came in and programmed using those tools and apps. Many times I came in after the local yokels had already screwed things up. This meant a higher bill rate. Life was nice.
But I started noticing something: there was a certain arrogant-jerk-inbred-echo-chamber feeling to the MS community. MS pimped tools to the developers. Developers ate it up. MS pimped new servers to their MVPs. The MVPs sold them to corporations, consultants came in and collected. It was all fine and dandy, but over time there just got to be more and more tools and apps, and more and more servers and experts. Any small reasonable thing you'd like to do, like set up an email server, involved books, certifications, special servers, learning the acquisition history of all these small companies, and so on. It was ludicrous that any one person could be an expert enough to maintain the small set of tools that most folks would need. Microsoft was adding complexity -- unneeded complexity -- into everything it touched.
More troubling, once I started learning more about startups, I saw developers obsess over new Microsoft tools or third-party components instead of making things people wanted. Microsoft's interests was in creating and maintaining this ecosystem of selling servers and tools, not in helping people make things other people want. So I'd see these projects that were supposed to be solving a simple problem. They'd use all kinds of fat, bloated, feature-laden junk strung together in a huge pile of tech. Then somebody would start down the "happy path" of making a "hello world " app work. Very soon, however, developers ventured off the happy path, and then they had to learn javascript, html, SMTP, SQL, and so on.
So development consisted of salivating over new stuff, eagerly installing it, and then wandering around in the weeds trying to hook all the pieces together. And oh, by the way, the user was supposed to like it. But, let's face it, screw the user. We're here for the tech, right?
I still love the CLR and several other things Microsoft has created. But I'm not part of the ecosystem any more, and I won't spend any time at all learning whatever new version of Silverlight they'll have out next year. I'll also stick to my command line and bash, thank you very much. I've been burned too many times, and I've seen too many development teams destroy their productivity by getting lost in the Microsoft ecosystem.
Its weird that the HN crowd just seems to assume that the advice to use linux and mono just has to be a better idea than using windows.
If you haven't looked at windows since 2003 you really need to take a look at server 2012 R2. The default installation mode is server core. It requires dramatically fewer patches. Management with PowerShell is incredibly powerful. IIS has seen many, many improvements.
Also, "developing your app for azure" is a weird statement. If you develop for Azure Websites you are literally just writing an asp.net web app or api. it runs in IIS in a VM. It just has some management wrapped around it so that you don't have to take care of the VM(s). It has autscale, monitoring, and all the stuff you would expect from a cloud provider. Writing your app to use SQL Azure, or Azure storage, or something like that is just like using the comparable services from Amazon. It's like anything else...you should implement its usage as an interface so you can swap it out if need be.
Some people on HN have accused me of working for MS just because I use their stuff. I'm not, nor have I ever been, a MS employee. I'll admit that I started looking into windows a couple of years ago because I was bored with Linux and Unix. I've found that if you put the time in to understand how it works its incredibly productive and thorough. If you try to make it work like unix it will suck. If you learn PowerShell and stay away from the "clickety-clickety" thing it's awesome.
From a development standpoint I actually like the total stack approach...but that's me. If you need to use best of breed components you can still do that with .Net. For me though, my interests shifted to C++ a while ago, so .Net stuff for web api's get's the work done when I have to do it. I would like to see more stuff like openstack in the .net world, but system center is fine. The stuff that I do ends up being important enough for enterprises that getting funds for that kind of thing is just part of the package.
That's another thing. I'm completely uninterested in startups. I've worked at startups in various roles in the past and I'm just over it. Any startup that I built would have to be something that I could run by myself that immediately made money that I would keep. Investment funding is shit. It's a hassle that is super crazy. Dealing with "business" types that aren't technical enough to understand the challenges is also completely off the table. If you did choose to work with a VC then it's much better to be making money and talking about selling out totally instead of implanting them in your life. Shudder.
The one thing that I think Windows needs is a container style app deployment model. The coolest thing going in large scale app building is CoreOS. Its the future of how a large scale app will be built and deployed.
The new, and much loathed, metro applications are actually a good starting place for building a container system. They use feature called "app containers" that was first introduced in Vista. Add to that an app package that installs and uninstalls as a unit, called APPX. They haven't made any noise about using the new app model for servers, but it would be a great idea. It uses an API monitor that stops calls to things like LoadLibrary or GetProcAddress and all the other API's that let you bootstrap malware. Anyway, like I said, they haven't made any noise about it...it would be cool though.
If you haven't looked at windows since 2003 you really need to take a look at server 2012 R2. The default installation mode is server core. It requires dramatically fewer patches. Management with PowerShell is incredibly powerful. IIS has seen many, many improvements.
Also, "developing your app for azure" is a weird statement. If you develop for Azure Websites you are literally just writing an asp.net web app or api. it runs in IIS in a VM. It just has some management wrapped around it so that you don't have to take care of the VM(s). It has autscale, monitoring, and all the stuff you would expect from a cloud provider. Writing your app to use SQL Azure, or Azure storage, or something like that is just like using the comparable services from Amazon. It's like anything else...you should implement its usage as an interface so you can swap it out if need be.
Some people on HN have accused me of working for MS just because I use their stuff. I'm not, nor have I ever been, a MS employee. I'll admit that I started looking into windows a couple of years ago because I was bored with Linux and Unix. I've found that if you put the time in to understand how it works its incredibly productive and thorough. If you try to make it work like unix it will suck. If you learn PowerShell and stay away from the "clickety-clickety" thing it's awesome.
From a development standpoint I actually like the total stack approach...but that's me. If you need to use best of breed components you can still do that with .Net. For me though, my interests shifted to C++ a while ago, so .Net stuff for web api's get's the work done when I have to do it. I would like to see more stuff like openstack in the .net world, but system center is fine. The stuff that I do ends up being important enough for enterprises that getting funds for that kind of thing is just part of the package.
That's another thing. I'm completely uninterested in startups. I've worked at startups in various roles in the past and I'm just over it. Any startup that I built would have to be something that I could run by myself that immediately made money that I would keep. Investment funding is shit. It's a hassle that is super crazy. Dealing with "business" types that aren't technical enough to understand the challenges is also completely off the table. If you did choose to work with a VC then it's much better to be making money and talking about selling out totally instead of implanting them in your life. Shudder.
The one thing that I think Windows needs is a container style app deployment model. The coolest thing going in large scale app building is CoreOS. Its the future of how a large scale app will be built and deployed.
The new, and much loathed, metro applications are actually a good starting place for building a container system. They use feature called "app containers" that was first introduced in Vista. Add to that an app package that installs and uninstalls as a unit, called APPX. They haven't made any noise about using the new app model for servers, but it would be a great idea. It uses an API monitor that stops calls to things like LoadLibrary or GetProcAddress and all the other API's that let you bootstrap malware. Anyway, like I said, they haven't made any noise about it...it would be cool though.
> Some people on HN have accused me of working for MS just because I use their stuff.
I find it hard to believe it all happened in the couple minutes it took you to create the account and post this.
The main problem I see with developing for Windows is that the server side ecosystem outside Windows is much richer. Once you built your application on ASP.NET, you are pretty much limited to Windows servers or Mono on Linux and even that step may need some work because Mono is an incomplete subset of the Windows environment.
I would say the same for developing software that only runs on Solaris (and its descendants). Despite Solaris being an amazingly solid OS, if your app does not run neatly on other OSs, you are limiting yourself - you made many architectural decisions very early in the development process that will impact it for a very long time and, if you are not careful, limit your future decisions to whatever is available from a single vendor.
The last time I made a decision to move from Windows to Unix-likes it was a Java application running on the Orion server. It was a 15-minute job, even though we never gave much thought to porting it. I seriously doubt such thing is possible with ASP.NET and Mono.
Apart from .NET, there is little reason to go with Windows. Most of my development these days is with JavaScript, Python (with Flask or Django) and PHP. None of these would run any better on Windows.
I find it hard to believe it all happened in the couple minutes it took you to create the account and post this.
The main problem I see with developing for Windows is that the server side ecosystem outside Windows is much richer. Once you built your application on ASP.NET, you are pretty much limited to Windows servers or Mono on Linux and even that step may need some work because Mono is an incomplete subset of the Windows environment.
I would say the same for developing software that only runs on Solaris (and its descendants). Despite Solaris being an amazingly solid OS, if your app does not run neatly on other OSs, you are limiting yourself - you made many architectural decisions very early in the development process that will impact it for a very long time and, if you are not careful, limit your future decisions to whatever is available from a single vendor.
The last time I made a decision to move from Windows to Unix-likes it was a Java application running on the Orion server. It was a 15-minute job, even though we never gave much thought to porting it. I seriously doubt such thing is possible with ASP.NET and Mono.
Apart from .NET, there is little reason to go with Windows. Most of my development these days is with JavaScript, Python (with Flask or Django) and PHP. None of these would run any better on Windows.
Actually I've had to start over with this account. But...good catch. I'm trying to take some advice this time about the way that I respond to people.
I get your point about portability, its just not one that I agree with. I think that using the platform for what its good at is a totally viable thing to do.
I also take your point about the stack that you are using. Cheers.
I get your point about portability, its just not one that I agree with. I think that using the platform for what its good at is a totally viable thing to do.
I also take your point about the stack that you are using. Cheers.
As someone who works professionally in both environments on a day to day business, I don't understand it either.
I personally prefer developing on linux because of the tools available, but they're both perfectly capable.
I personally prefer developing on linux because of the tools available, but they're both perfectly capable.
In a lot of cases I find that its usually that people had written windows off several years ago and haven't looked at it seriously. For a lot of people taking the time to learn PowerShell or the "windows way" of going about something is either something they don't have the time or interest to do.
I'm sympathetic to that, don't get me wrong...if you have to get something done quickly you go with what you know. That's cool.
I've just noticed that a lot of the reasons that people give to justify their choices are predicated on an experience with an older version of windows or if you drill into it, they "thought" it should work one way and didn't take the time to find out how it actually works.
I agree that they are both completely capable...
I'm sympathetic to that, don't get me wrong...if you have to get something done quickly you go with what you know. That's cool.
I've just noticed that a lot of the reasons that people give to justify their choices are predicated on an experience with an older version of windows or if you drill into it, they "thought" it should work one way and didn't take the time to find out how it actually works.
I agree that they are both completely capable...
The problem is cost and lock-in. Microsoft has a ton of great products out there, and I use many of them at my own job at my current job. But if I were starting my own company, I don't think I'd want to build things on a Microsoft stack.
I would at least put C# on the table for consideration though. But that's because I really like C# and have a bit of experience developing in Xamarin with it for both the CLR and mono, so I know the workflow and tech CAN work on linux. The quality of some stuff out there, like this http://www.codeproject.com/Articles/168662/Time-Period-Libra..., is phenomenal. The concurrency stuff is pretty solid as well. But it's a different ecosystem too and you get casualties like ServiceStack.
I was also enamored with UNIX and later on GNU/Linux as a cheapest way to get UNIX at home. After already some years experience with *-DOS, Netware, Windows and Amiga systems.
But from the point of view of technology stack, innovation seems to be standing still on the UNIX side of things.
Microsoft seems to innovate more in terms of how modern OS stack should look like, in terms of full stack, whereas UNIX clones hardly offer more than "portable" POSIX cli and daemon model APIs.
But from the point of view of technology stack, innovation seems to be standing still on the UNIX side of things.
Microsoft seems to innovate more in terms of how modern OS stack should look like, in terms of full stack, whereas UNIX clones hardly offer more than "portable" POSIX cli and daemon model APIs.
Again: I'm also not a big ms fan (see my comment on visual studio) but why not comment when downvoting?
I agree completely. I would add however that CoreOS or NetBSD rump kernels are really very innovative.
I agree somewhat, as I meant the whole stack.
Interesting how the post completely ignores the quality of the language. Most people I know don't use C# for the same reason they don't use Java: Because it's often feels bloated, over-engineered and too verbose for building stuff fast. It has nothing to do with Microsoft, Azure or scaling, they just prefer whatever dynamic language they're comfortable with.
I've only ever heard good things about C#. I believe C# has first class anonymous functions, makes async operations easy, and a combination of VisualStudio and JetBrains resharper you have a pretty amazing development environment. I haven't programmed much with C#, but like I said I've only heard good things.
C# is a fine option if your choices are C# or Java. On the other hand, F# is safer and 3 times more concise language that can do everything C# can It interops perfectly with any C#/VB.NET libraries. I'd think long and hard when writing any new C# code, and defend why you need to reduce your possible solutions to only those C# supports, when you could have the ability to do everything C# does and more with F#.
For me personally, conciseness of F#, it's tendency to use short words, cram things together and overload operators actually make it less readable. I like many of the features F# has and am happy to see how they are slowly migrating to C#.
If you want to get paid...use C#, if you want to get paid less...use vb.net, if you want to be right use F#. This is outside of the startup discussion here...but it is the general rule for MS developers. All three languages are comparable to the junior to mid level dev.
I can see people having reservations about C# for many reasons - mainly as to how closely it is tied to Microsoft and to Windows (yes, I know it is cross platform, but the focus of the eco-system in very much on Windows) - but I can't see the quality of the design of the language being much cause for concern. Personally, I think it's one of the nicer languages in that particular space at the moment - certainly much nicer than Java.
"I know it is cross platform, but the focus of the eco-system in very much on Windows."
There's a funny thing about its cross-platform nature: You almost never see C# apps on other platforms. Why is that? There must be thousands of useful C#/.Net applications made that other platforms could benefit from, but the ONLY ones I've seen are the ones that targeted Mono to begin with. Nothing else.
Something fishy is going on here.
There's a funny thing about its cross-platform nature: You almost never see C# apps on other platforms. Why is that? There must be thousands of useful C#/.Net applications made that other platforms could benefit from, but the ONLY ones I've seen are the ones that targeted Mono to begin with. Nothing else.
Something fishy is going on here.
> There's a funny thing about its cross-platform nature: You almost never see C# apps on other platforms. Why is that? There must be thousands of useful C#/.Net applications made that other platforms could benefit from
I'm not sure that that's actually the case. C# has never caught on in a big way for consumer desktop development; the bulk of that still seems to be C++ and Win32/Win32 wrapper. It's used for _enterprise_ desktop development, of course, but people are less excited about porting that.
I'm not sure that that's actually the case. C# has never caught on in a big way for consumer desktop development; the bulk of that still seems to be C++ and Win32/Win32 wrapper. It's used for _enterprise_ desktop development, of course, but people are less excited about porting that.
Yeah, that could explain it. Sort of like how you rarely see Java client applications...
Eclipse, PyCharm?
I think its simple. Unless the person is interested in Mono they don't develop for it and don't have any interest in supporting it.
Many people use C# to develop applications for Windows and don't, won't or can't support other environments....
And while there are thousand of useful C# programs I doubt many don't have direct python / Linux competitors readily available that do near enough the same thing.
Many people use C# to develop applications for Windows and don't, won't or can't support other environments....
And while there are thousand of useful C# programs I doubt many don't have direct python / Linux competitors readily available that do near enough the same thing.
Two reasons:
a) I can't imagine somebody bothering to support .net software on the Linux desktop without being paid for it. I know those guys[1] are a minority, but it takes only a minority to create an absolutely toxic atmosphere. Maintaining a end user product can lead to frustrating interactions, and it doesn't really help if your choice of technology means that there exists a significant number of people who literally want you, your spouse, your three year old daughter and the family dog to die in a fucking fire.
b) Mono was always a bad choice for asp.net, which means that the software people are actually paid for doesn't run well on Linux. That was mostly a problem outside of xamarins control, and I hope it becomes better not that the devdiv MS seems to be somewhat committed to work together to make it truly interoperable.
[1] Just look at the comments at http://techrights.org/2013/02/09/tombye/.
a) I can't imagine somebody bothering to support .net software on the Linux desktop without being paid for it. I know those guys[1] are a minority, but it takes only a minority to create an absolutely toxic atmosphere. Maintaining a end user product can lead to frustrating interactions, and it doesn't really help if your choice of technology means that there exists a significant number of people who literally want you, your spouse, your three year old daughter and the family dog to die in a fucking fire.
b) Mono was always a bad choice for asp.net, which means that the software people are actually paid for doesn't run well on Linux. That was mostly a problem outside of xamarins control, and I hope it becomes better not that the devdiv MS seems to be somewhat committed to work together to make it truly interoperable.
[1] Just look at the comments at http://techrights.org/2013/02/09/tombye/.
"I think its simple. Unless the person is interested in Mono they don't develop for it and don't have any interest in supporting it."
But why wouldn't someone who IS interested in running the application on Linux simply do the last bits to get it to other platforms? I have NEVER seen that happen.
"And while there are thousand of useful C# programs I doubt many don't have direct python / Linux competitors readily available that do near enough the same thing."
Sure, but I refuse to believe all the competitors are always doing a better job. There should be at least some application that found their way over to for example Linux.
But why wouldn't someone who IS interested in running the application on Linux simply do the last bits to get it to other platforms? I have NEVER seen that happen.
"And while there are thousand of useful C# programs I doubt many don't have direct python / Linux competitors readily available that do near enough the same thing."
Sure, but I refuse to believe all the competitors are always doing a better job. There should be at least some application that found their way over to for example Linux.
What about Xamarin though:
https://xamarin.com/
I've been kind of avoiding mobile development after getting my fingers slightly singed by spending too much time with jQuery Mobile before giving up - the one thing that tempts me to try doing some mobile development is the Xamarin tool set.
https://xamarin.com/
I've been kind of avoiding mobile development after getting my fingers slightly singed by spending too much time with jQuery Mobile before giving up - the one thing that tempts me to try doing some mobile development is the Xamarin tool set.
> they just prefer whatever dynamic language
That's the thing. If you're adamant on a dynamic language you won't even be looking at C# or Java. It has nothing to do with the quality of the language, but the choice of programming paradigm.
Both C# and Java are quality languages. Given the choice between the two, I choose C# anyday. Sadly, this means Visual Studio... Resharper makes this slightly more tolerable.
That's the thing. If you're adamant on a dynamic language you won't even be looking at C# or Java. It has nothing to do with the quality of the language, but the choice of programming paradigm.
Both C# and Java are quality languages. Given the choice between the two, I choose C# anyday. Sadly, this means Visual Studio... Resharper makes this slightly more tolerable.
C# I can handle (despite coming to it late, as part of Unity3D), but I find Java more and more frustrating to work with.
To be honest, I think I'm just using it for the wrong thing - I don't tend to work on big, collaborative projects which is where Java really shines. Meanwhile, C# has a few conveniences (such as LINQ and rectangular arrays, off the top of my head) which seem to me to make scripting and small projects easier.
To be honest, I think I'm just using it for the wrong thing - I don't tend to work on big, collaborative projects which is where Java really shines. Meanwhile, C# has a few conveniences (such as LINQ and rectangular arrays, off the top of my head) which seem to me to make scripting and small projects easier.
> I don't tend to work on big, collaborative projects which is where Java really shines
What aspects of C# makes working on large collaborative projects difficult? Not sure where you are going with this.
Unless you meant Team Foundation Server / Visual Source Safe pukes.
What aspects of C# makes working on large collaborative projects difficult? Not sure where you are going with this.
Unless you meant Team Foundation Server / Visual Source Safe pukes.
> What aspects of C# makes working on large collaborative projects difficult?
None. I was just talking about my issues with using Java for small projects, not using C# for large projects. My argument is that C# covers scripting and small utility programs adequately, while Java seems to require more boilerplate.
C# would be my natural choice for projects large or small.
None. I was just talking about my issues with using Java for small projects, not using C# for large projects. My argument is that C# covers scripting and small utility programs adequately, while Java seems to require more boilerplate.
C# would be my natural choice for projects large or small.
I really feel like your idea of C# is based on C# 1. It's at version 5 now, and many modern C# codebases are hardly more verbose than Ruby. Still slightly more verbose, because types, but it's really incomparable to Java these days.
These days C# has more in common with Scala than it does with Java, even if C# 1.0 was virtually a clone of Java.
[deleted](1)
I think it's just a matter of being used to it. I use c# with MVC on a daily basis and starting up for me it's extremely easy. If I use Rails or anything else that people consider fast or w/e, I find myself extremely awkward. I can do it, but it takes ages to setup and everything. Instead of just going to IIS creating the website and creating the project in VS, that btw is the best IDE I have ever used and it's almost impossible for me to use anything else.
> ignores the quality of the language ... just prefer whatever dynamic language they're comfortable with.
"quality of the language" is not the same as the "dynamic" vs the "statically typed", "strongly typed" or "compiled" nature of the language.
Strongly typed languages have definite advantages because of the type guarantees that they provide in any successfully successfully compiling program. They have disadvantages too as you mention.
Nevertheless, many people feel strongly that where a strongly typed, statically typed, compiled language is available (i.e. not in a browser) it is an advantage to use it. And compared to java, c# generally is more terse and expressive.
"Quality" is subjective depending on what you value. If you only hang with dynamic language people then yes, c# and java are not of interest to you. Don't mistake that for a quality issue, or a universally held opinion; it is a design goal and design philosophy issue.
"quality of the language" is not the same as the "dynamic" vs the "statically typed", "strongly typed" or "compiled" nature of the language.
Strongly typed languages have definite advantages because of the type guarantees that they provide in any successfully successfully compiling program. They have disadvantages too as you mention.
Nevertheless, many people feel strongly that where a strongly typed, statically typed, compiled language is available (i.e. not in a browser) it is an advantage to use it. And compared to java, c# generally is more terse and expressive.
"Quality" is subjective depending on what you value. If you only hang with dynamic language people then yes, c# and java are not of interest to you. Don't mistake that for a quality issue, or a universally held opinion; it is a design goal and design philosophy issue.
Our startup's backend is made in C#, and we're very happy with the choice. We use Postgres, we host it on Docker containers on Linux, and our devs are equally spread over Windows, OSX and Linux. MonoDevelop is a remarkably great IDE for something with so few users, for example, and great open source like Dapper and ServiceStack.OrmLite make it super easy for us to interface with Postgres and use all of Postgres's unique features (Json as a first class data type, multiple-cursor result sets, stuff like that).
The author seems to propose "get all the free Microsoft goodies when you start, and once you really need the paid versions you're probably successful enough that the cost doesn't matter much". It is Microsoft's strategy that companies do this, and it's a valid one, but it's really not what I would do. Microsoft might've become a whole lot more open these days, but tying yourself in so much with a single provider sounds, well, dangerous no matter what.
For example, if you develop your C# app for Azure, moving to a different provider is a lot of work (much like if you want to move your Rails app away from Heroku, but with less open source out there to ease the road). If you develop your C# app to work platform-independent (or at least cloud-provider-independent) from the outset, then you're free to move whenever you want.