What technology should your startup use?
matt.aimonetti.net
matt.aimonetti.net
In any case, I'm not sure that many (any?) product needs could dictate choice of language in the vast majority of cases. Yes, if you need to do a ton of realtime stuff then maybe think about Node etc., but most people want the same standard stuff.
So you can use that method when hiring the first developer.
When it's time to hire the second developer, are you looking for only developers that are comfortable with the same languages as the first developer? If so, you are hiring developers based on language, and no longer following your advice. If not.... then you get a bunch of developers comfortable with different languages, and now what?
Often the answer might be "good developers can learn to be effective at any language." Which while on the whole (if not always) true, nevertheless only sometimes works for an enterprise (sometimes you don't have time to wait for them to learn it). But even so, now that turns into different advice: Hire your first developer, have her use a language she's comfortable with, then hire subsequent developers that either already know that language or are capable of learning it, and have them learn it. Which doesn't sound quite so obvious as your original advice, although it's not neccesarily an unreasonable approach.
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.
"Never use a new language for the first time for a project you love or that's important to you - you'll end up hating both the language and the project."
> We have a better IDE than the Java guys
Biased Java guy here. Completely disagree. Yes VS lets you build nice UIs with drag and drop. But if you compare bare bones Intellij IDEA to bare bones Visual Studio, Intellij IDEA wins everywhere else. All things being equal (that includes programming languages), you can be more productive in Intellij IDEA because its got the fundamentals down and has intuitive shortcuts for doing everything.
Of course I haven't used VS for about 5 years. Keep that in mind. But back then IDEA was light years ahead and .NET devs still thought VS was better.
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.
Those who only occasionally use Java when they have to... tend to find maven incredibly confusing to get working properly.
I wouldn't call myself a Java lovers as I'm moving away from Java lately but so far I haven't found a comparable tool to build+dependency that Maven provides nor I have found a good ecosystems that adhere to non-breaking fundamental building-block standards (Servlet, JSP, JPA2, EJB3-lite, JMS, etc).
Yes, Maven could be painful to start with especially without someone who had previous experience on your team but feature-wise, nothing competes with it yet. Ruby needs RubyGems and Bundler (and Rake to that extends) to compete with Maven. I heard the philosophy of "Do one thing and do it well" but if you're using those tools altogether every time (Rails) then what's the point...?
Sure, and Java needs maven to compete with RubyGems and Bundler.
?
Oh wait, you think it's significant that on ruby it's two cooperative tools with two different names, compared to one tool on Java? I don't see how that matters too much in practice. (But it does, in real life, is it really just maven, or is it maven, and definitely ant, and maybe ivy too? heheh.)
I will admit that I find bundler a lot easier to use than maven, but I'm definitely a rubyist more than a javaite. I _think_ that someone who only occasionally needs to use ruby will find bundler easier than someone who only occasionally needs to use java will find maven. But maybe that's just my own prejudice, I could be wrong there.
Maven = Bundler + RubyGems + Rake
Maven = Ant + Ivy
Maven = not-sure-what-the-equiv-in-python (pip is more along rubygems?)
I don't think Maven is easy to use if you have to write from scratch (you need an IDE or something to generate the initial POM first ).
I'm also questioning if it's necessary to have RubyGems separated from Bundler when in real-life, you'd almost always use both anyway (along with Rake) to have a more productive workflow.
Don't people similarly often use ivy _with_ maven, as an extra layer that makes certain aspects of maven easier? Maybe I had that wrong. And I thought maven use almost always included using ant. Maybe I had that wrong too. So not a java guy.
Ah, from the Ivy project's own documentation, sounds like I did have it wrong:
> First, the most important difference is that they aren't at all the same kind of tools. Apache Maven is a software project management and comprehension tool, whereas Apache Ivy is only a dependency management tool, highly integrated with Apache Ant™,
That does make it seem like maven isn't neccesarily the "do one thing and do it well" tool you were suggesting it was though! That might be more what ivy is trying to do?
Many people keep saying that Maven is a bloated software but the Maven core itself is rather small, everything else is a plugin.
Compile Java? Plugin.
Compile Scala? Plugin.
Unit-test runner? Plugin (surefire).
WAR packaging? Plugin.
Run your CSS/JS via YUI Compressor? Plugin.
The reason why occasionally you see ANT TASK inside Maven may have something to do with the situation where there's no Maven plugin for that particular task and there's already an ANT TASK for that particular job so people just call that ANT TASK from within Maven. All these tools can work together nicely.
BTW, executing ANT TASK from inside Maven? that's a Maven plugin.
So Maven does one thing and do it well: orchestrating plugins. Each plugins does one thing and do it well: solve a particular need. It does make Maven look bloated because it gives the illusion that Maven does everything... like your Operating Systems.
When people refer to Apache Maven as a Software Project Management it is because it can also generate a website for that particular module/sub-modules/the whole projects.
Example of generated Maven websites:
So you can put everything under your source control and have them build by maven to generate a complete website + documentation + javadoc + release notes for your modules/libraries/javadoc along with other goodies as well (code-coverage result as part of your project website).
Example of the goodies that the maven site plugin can generate:
1. Display dependencies of your libraries/projects
http://mojo.codehaus.org/cobertura-maven-plugin/dependencies...
2. Project reports
http://mojo.codehaus.org/cobertura-maven-plugin/project-repo...
- Checkstyle report (does your code violate any coding rules?)
- Cobertura => check the code coverage
- Javadocs => brings you to the API
All the links in project reports are generated by "mvn site" command and the availability depends on whether you install the plugins.
For example: VS.NET Express does not allow you to have any plugins (or used to, never checked anymore) which means you can't run your NUnit from there and expect code-coverage instantly show up once you ran them.
Their NuGet solution somehow seems limited compare to Maven eclipse plugin where it can download the JAR, JavaDoc, and Source if required whenever someone needs to navigate the source code of 3rd-party lib.
As for NuGet, as soon as you build, all code, docs, etc are right there and it's up to the creator of the library to have created the info. It manages versioning and updating for you as well.
http://blog.davidebbo.com/2011/04/easy-way-to-publish-nuget-...
Unfortunately the whole debate of OSS vs Proprietary does matter when it comes to "which tools is better". I know it'll never end but it affects the playing fields.
The fact that you can get up to speed very very quickly without spending money or talking to Finance, MS Sales/re-sellers using Eclipse+plugins and Java+OSS libraries/frameworks that were more mature is probably a significant point on this debate.
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
I don't see what a lack in .net experience has to do with anything. I'll be the first to admit C# is a better language than Java. This is a comparison between two IDEs. I've used both. I was shocked at what VS couldn't do.
Back in 2008-2010, I used Eclipse exclusively with Maven (and m2clipse), FindBugs, Checkstyle, PMD, Hudson (Jenkins nowadays), Spring, GWT, with some exposure to HBase and Hadoop. I never had to wrestle with any licensing issues at all. If I want to use something I would go to the internet and download them (IDE, plugins, tools, libraries or whatnot). They're also high-quality grade tools and not toys or something with serious limitation that forces you to buy the commercial offerings.
Feel free to invalidate my opinions. Love to see a better version of NuGET. Love to see VS.NET Express to support plugins. Love to see what great cool plugins exist for VS.NET. Love to see any heavy-weight framework/libraries from .NET that are being used in large-scale and in may areas. It wouldn't hurt if you can list them here for the benefit of everybody else as well.
PS: Mylyn is a very underrated tool. I heard they're going to port Mylyn to VS.NET but haven't seen it from their product page yet as of today.
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.
1. I compared bare-bones IDEs because I know resharper levels the playing field.
2. When I said, "All things being equal (that includes programming languages)" I meant I feel that C# is a better language, but I'm choosing to ignore that so I could compare IDEs apples to apples.
2. Click on the Products menu
3. Click on Express 2012 products
4. There is no step 4
To get the other software free, you need to sign up for BizSpark (which requires jumping through a few hoops). http://www.microsoft.com/bizspark/
The express apps should be sufficient for building apps (I'm using them for a desktop app right now) and should allow you to learn the Microsoft stack with minimal effort.
The Express products are completely functional although they lack certain non essential features. The main limitation of the Express editions is that you can't use third party plugins with them. Third party plugins are used to enhance Visual Studio itself and are not to be confused with third party libraries which you can download conventionally or with the built in package manager Nuget.
The Express editions are distributed by task so you only download what you need. If you don't want to create Windows Phone apps, for example, you don't have to download that functionality.
To develop web apps you have to download Visual Studio Express 2012 for Web.
http://www.microsoft.com/visualstudio/eng/products/visual-st...
It allows you to develop ASP.NET MVC and ASP.NET WebForms apps with C# or VB.NET right out of the box but you can also use it to develop web services with WebAPI, regular HTML5 websites, etc. And out of the box you can deploy by using FTP, WebDeploy and Azure but you can also use whatever external tool that you like.
The product includes a copy of MS SQL Express that runs as a process but you're not limited to using Microsoft databases.
Oh, no, you're definitely right about that. What I meant was weird was that nobody seemed to describe it in those terms, so I was looking for the wrong thing.
Thanks for the rundown! Now that I actually have some idea what I'm doing, I'll have to give it another go once I get a bit of free time.
Wait until your operation gets bigger and requires monitoring and all the goodies specifically for IIS/Windows Server.
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.
People either not aware or pretend not to aware or have their biases set already when it comes to Mono.
I'm not sure if people aware that the commercial entity behind Mono is focusing on Mobile heavily than enterprise and I'm not sure if these people are aware of the repercussion of that.
My comments are to highlight comments made by others too; that language and platform familiarity weigh very heavily in the decision process and that discounting the entire Microsoft ecosystem based on licencing is not a cut-and-try process as it perhaps once was.
The ecosystem is diversifying and growing. It may not be as mature, advance, diverse as other platforms but for those already familiar with the technology it is a viable option.
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.
[0]: http://matt.aimonetti.net/posts/2013/08/27/what-technology-s...
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 :)
Her "how much pain and when" I think implies that she only accepts concurrency as practical when units of concurrency are isolated as that would reduce the number of shared data structures being updated, lock contentions and so on. There is some truth in there that I agree with.
But then again maybe she was just trolling. I for one do not like her tone her comment.
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/
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).
IMO, Groovy is absolutely one of the top platform choices a startup could make. We've been using Groovy and Grails at Fogbeam for 2+ years and haven't regretted the decision at all, FWIW.
If we're talking about Web apps, technology is much less relevant than the team's abilities. If you're also going for native apps, your options are mostly limited anyway (especially on mobile), but the same principle still applies.
Another reason for going with a familiar technology is that it will be easier for you to find future team members, as you will (presumably) already know the local community, thus avoiding what happened to Reddit.
If they ask "is it sane to use XYZ" I could give them some actually useful information, but sadly people often want to be given the answer rather than get advice.
I'd say this question ranks up there with "Can I ask you a question?" to which I usually respond "You just did...". If you want useful information, just ask for it, your friends and peers are not your parents.
NB: I ported a lolcode interpreter so I do actually encourage people to use it... sometimes...
Value is important. Say that about a thousand times. Once you are creating value, then you can write long blog posts about various tool choices -- or spend time reading them. Until then? These issues are so trivial as to almost not be worthy of discussion.
The interesting thing is that this is exactly backwards from the way most folks are taught programming. You pick the tool first, learn it's secrets, then set about making someone happy. This is a great paradigm if you want to be a corporate programmer, but if you're looking to form a startup you've got the cart in front of the horse. Sure, bring the skills to use all kinds of tech. But don't spend a millisecond focusing on that crap when nobody wants what you're offering.
A lot of guys who say they're in startups are like a severely overweight and out of shape guy who sits around reading running magazines and ordering expensive gear. Yeah sure, that stuff can be dreadfully important. But only in the context of actually doing something. Otherwise it's just bike shedding.
You really nailed it here. I really like the language but I really struggled with debugging code and I'd shit my pants every time I refactored.
I had a much nicer experience with Haskell: If your code compiles, it probably works. With Clojure: If your code compiles, it probably doesn't work. I'll tell you something's wrong, but you'll spend most of your development time discovering the cause. That's very frustrated. But to give Clojure the benefit of the doubt, I never felt like my development pipeline was efficient. Unfortunately, I couldn't find a canonical example of a good development pipeline.
Edit: I would also disagree with the language being complex. I think the only languages that compete with its level of simplicity are mostly other lisps/schemes.
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.
This is actually a fantastic way of looking at it. All programming languages have philosophies, and certain "cultures" that they bring along with them.
It's important to realize that technology choices are not just about the technology.