I have been working with PHP steadily over the last year, and, coming from a Rails background (learned it at General Assembly), I used to hate the "ugly" syntax, weird method calls, and strictness of PHP (missing a semicolon can be damnable offense in the eyes of the compiler). Ruby to me seemed a lot more flexible, but over time, after hacking at PHP, I have come to appreciate it as a language that gets the job done.
My preference is still with Ruby on Rails; however, I have been thinking of using a more lightweight framework like Sinatra. I am still impressed with how flexible and expressive Ruby can be. Alongside bash, it has really become one of my favorite languages to work with particularly for scraping/writing automations.
Would love to get into Node, but the idea of javascript on the back-end hurts my head. All I have used Node for is for basic utilities like uglify-js and minifier. Been hacking on Angular and Mithril on the front end, I love javascript as a front end language, but still haven't wrapped my head around Node. Javascript isn't too far off syntax-wise from PHP, but my struggle with Node is how to organize the codebase as well as understanding a clean separation of concerns when it comes to front-end and back-end code.
Might be off topic, but I am really excited to see how the GraalVM is going to impact languages like Javascript and Ruby.
It sounds like they might prefer F# over C#. Also, if they're not willing to pull in the JVM, it seems unlikely they'd be happy about pulling in the CLR.
.NET Core makes the CLR dependency a little easier to swallow. It's modular, so you can only pull in the stuff (packages) you need. Cuts down on the bloat and "CLR kitchen sink" quite a bit.
Modern JVM based frameworks are far from being "monsters", and you have a lot, lot of choices! Many of them have an embedded HTTP server so they are very easy to develop and deploy.
It has static typing, limited type inference (function parameters need their types declared - by design - will infer otherwise), no JVM, and has several web frameworks. Not sure if any of them would be considered "good" by your definition, but check it out: https://github.com/flosse/rust-web-framework-comparison
But the number of web frameworks, etc. for Rust sucks compared to that of older languages like Go. Go 1.0 was released in early 2012 and Rust 1.0 in May 2015.
Rust is more verbose than Go, but Go's FFI to functions written in C isn't as efficient and since "cgo isn't go", I'm not sure cgo covered by Go 1.0 compatibility guarantee.
On the other hand, Go has tons of "batteries included" plus web frameworks so that is pretty awesome to have on stable platforms (I don't consider Windows a stable platform for Go and got burned several times, but Go works great on FreeBSD & Ubuntu.)
I suspect Go & Swift won't have robust reliability on Windows (compared to other platforms) but they'll be rock solid on the ones they favor. Rust may have better prospects regarding this, but Rust still too new this year for web server language -- wait until MIR is integrated and a couple more releases after that.
I will be revisiting OCaml sometime in the near future to write a more solid web framework for it (compared to OWebl). This time it will be based on FastCGI rather than doing the networking itself I think.
In the meantime, I'm more actively working on Ponyo for Standard ML right now. Take a look at the ponyo.org server[0] for a brief glance at what it can do today.
Check out the /r/sml wiki if you are trying to get started. And please join #sml on Freenode if you have any questions!
I've just started using D for this sort of thing. It has web framework called Vibe.d (http://vibed.org/). I'm pretty happy with it, and it seems to satisfy all of your requirements. Note that I've only just started to use it, so I don't know how well it will hold up over time, but I'm enjoying it so far.
There are a couple Haskell frameworks that might fit the bill. Yesod is a big one, although some take issue with its excessive use of Template Haskell. Others to look at would include Servant, and the very confusingly named rest framework.
PHP. It may be old, tricky to debug, and cumbersome to write long projects with but the ability to bounce in and out of logic on a simple, proven, well adopted stack that has plenty of knowledge-base and ready machines everywhere has it's advantages. Plus, I've heard a lot of developers knock PHP but I've yet to see a problem solved with Ruby or Python that couldn't have been solved with PHP.
After about a decade programming PHP, I'm now mostly using java 8 (play framework), with some node.js thrown in on the side. I've found that PHP's benefits are also its downsides. The simplistic concurrency model where every request starts from a blank slate and has no asynchronicity is easy to understand, but difficult to optimize for performance. The large knowledge base is great for getting a solution, not so great for getting the right solution. The "just keep going" error handling philosophy is excellent for newbie programmers, but terrible for guaranteeing correct operation. The interpreted zero-build dev model is excellent for quick edit-reload cycles, not so great for large-scale refactorings where you want to know you've correctly adapted all uses of a core api.
Java has improved a lot from what I remember it used to be. Java 8's elimination of a lot of the boilerplate, coupled with the simplicity of the play framework, and activator's hot reloading of code for quick edit-reload cycles brings it on par with PHP as far as developer comfort is concerned, at least for me. In my experience java is nicer for large-scale web dev, while PHP is nicer for a quick side project. Node with javascript I would put more in the PHP camp than the Java camp. It is great for side projects, but scaling it up necessitates switching languages to something like typescript with a whole-project build, which takes away much of the "ease" that something like PHP or Node provides.
Solving a problem and computing a function are almost entirely unrelated concepts. For instance, solving a problem usually takes the form of "write a system which can do X, within budget, on schedule, in a maintainable way, with integration with these services, with at least this much reliability." Out of that list, the only thing a function can compute there is to do X, once. And maybe not even that; functions can't even do I/O.
Unless you have developers who are super excited about writing web services via BPF filters, Turing-completeness is not a meaningful way to compare programming languages; that is, that's not the reason why we have multiple programming languages in the world and why different people or projects prefer different ones.
"I've yet to see a problem solved with Ruby or Python that couldn't have been solved with PHP"
Scientific computing is extremely strong in Python - numpy, scipy, scikit-learn etc - and a lot of it makes use of language features that aren't present in PHP (at least as-of a few years ago, my PHP experience is rusty at this point).
I saw it just now, so by now its already added and stands 6th most used (not bad for a relatively new language) for server side web development.
I like it a lot, have been using it since 2013. I bet its going to rise in usage.
A minor point regarding its name usage. We should always call it Golang on HN & comments etc or in searches, as 'Go' is such a common word. I always try to to a ctrl-f for golang. And I am sure many other gophers do.
Java and Groovy, mostly. More Groovy (via Grails) for web specific stuff, sometimes plain vanilla Java for backend services. Nothing is off the table though... I'll happily use Scala, C++, Haskell, Python, Rust, Go, or Intercal, if there's a good justification for it in a specific situation.
Now that Go has been added, I see a good amount of votes for Go.
Since we're talking about server-side web apps, I'm assuming this entails an HTTPS API endpoint, some datasource, and some business logic. What packages/libraries/toolkits to you use to build a (micro-)service such as this?
Python(Django and pydata stack). Most surprising to me, there has been a huge uptake of Python in my country (Kenya) this year. Ruby didn't win. Neither did JavaScript.
I use PHP for a long time. But now I see Python and JavaScript are the most used languages. I just wonder which one of them will be a true choise after PHP?
Both, neither, does it really matter? In my experience any server-side programming language will be good enough for 99% of the websites out there. Once you get up to the size of a google, twitter, facebook, etc. then you can start worrying about which server-side language you should use. Otherwise just use whichever one you prefer.
But the PHP looks like it's going to die. So how can you explain popularity of Python and JavaScript? PHP, Python and JavaScript; all of them can make same job? Any differences in performance?
Yes, they can all do the same job and for all practical purposes they don't have any difference in performance. Just pick whichever one you prefer. If you become the next google then you can start worrying about the performance of your server-side language.
Be aware that all of the frameworks are targeting Swift 3 right now, so it's a bit unstable until Swift 3 is officially released. But the ecosystem is going really strong =]
I'm using Vapor on a new project and I really like it. The biggest stumbling block at the moment is that the Swift Package Manager can't resolve packages having dependencies on different versions of other packages. I'm using Vapor with Zewo's PostgreSQL ORM, and upgrading either one is an exercise in frustration.
Despite the apparent lack of popularity, Groovy with the Grails framework is certainly better suited for web development than many (I would dare to say, most) of the programming languages listed above.
Of course, it also matters what kind of web development we are talking about. Is it web services or web applications? I think the requirements are quite different between the two.
After its leadership changed in 2005, Groovy was commandeered to be primarily a scripting language for Grails. A Ruby-like meta-object protocol was added to Groovy so Grails would be Rails-like. Groovy's never really broken free of this shackle, despite its failure around static typing and Android, or use for defining builds before Gradle 3.
With the exception of the blog. That is written in Node.js. I did that as a way to learn Node.js. But as soon as I find some time I'll rewrite that in Pascal too.
Here we go again with JavaScript. Can't wait for this cycle to go back down like it did back when jQuery and Node first came out and everyone jumped on the bandwagon.
After all this time it's still interesting to see how much hate there is out there for JavaScript even though it has proven itself a more that capable language across multiple platforms.
It's not so much the hate for JavaScript. It's the hate for the developers who know nothing about computing history making all the same mistakes as with any other platform while being so darned insistent that the world will run only on JavaScript any day now because JavaScript is the uber language.
You meet a young hip developer at the train station, the train is 8 minutes late so you have a moment to talk. They tell you they love JavaScript above all else, after a brief rant about how great lexical scoping and arrow functions are in ES6 you can finally get a word in edgewise.
What pieces of advice do you offer so that this poor child may avoid the mistakes of his forebears?
More than anything I would say stay slightly behind the hype wave.
Take two steps back and one can see the waves of hype roll through programming blogs, HN and reddit. 10 years ago people were arguing over ORMs. Then it was dependancy injection frameworks, then SQL vs NoSQL. Now there's JavaScript and it's various frameworks and libraries. THere's always so much hype about what to use that it's easy to lost in it and worry that if you aren't riding the trend wave, you'll drown. But most times it's easier just to float a while and watch from a short distance. Get done what you need to get done with what you currently know. Let the hype die down. Learning new things is a ton of fun. But they can be devilish to deploy in production. Don't feel like you have to use them.
Edit: I'm not saying DI frameworks, or ORMs or NoSQL (or even SQL) are bad in any way. Just that within each topic there was much arguing about what is "the best" or "proper" or whatever. Wait for that to cool off and die down before betting your next project on it.
They're not waves, they're cycles, with each successive generation rediscovering the lessons of the previous generation. I found it particularly amusing to see javascript front-end developers struggle with model/view binding strategies a few years back knowing that all of this was already hashed out by desktop developers in the 90's and terminal interface developers in the 70's. Still, react came out of that, and I don't think the desktop ever had an equivalent to react, at least not in the 90's. So every once in a while a genuinely novel idea pops up, but they're rare.
Citing Alan Kay on the difficulties of keeping up with tech:
We are fortunate that most of what is "new" is more like "particular 'news'" rather than actually "new". From the standpoint of actual categorical change, things have been very slow the last 30 years or so.
I wouldn't say components is the novel idea in react. For me the novel idea is continually generating the entire ui by applying functions to data. Previous component-based frameworks were about static declaratively-described ui's that where then bound to data, which is in many ways an inferior approach.
"developers who know nothing about computing history"
I guess it depends on what time scale you are using to define computing history. JavaScript hasn't been 'new' for a long time.
I've been a web programmer for about 20yrs and have used ASP, ColdFusion, Java, C#, PHP, and JavaScript professionally and for me it is the language I enjoy using/writing the most. It continually surprises with new and more powerful innovations and implementations: from the early days of DHTML to AJAX, closures, Node, React, Tessel, etc.
I'm curious as to what more would have to be done with the language for it to graduate to 'real' language status.
My preference is still with Ruby on Rails; however, I have been thinking of using a more lightweight framework like Sinatra. I am still impressed with how flexible and expressive Ruby can be. Alongside bash, it has really become one of my favorite languages to work with particularly for scraping/writing automations.
Would love to get into Node, but the idea of javascript on the back-end hurts my head. All I have used Node for is for basic utilities like uglify-js and minifier. Been hacking on Angular and Mithril on the front end, I love javascript as a front end language, but still haven't wrapped my head around Node. Javascript isn't too far off syntax-wise from PHP, but my struggle with Node is how to organize the codebase as well as understanding a clean separation of concerns when it comes to front-end and back-end code.
Might be off topic, but I am really excited to see how the GraalVM is going to impact languages like Javascript and Ruby.