F# for several reasons 1) Tooling, I like proper thick IDE's like xamarins or VS. 2) better platform support (I'm serious, it isnt tied so much to windows as you might think but is one of few languages you can e.g make a 3-platform mobile app with today!). Running Haskell in the same IDE with the same compiler on several platforms is hard. Making android/iOS or web apps with it is also tricky. 3) I like ML more than Haskell, 4) trivial to slap a non-functional C# front end on F# business logic should that be necessary, much harder to do from Haskell or ML without having to resort to C/C++.
Xamarin is really the "killer app" for .NET at the moment. Being able to use a common codebase for Windows RT, Windows Phone, Windows, OS-X, Android, iOS is amazing. Being able to do full native work on top of that on every platform. The apps look, feel and act native cause they are using native widgets.
Last I checked the F# supports was still a little crufty (over a year ago) -- but if they really get the F# support to be top tier, I will have to return and have another look.
F# has gone from tiny to quite popular (#12 spot on Tiobe currently), and that shows very clearly in the quality of tools and availability of libs now. It's not the same language/community it was a year ago.
By comparison, Haskell is 49 and no ML lang is in the top 50.
So I guess the (currently third place) "Other" is mostly PHP? I know it's not cool but it still seems strange to leave that popular and frequently used platform out of the poll.
"If, however, the variable has been used in only string contexts since it was set, and has a value that is not the empty string and matches the pattern /^[a-zA-Z][0-9]\z/ , the increment is done as a string, preserving each character within its range, with carry..."
So "0wz"++ becomes "0xa", "0xa"++ becomes "the hexadecimal representation of 10, plus one".
Man, Grails / Groovy never get any love from these poll authors! C'mon, Grails rocks people... :-)
Seriously, I switched all of our development from Java/Tapestry/etc. to Groovy/Grails a few years ago, and really couldn't be happier with the decision. Grails isn't flawless, but it mostly "just works" and makes my life SO much easier than before.
No, it isn't the "flavor of the day" like node.js or what-have-you, but it works, it stays out of the way, and gets the job done. And it lets me leverage the decade plus of experience doing Java that I previously experienced. What more could you ask for?
I chose Scala/Play framework for the same reasons. Java might be awful, but the JVM is a beast.
>Though my tip though for the long term replacement of javac is Scala. I'm very impressed with it! I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy.
-James Strachan
As someone who is trying to swing back to the new world of JVM development (my last effort was Spring and J2EE 6 years ago) just curious who is going to win out?
I'd also put my 2ยข out for JRuby. It's amazing how nice it can be to have Java libraries mixed in with Ruby on Rails, and your only penalty for it is a delayed startup cost (with potentially faster JIT to boot, and new Java 8 scripting performance to look forward to).
I have really only experimented with Scala, so I'm not in a position to really judge it. But my initial impression is that Scala makes it awfully easy to write "write only code" that no one else can read. The amount of optional syntax, and the multitude of different ways to do the same thing, doesn't sit quite so well with me.
OTOH, I have generally been a fan of languages with static type systems, and I believe Scala tends to be a bit more performant than Groovy. I'll probably revisit Scala at some point, but right now Groovy is working really well for me.
20 days ago: https://news.ycombinator.com/item?id=7278426 "Assuming there is a next startup and it's anything like the current startup, then I'd probably go with Groovy again. Groovy has worked very well for us."
2 months ago: https://news.ycombinator.com/item?id=7042329 "We've been using Grails and Groovy extensively (almost exclusively) at Fogbeam Labs for about 3 years now, and I am very happy with how that decision has worked out"
2 months ago: https://news.ycombinator.com/item?id=7013785 "Anyway, if you already know Java and have some familiarity with that world, I can't recommend Groovy and Grails highly enough."
2 months ago: https://news.ycombinator.com/item?id=7011934 "if you asked me to write a non-trivial program starting today, and I had to optimize for productivity, I'd pick Groovy."
Heh, that's interesting in a sense... especially given that I'm not involved with either Groovy or Grails projects in and of themselves (eg, not a committer / contributor to either), just a happy fan.
I do find it curious though, that you took the time necessary to look all of that up and post it. I'm sure every language has a handful of people who are particularly vocal about their support for it. :-)
> you took the time necessary to look all of that up and post it
Less than 5 minutes work. Having remembered many similar comments from you in the past, I used the search field at the bottom of the page, searching for "groovy", clicked the "comments" and "sort by date", then used the browser search function to jump to references to "mindcrime", cutting and pasting, then editing.
Don't get me wrong, Groovy was (and likely still is) a very pleasant alternative to boilerplate laden Java, but the lack of static typing and runtime MOP magic was, in hindsight, more hindrance than help.
Agreed re: many ways to do one thing, Scala's no Python ;-)
Readability is a matter of experience. From the outside looking in some Scala code may look fairly dense, but the same can be said of Haskell. Groovy wins in this department, no argument there, any Java dev can grok Groovy.
Watching these answers stream in on the spreadsheet really makes me think of what a realtime reddit or stack exchange could look like. Adding live interaction from observers (likes, comment streams, etc).
I am most surprised by the number of people who want to use Go. It isn't that Go isn't a great piece of technology but I thought it would be really difficult to hire for and seems a bit overkill for an MVP.
Depends. If what you need to build is actually a simple interface between database and front-end over an XML or JSON API, Go's not that much heavier than the alternatives, with the promise of more performance in the future and with less code than many other libraries require. Plus if you host on Google App Engine, it's free to start. Even the HTML templating has built-in context-aware output filtering for XSS prevention.
That said, Rails, or any language developers are more familiar with, can be faster. At that point, I'd argue even static HTML pages might be one of the fastest MVPs to put together...
For small stuff, their entry level 5$ a month droplet is perfect and pretty much beats anything else I've come across. Having SSD backed storage is nice too.
Why is that? My motivation for picking Android is the larger market share. Even if you have engineering preferences, to me what really matters is getting it out in front of a wider audience.
What markets are you trying to get more in front of? US? Europe? China?
What device levels are you trying to get in front of?
Android seems like a "no brainer" until you start looking at the details... For example, if you cut out all "cheap shit 2.2 android devices" and focus on new(ish) Android 4.0> things get REALLY murky... In the US iOS still holds a lead over Android in those markets; in Europe Android is ahead, but then you have localization to deal with.
Additionally, Android might have an edge in some markets, but the fact that iOS users actually PAY for apps also makes a big difference.
The point is that Android is a sensible choice but it's not an automagic choice, nor is it as cut and dry as it appears.
It really depends on your user/customer. If you have a app that targets a specific customer profile, then the larger market share is not as relevant. You need to try to identify your customer, in specific terms, and learn what kind of phones these people tend to use, among other things.
Is your app primarily for middle-aged women (mom's) living in the U.S.? Is it for teenagers and young adults in the UK? The more specific you can get with your customer profile, the better your decisions will be. The makeup of some user populations can be very different than the broader market. It would be unfortunate to invest in building an Android app, only to find that your soccer-mom customer base runs 80% iPhone (just an example).
Well, I voted twice on the same IP so maybe the results are meaningless. But considering HTML5 > native, iOS is more like 1/4th of the pie.
Objective-C is not a language option, but maybe because it's not a backend language? If iOS/Objective-C people voted for C++, they only have 3% now. So ~25% people want a fantasy iOS app but only 3% know native iOS = Objective-C?
16% of people think Javascript is a backend language? Hope those are votes for Node.js?
I actually prefer Android as a user. But if I'm building native (instead of HTML5), it's because I want a polished UI, and that is easier to deliver on iOS where there are only a handful of devices to test against (in particular screen resolutions). Assuming the app goes well on iOS then I'd happily take on the extra effort of an Android version.
There was a lot less dithering over proper database design; I just created objects in code and stored them wholesale. Aside from some administrative details/learning (zero knowledge going in), I spent far less time worrying about Mongo and more about my code, none of which has to do any manipulation of the database.
On the code side, I already know JS pretty well, though mostly from a UI-manipulation side. It was more like extending knowledge I already had, than having to learn something completely new. The slowest part was trying to determine which modules met my needs, then sorting through the myriad of somewhat confusingly- (or just plain badly-) written documentation.
The best part was being able to use the same language end-to-end. When I deal with PHP, there is always some context-switching between it and the other parts. This project flowed much more naturally and left me quite enthusiastic about whatever the next one is (I get a lot of latitude in devising solutions).
Some of the code is probably badly-written and I'll spend some time cleaning that up (first project in Node) for an update and there are still a couple of parts to write (shell scripts, mainly). There's also one key part that no-one seems to be able to solve (MD5 in Mono won't match the MD5 from JS), but we'll figure that out as we can ignore it, for now.
Really, given all the interruptions I faced during the process, going from zero to finished in two weeks of eight-hour days (including having to learn some things) feels pretty good.
The same project in PHP would have taken about the same amount of time, without having to learn new things. Admittedly, I'm a slow coder because I want to make it right the first time so I don't have to f* with it later, not just have a running solution. I'm not as thrilled with PHP as I used to be and half the time, I feel like I should reinvent the wheel, rather than just using a lib.
That's my informal review of the experience. Take it for what it's worth.
Disappointed Windows Azure isn't listed. Ignoring the anti-anything Microsoft crowd, it's a stable easy-to-use reasonably (at least competitive) priced platform.
I wouldn't limit myself to one language or framework, in reality.
Growing very fast? Python, with C for high-performance components. Python's got great libraries for everything, and hiring Python and C programmers wouldn't be hard because those languages have a lot of users.
Growing typically fast? Clojure. Drop to Java if needed for extremely high performance demands, or if I need to hire fast.
Growing at a leisurely pace? I'd be tempted to try Haskell (and possibly switch to Clojure). It's badass, it'd be fun to learn, and some of the smartest people I know are big fans of it. However, with the "leisurely pace" (R&D) I'd be tempted to hire people only as smart as I am and let them use whatever they wanted.
If I were to start my career from scratch in 2014 I'd pick F#, and keep an eye out for Rust.