Haskell is not only for surpassingly intelligent people, or even optimized for them. If anything, it's the opposite: one of its core tenants is that we're not smart enough to reason about our programs in most languages. Much of the design work focuses on unloading complexity into the language, tools and abstractions.

Haskell goes out of its way to prevent common errors and help you design your program. In a very real sense, it trims the "search space" of possible programs, helping you zero in on a reasonable solution. To an extent, I use Haskell because I'm not smart enough to use C.

Haskell is unfamiliar. And people mistake that for some sort of innate difficulty. But the two are not the same.

I would argue that overcoming unfamiliarity is one of the most important ways to grow as both a programmer and, more generally, a person. That's why I think the article focuses too much on choosing a language that's familiar, codifying it as "just about all the good advice". This mindset is far, far too exaggerated in most programmers, and its what really slows down progress, especially for popular programming languages.

The blub paradox is also a bit misrepresented. Being a "blub" programmer is not a matter of being more or less intelligent—it's a matter of not knowing what you're missing. "Beating the Averages" is not "we used Lisp because we were smarter than you"; it's more like "we used Lisp because it offers some incredibly powerful tools that non-Lisp programmers have never used and so do not really appreciate". It's a matter of habits and experience, not intelligence.

My advice? Do try something unfamiliar. Especially if it seems to be higher in the great partial order of programming language power :).

Which brings up another point: if we're talking about web frameworks for the next decade we should really be looking at service-oriented architectures / single-page apps or whatever you want to call that model. It's quite different from the web frameworks of yesteryear that generated UI on the server. Dropwizard can do web views but it really positions itself as a REST service framework.

So, that brings javascript frameworks into the consideration. And the author has a paragraph where he just dismisses it as a "terrible hack"...??? I think that is going to seriously hamper the outcome here. It's good that modern web apps leverage the power of the browser and JS frameworks are the way to do that.

I really think the author is missing out here - for the sake of just sticking with what they know and not wanting to do any actual research, it's impossible to come up with an actual objective choice. So misinformed, I get that .NET/C# development is not everybody's cup of tea but I think it's crazy to title an article "Choosing a Web Framework/Language Combo for the Next Decade" without even evaluating an extremely popular option due to simple disinterest. The lawyer comment is just irrational fear (and I get is probably meant to be a bit of a gibe towards Microsoft's licensing schemes), unless you're writing something completely from scratch, you need to be aware of the licenses of ANY library/framework you depend on, even if they're free.

Anecdotally, I agree with that. I once built a product on GWT because it impressed me so much on paper. Static typing, compiling permutations of your app and loading only what's needed, optimization of stylesheets, rendering only on the client etc. It seemed perfect. IIRC the two main issues at the time, a few years ago, were a) terribly slow tooling for any decent sized app and b) the usual interface-hell of Java. This may not be a problem if you're used to it, but for me it was an issue.

This is no longer a problem in Python because of virtualenv and pip, which together allow you to tie down the version numbers of all the dependencies an application uses.

The lead developer, Qiang, is literally the second most active developer on github[0], so it's not like they're not trying - the guy is currently on a 370+ day streak - it has taken a huge amount of effort for them to get to this stage.

I would personally build on the beta at this point because I have a lot of faith in the core team and they've had a lot of time to iron out any major problems, at this stage any changes are likely to be quite minor or fixes, so the real release will probably ship before your new project does.

Kohana seems dead and CakePHP has historically been rather slow and ungainly.

The lack of library support for Lua is a bit annoying, but it's getting better and can possibly be mitigated by using Lua's FFI to talk to C. If the eco-system was a bit more mature OpenResty[1] would be pretty compelling.

0. https://gist.github.com/paulmillr/2657075 1. http://openresty.org/

Rails is pretty much the premier MVC framework. If you are going to go MVC, go with Rails. If we are looking for an alternative to Rails, then we are probably looking for an alternative to MVC, and none of these mentioned choices fit the bill.

I wonder when the day will come that we finally get sick of recreating all the libraries that typically go into an MVC framework. That day, Rails will still be going strong and we will probably give up and just go with Rails.

Of all the choices mentioned, not many have been around as long as Rails. For every day that Rails survives, the stronger it becomes. The more likely it will continue while the alternatives shrivel.

One day MVC may become obsolete, but some people might still want to use an MVC framework for whatever reason. That day, Rails will be there waiting for you.

Years ago, I watched the video on how to build a blog in 10(?) minutes. Today, I can still somewhat follow that video. With many of the MVC frameworks in this list, you couldn't do that. ZF1 is not ZF2 for example. The framework was completely changed. They might as well call ZF2 by a different name. If it were called anything more interesting than "Zend Framework" then maybe it would have a different name.

Go is interesting, but the MVC web framework ecosystem has to be created, just like we did for Node. I don't even know if that will happen anytime, or ever. Maybe people are getting sick of doing that. And then you need to wait X years to see if something actually has any lasting power.

Screw it, just go with Rails.

Or Django. ;)

I now rather like significant whitespace and often find myself considering that my ideal language would probably be half way between Python and Lisp.

The dismissal of Python and not Ruby over arguments of slowness of execution and dependency issues seems backwards to me.

The main reason I choose Python is because I can jump into a codebase that is years old and immediately understand what the code is doing. Brevity and readability trump just about everything else for me. I also like the pluggable nature of the Flask ecosystem.

Dismissing python due to maintenance difficulties and not Ruby seems weird. Both are highly dynamic languages with not much help from static analysis, and this is for me the reason why maintenance may be hard.

The fact that whitespace was an issue to OP probably means he never used PyCharm. I haven't had any single syntax issue since I started using this IDE.

- Dropping JBoss Seam as a framework was a good choice because the important parts of Seam have been added to the JavaEE system, which provides an end-to-end set of technology specifications. If you choose to run a Java Application Server (such as JBoss EAP, Glassfish or Wildfly), then the server will support the full set of specifications, but you don't have to use them. Since JavaServer Faces (JSF) is one of those specification, I'm not really surprised you hadn't heard of it ... it's essentially JSP with lifecycle control and data-binding.

- GWT is indeed a Java technology, but it produces client-side code. For big projects, I generally use GWT with Bootstrap to generate the client. It compiles into Javascript producing several versions optimized for different browser groups. Using Martin Fowler's Passive View pattern, it's easy to write fast tests for your client-side business logic, and since it's typesafe, you get compiler errors before the compilation to Javascript instead of the run-time errors you often see when writing in Javascript (or Coffeescript). Since I generally write the back-end for a generic JavaEE server, I also tend to use REST calls from GWT to an Application Server for client-server communication.

- If you're looking for an ORM, none of the Java frameworks will include one directly, but it should be pluggable. When people talk about Java web frameworks, they're often constrained to just the "View" tier. Spring provides a much more full-featured stack (with DI and JPA) and is more analogous to JavaEE as a whole. I think you should consider those two as the full-stack contenders in Java. You can add GWT onto either if you need a client-side Java technology (I'm sure you'd NEVER use Java Applets for the client side right?).

- I happen to like Scala and appreciate how purely it seems to add a syntax to Lambda calculus. Martin Odersky's "Principles of Functional Programming in Scala" on Coursera was a great class, but I'm hoping the Scala IDE advances quickly. I'll admit I've never written production software in Scala (or using WAVE) but I also admire one project that's using it successfully (https://github.com/takezoe/gitbucket).

Starting at the framework end doesn't help me much. Instead I go with the people I have for the project and the things I want to do/validate - and start looking for what gets me progress as quickly as possible.

Express [1] has been the dominant framework for Node.js since 2009-2010. What frameworks are you talking about?

[1] https://github.com/visionmedia/express

Once it does that, I don't think there will be any doubt in anyone's mind that Go has less chance of survival than say Java. In fact, Java will immediately lose confidence once Android drops Java (in a reasonable 3-5 year timeframe).

Symfony dumped all symfony1 users up s* creek when Symfony2 came out; Zend framework 2 is an entirely different beast to ZF1...

Are these mature frameworks any more stable than the new ones, or are they new frameworks, phoenix-like in assuming the name of the old one?

To be honest I still don't see any compelling reason to switch to anything else in 2014, but if I was looking I'd be strongly favouring Go as the language, as it seems like the preeminent forward-looking, popular-ish, well-supported language. Rust and Erlang would also get a look in.

Yes, Laravel does have a high "bus factor", but for me personally its the number one choice in terms of ecosystem, features, support and community,

[1]: http://blog.paralleluniverse.co/2014/05/15/modern-java-pt3/

[2]: http://zeroturnaround.com/rebellabs/the-curious-coders-java-...

[3]: https://www.youtube.com/watch?v=ygW8fJVlDxQ

I recommend that you take a second look at Scala. Considering that you "have a working knowledge of Java (but really don’t like it)", I think Scala is a good choice.

The usual cliche-but-true reasons:

A. It runs on the JVM, arguably the most performant VM.

B. It has mature, huge (Java) ecosystems. High quality IDEs, rich (3rd party) libraries, a plethora of build tools (for better or worse) and profilers.

But for me personally, the things I like about it:

1. I can use different languages (as long as it runs on the JVM, obviously) for different needs. Probably not wise to mix a dozen languages (http://en.wikipedia.org/wiki/List_of_JVM_languages) in a project, but at least I have a choice.

2. Since I'm a Java developer during the day, I can reuse my skills (can use same framework, same debugging approach, same build system).

3. I can start coding with Java/imperative style. When I started learning Scala, I literally coded like in Java, minus the semi-colons. Over the time, I enhance my coding style because I keep thinking, "There's gotta be a better way of doing this." At least this lowers my barrier to learn Scala.

EDIT: IntelliJ allows you to copy Java code and paste it as Scala.

Obviously you can replace "Scala" with "any JVM language other than Java", but I have my specific reasons in choosing Scala (over, say, Clojure).

My criteria differed somewhat, but the gist was the same -- maximize your investment, position yourself well, and as Wayne Gretzky would say, "Skate to where the puck is going."

I'm in a rush to be somewhere, but here's a quick rundown of my key criteria for a 10-year language:

  1. Concurrency Model (we're in a multicore world)
  2. Data Processing (data is driving everything)
  3. Platform (cloud platforms are the new OS)

Python for its practicality, massive library in general and also in the data processing/data science space.

Clojure because of its concurrency model, first-class Java interop and thus massive library, plus its simple elegance and limitless potential appeals to the painter in me.

Go for its concurrency model on top of being a well-designed systems language that's backed by Google. I think Go is going to be the language to emerge as the dominant player in the next 10 years.

All three languages work on App Engine, and Google's Cloud offering is another one of those "skate to where the puck is going" things. It's already the most technically advanced cloud, and you can see signs that it's about to catch a Google-fueled hockey stick and blow past AWS at an exponential pace.

Honorable Mention: Scala.

Scala is in use by big companies like Twitter and LinkedIn, and it's the code behind some of the key open-source systems like Spark, Finagle, and Kafka. And Spark's the data-processing skate-puck destination: Cloudera is adopting it, and the days running up to the Hadoop eclipse keep growing shorter so I suspect Scala and I will keep crossing paths as these tools continue to make the rounds.

It's a good thing. By the looks of it, the community might be jaded in some way, which means no more running around trying to be the coolest /fastest kid in the block, mostly everyone just wants to get stuff done. The amount of useful gems and well-maintained libraries (years of being maintained, not just a few months) is amazing.

The language matured enough, and the ecosystem along with it. The ecosystem still has some flaws and voids here and there, but that's what makes it exciting in being part of it.

I don't use Tcl (not TCL!) anymore myself, but it'd be more honest to say that it's not that popular these days or not a language you happen to like. This is built with Tcl just fine:

http://flightaware.com/

With that out of the way, I think that was a good read, and a reasonable process. It's fair to be a bit subjective about some things, because... we're humans, and that's the way we are.

Personally, I use Rails as my go-to framework because while it's not super fast, it's very, very full of useful things to get up and running quickly, and keep iterating once things are built.

1. A awesome ORM 2. I could use Ruby for iOS applications(Rubymotion). 3. JRuby 4. Great for writing scripts and little one off things I needed to do. 5. Capistrano (although you can use this with any language) 6. Opal(although this really hasn't taken off yet). 7. People are actively trying to speed the language up. MRI, JRuby, Rubinius.

So I invested in Rails because of the other things I could do with Ruby in addition to web.

[1] http://leafo.net/lapis

This is all before the frameworks are even discussed, which are included and dismissed for reasons just as arbitrary. Smaller frameworks like Sinatra are discarded because they can't handle the complex logic that flash cards demand, Django's out because of the whole auto safety thing, and we all know that ExpressJS didn't show up at Jaques' birthday party that one time. Play's out because Scala is unfamiliar, despite that not being a specific quality of Scala and just something that's true in general of programming languages one hasn't bothered to learn.

So the final list contains some more PHP horror shows and a few Java and Go frameworks to make things look democratic. Thankfully, Rails makes an appearance, but it feels like this is just because it was lucky enough not to get hit by a dart.

Let it be a lesson -- we all procrastinate, but when you get to the point where you're writing blog posts about dozens of languages and tools, none of which you have direct experience with, the best thing is just to pick something, do what you'd meant to do in the first place (although you will note that writing the flash card app was itself a way to procrastinate on learning Romainian), and discuss the pros and cons of the tools you chose once you actually know what they are.

People are experimenting with new frameworks, e.g., beego, revel, martini, etc, but I don't think any of them are stable enough to meet your stringent criteria in that regard.

It seems to me (as an outsider looking in) that the Go community is relatively "anti-framework", instead preferring libraries, like Gorilla, for special oomph in routing or sessions or what have you.

I also think it's worth determining what you think the next decade's high level architecture will be: JSON api backends with fancy JS frontends, or more along the lines of standard Rails, Yii, etc? That will drastically change the type of web framework to choose.

It's actively developed (just follow the dev branch, which is quite stable) and the devs/community have been quite helpful. I wanted something much lighter than Laravel, but still have all the handy features, and that fit the bill. Based on your requirement of sheer usage numbers though, I don't know if it meets that (yet).

I'm not the only one who'd like people to choose frameworks and languages on something other than gut feel and googlefight results, right?

Finding Erlang programmers is admittedly more difficult, but finding someone willing to learn Erlang is not too big of a problem. It's also not a big deal to learn Erlang, because the language is simple.

As someone writing Erlang code for years, the good parts of using Erlang far outweigh the bad parts.

And the part about Python code breaking due to external modules must be a joke, right?! How hard is to specify a fixed version in the requirements.txt

Re: why there were so many "PLAY!" results in Google, that would likely depend on the query you use. Something like "play framework" would probably match for any page where someone said "I will play with this framework".

...which is another reason why "Go" was such a bad idea for a language name, BTW.

And while Grails today is a great servlet framework, Grails 3.0 will allow new application profiles, like netty, hadoop and batch.

Additionally, even though I'm not a fan of the following frameworks, but any java web dev know about jsf (due to being pushed as the "standard enterprise web framework") and vaadin.

What do you mean about Laravel's "bus factor"?

ORM, templating engine, community, it's all there.

Sure, there is no real hack framework yet.. but you could help build one. Plus, all your PHP frameworks will work fine in the meantime.

keep tuned I will write a similar back end post soon.

So Xamarin is Microsoft now? Better tell them, because they don't know it yet. Clojure is a .NET language as well by the way.

It's Javascript and Node.

Also, it could be foolhardy to pick just one for the next 10 years. When all you have is a hammer everything looks like a nail.

It might help to try to think of the specific constraints that you envision running into. How can your technology choice help address those concerns and simplify your stack or speed of development, or ability to hire talent? You should easily come up with over a dozen items that you will want to be able to address with your choice of technology.