What technology should your startup use? (opens in new tab)

As long as the .NET guys don't have Maven they can't win.

I can check-out a Java project that contains pom.xml using the big 3 Java IDEs out there (Eclipse, IntelliJ, NetBeans), compile, build, run unit-testing, integration-testing, navigate my codebase like crazy.

But you know, I'm gettin tired singing the same choir of Java. .NET guys can sing how great their C# languages and VS.NET are but we know Java ecosystems win hands down End-To-End; we got it cover from distributed systems, big-data, enterprise, "service oriented", dependency management, build, validation (findbugs, checkstyle).

Eclipse + essential plugins are more than enough for me (albeit I'm using IntelliJ these days) and it's free.

We don't really use designers anymore outside of quick low volume enterprisey data driven apps. It's all about the MVC3/4 and EF5 (6 soon!) stuff. We have Resharper now, made by JetBrains, the Intellij guys, and it kicks total ass. Refactoring is a breeze, and it really helps with dealing with legacy code.

I was reared on Java, but at this point I don't think I could go back. C# is just so far ahead of java in terms of language design and features at this point, and Linq is bloody amazing. It's far easier for me to transfer the ideas in my head to my C# code than pretty much any other language I've used at this point, excepting Python for simple algorithmic problems.

My first thought too, being an Intellij IDEA user (and mostly java developer) I was annoyed with that affirmation. I had the need to use Visual Studio recently and I can say it is still light years behind Intellij.

As someone who started using Java during college for a side job and after getting a job at the company afterwards switching to C# mostly: IntelliJ vs VS? IntelliJ wins (though VS got way closer). But with plugins? Or mainly one plugin: ReSharper (for those who don't know it's a plugin for VS made by the guys who make IntelliJ). VS with ReSharper has become my favorite IDE.

Both you and Edwin don't seem to have a clue what you're talking about.

Drag & Drop? Lack of end-to-end support? Maven?

Just all showing your lack of experience in .net

I wouldn't mind if they were decent criticisms but they're not

Agree. Discounting C# on prejudice against Microsoft "reeks". Ignoring the Bizspark programme, the Microsoft development ecosystem is now so large you can actually avoid Microsoft licences.

Look at the success of Xamarin moreover their tools that can be used to create systems in Mono in F#, C# et al hosted on Linux with Nancy behind Nginx using Postgres.

The OSS ecosystem is growing too look at Edge.js for a good example of some innovation where C# and F# can strengths can be utilised in conjunction with other ecosystems with more focus on web.

It may not be perceived as trendy but there's plenty of developers familiar with that ecosystem. If you're in London for example finding decent C# devs is not a tall order.

Well, the article is written from a web app perspective, in which there is a big scaling tax when you go MS (windows server and sql server licenses). I know there's bizspark but it doesn't cover growth hacking startups well(limited prod SQL Server use, 3yrs only).

I left the .Net world about 3 years ago. There were plenty of things to complain about, but licensing was never one of them. Most of the stack is free until you get to the point where you should be able to pay for it anyway.

Last time I dealt with Windows development (for the desktop) as a small shop, I was completely unable to understand the licensing. It ended up occupying a significant part of my attention.

I'm sure someone will just "lol, use your MSDN (or whatever it is now) subscription", and when you have that and it's being paid for that's fine, and the tools are nice. But it's way too much for small shops to bother with, IMO.

OP here, when you build a company, you need more than one person so you also need to think about your product needs (what tech better fitted) and who you will hire to help you build it.

Great comment, untog!

Getting something up & running is more important that everything else put together (except maybe determining what that something is.)

It's hard enough to get from "thought" to "thing" without worry about all the details. For an MVP, almost any technology can do almost anything you need. So just do it.

Although not ideal, you can always refactor, rewrite, rearchitect, or redeploy. But unless you have a time machine, you can't go back and do it again. So listen to untog and use what you already know.

Good question. Hopefully you have not been put off by that comment. It comes off kind of harsh.

She wasn't right about lack of concurrency. Go, Scala, Python, hell all of them I guess can do "concurrency". They all have facilities to launch concurrent requests/actors/callback threads/other processes.

Now maybe what she was going to say (and her "how much pain and when" kind of hints in that direction) is that once you start handling large scale concurrency, things get very complicated. Anything that lets you share memory will eventually bite you back in terms of debugging and downtime.

Erlang's concurrency is unique because its concurrency units are isolated. They are as isolated as possible. Each has its own memory. Garbage collection can happen concurrently. One such what they are called process will not damage or interfere with other processes. That is invaluable.

Erlang's concurrency just like (Go's and Rust's I think) is also a mix of both CPU and IO. So behind the scenes Erlang spawns an operating system thread for each CPU core and then it dynamically scales your concurrency units over them. You need to run better, just add more cores.

Another (and this should be the main differentiation) is fault tolerance. This was and is the raison-d-etre for Erlang. Nothing practical out there matches it. Processes can and will crash and Erlang has standard ways to supervise and restart. Even crazier it provides built in facilities to reload the code while the system is running. That is of course possible in other frameworks and languages but in Erlang is baked in and battle tested over many years.

That sort of makes Erlang a unique tool. It doesn't come without trade-offs. It doesn't for example has terribly fast sequential speed. So if your task is to multiply matrices for example, or computer lots of numbers. Erlang won't be the fastest in that regard. It is also a functional language. It is beautiful I think, especially if you like pattern matching, but some people don't like that.

But if you don't like the syntax, there is way out, the same Erlang virtual machine called BEAM can run other languages. For example a nice new one is Elixir http://elixir-lang.org/ check it out, it is rather similar to Ruby in syntax but includes all the concurrency features from Erlang.

As for resources I would recommend the wonderful and funny online book called:

Learn You Some Erlang For Great Good http://learnyousomeerlang.com/

"Erlang based systems obtain many of the aforementioned properties from the Erlang concurrency model. Erlang handles the concurrency itself instead of relying on the OS. A concurrent entity in Erlang, called Erlang process, is much lighter than a standard OS process or thread, initially using about 3 KB of memory on a 64bit system. In a typical Erlang systems, you can easily create hundreds of thousands or maybe even millions of Erlang processes. The Erlang virtual machine uses its own scheduler which ensures that each process gets a fair share of execution time. The scheduler also distributes processes over available CPU cores, using as few OS threads as possible (by default only as much as the number of available CPU cores)."

http://www.theerlangelist.com/2012/12/yet-another-introducti...

It is kind of like Node in that it is very easy to do concurrent stuff, except instead of nested callbacks and all that jazz, you write 'processes' which are designed to share nothing. They run akin to OS threads in that one process crashing won't bring down the whole system (unlike Node). As no state is shared it also means that they can easily (i.e. it is built into the VM, and switched on by default) be scaled up to run over many cores. If you are interested, you might want to look at Elixir (a language built on top of the Erlang VM) which has a more Ruby-esque syntax: http://elixir-lang.org/

EDIT: Should also point out that I think "Jessica's" comment was just trolling, however it isn't far from the truth :)

Erlang has a very nice concurrency approach, particularly if you are into distributed and fault tolerant systems.

But it's ridiculous to say that "only Erlang can do concurrency". Many other languages do concurrency very well in slightly different ways (Clojure, Scala and Go, for example).

Because Groovy has unfortunately turned into a mere appendage to Grails, with very little independent use, it's generally not considered as a viable standalone language by many people anymore.

The point about complexity is probably fair from the perspective of someone just getting started with Clojure.

Sure, the syntax itself is very simple and regular (like any Lisp). The complexity is in all the other stuff - macros, code-as-data, vars, namespaces, metadata, managed references, persistent data structures, leiningen, paredit etc.

Once you've got up the steep learning curve, I find Clojure is unbelievably productive. It's just a bit tough getting there. I think it's all solvable, but the Clojure community does need to listen and learn from constructive criticism.