For building a traditional monolithic website with server side rendering Rails and Django are far faster to develop in than anything in Go, Java or Node and the overwhelming majority of websites will never run into any performance problems with either.
> By way of contrast several years ago I benchmarked a real application hitting 1000 requests/s on a $20 per month Linode box
I have Rails applications that hit the database on every request doing 1000 rps on $10 a month Digital Ocean boxes. 1000 rps is not that much and all of these performance metrics are meaningless without extensive knowledge of how the application works and exactly what it is doing.
Erlang/Elixir is much, much faster than either Python or Ruby especially when it comes to workloads like your typical web app.
In the Techempower benchmarks the Phoenix tests had a ton of errors and there was no preview run so whoever submitted them wasn't able to fix them. Look at the error column. I assume they'll be fixed in the next run.
Honestly that site's benchmarks have never been accurate for me in production. But that's how benchmarks work I guess - my bad for bringing up benchmarks! My experience with using Elixir/Phoenix for web applications has been extremely positive performance-wise however, and has surpassed or matched Go, Ruby, PHP, and Python consistently in all production scenarios. For the latter three, the difference has been order-of-magnitude.
It depends on the problem domain as always. If you're doing a lot of naïve single-threaded number-crunching, have fun. But Elixir/Phoenix haven't failed me for web applications, even in very intensive situations. It's the first time I've barely had to do any tuning beyond external factors such as network and database queries (which, by the way, Phoenix's Ecto handles very gracefully and explicitly).
This is my experience with every Elixir/Phoenix app I've worked on thus far. I apologize if I made it sound like some sort of universal truth.
Most of those are optional libraries and rails does a hell of a lot more than a base install of PHP. PHP is also only "simple" if you ignore the god awful language semantics and inconsistencies of both the language itself and the standard libraries.
Yes. Most of the unnecessary complexity has just been moved from bad APIs with XML configuration to bad APIs with runtime scoped annotations, code generation and byte code manipulation. It's still a huge mess.
Yes you have. Jersey, Jackson and almost every Java database abstraction that's higher than JDBC uses one if not both. Dropwizard is one of the better Java libraries in this regard but it's still there.
There's quite a bit of magic under the hood of DropWizard (or, rather, the components that make it up). My experience has been that a developer using DropWizard will rarely, if ever, encounter this magic: they don't need to be aware of it. But if the veil ever slips, the sheer amount of ugly machinery will shock and horrify.
I can see that. We found that if we added the Spotify Docker Client to our test classpath we couldn't run the application from Eclipse anymore because our Jackson object mapper had the wrong Jersey modules.
This was because that package depends on a different version of jersey-jackson or whatever, which was discovered by classpath scanning, and so because Eclipse doesn't keep a separate test classpath, we'd be discovering a new MessageBodyWriter which Jersey would be using to override the Dropwizard supplied MessageBodyWriter, which would not have the appropriate Jackson modules.
Although it is very easy to add dependencies via Maven or Gradle, this does not prevent you from shooting yourself into the foot. You have to manage dependencies, including transitive ones. If the application has too many conflicting dependencies, then use classloader isolation (e.g. OSGi).
It is a littlebit sad, that there are no javac warnings enabled by default that at least check known classes for conflicts in the classpath. An IDE should do that by default, too.
Personally ,the worst I've ever run into is some hairy classpath issue, as one the children comments mentions. Although maybe I'm just lucky.
Where does bytecode manipulation or code generation happen in Dropwizard? Reflection for sure, but not any more so than any major web framework in a dynamically typed language.
Maybe you're referring to the SQL library they suggest (which I've admittedly never used heavily). But I don't see how you can have a SQL library without generating SQL.
I disagree. Dropwizard itself is really simple. The frameworks like Hibernate or HK2 are more complex, though. But there is definetely no magic involved.
Using Atom or VS Code instead of Emacs cuts my battery life by a few hours. The Spotify desktop app that uses a ton of JavaScript is also horribly inefficient and has a big impact on battery life.
On the other hand, my Emacs starts up in more than thirty seconds. To fully start up it needs to read some 2k loc of my own ELisp code and hundreds of thousands loc of required libraries.
I use Emacs as a Jabber client, Python and Clojure development environments, file manager, image and pdf viewer, HTTP server, spreadsheet and note-taking app and (polyglot) Literate Programming environment. And that's just the beginning of what it can be used for.
In other words, giving Emacs as an example of small and fast, natively written application is a bit unfortunate. Not to mention most of Emacs is written in ELisp, so the "natively" part is not even factually correct.
On top of this, chrome/chromium versus safari is another 1-2 hours of battery. I think people vastly underestimate the energy requirements of web technologies.
I've never successfully watched a video on Twitch. I get a black rectangle with playback controls, and when I press play, nothing happens. Disabling AdBlock doesn't help.
I don't have Flash installed at all. Does the site require Flash?
If so, then that's news to me; other video sites that require Flash usually a) show a "you need Flash" message in the place where the video whould show, and b) don't show playback controls, because they're part of the Flash component itself. Also, I never saw any mention of Flash in any of the site's help/troubleshooting/FAQ documents.
Since posting my last message, I looked at the documentation on the website again, and saw that it claimed that you could use the site on iOS and Android by just using an ordinary browser. So I tried visiting it in Safari on my iPhone, and the videos worked. Then I tried using Firefox on my Kindle Fire, and the videos didn't work. But they do have a dedicated Twitch app for the Kindle, so I downloaded that. So now I have a way of watching Twitch videos. :-)
The fact that Flash is not mentioned anywhere on the site as being a requirement seems like a glaring omission.
"ordinary browser" = Chrome for Android, latest version, Safari for Mac, Safari for iOS
Firefox does not support HLS in either desktop or mobile version. It requires Flash as a last-ditch fallback on any platform that doesn't support HLS, afaik.
The Phoenix tests had a ton of errors and there was no preview run so whoever submitted them wasn't able to fix them. This has happened with a bunch of different languages/frameworks in the past and until the errors in the implementation are sorted out the benchmarks are basically meaningless.
There were problems with the benchmarks and nobody had time to fix them. This is usually the case when the benchmarks have high error rates and this has also happened in the past with Haskell, C# and F# libraries.
> .NET development no longer tied to Windows, dev with a Mac or Linux using .NET core
.NET core hasn't seen an official release and there's still quite a bit of work to be done. Even with that, the overwhelming majority of .NET libraries don't work on OS X or Linux and it's going to take a significant amount of time to port just a small fraction of them.
.NET core might turn out to be a great cross platform solution but it's nowhere near that right now.
For building a traditional monolithic website with server side rendering Rails and Django are far faster to develop in than anything in Go, Java or Node and the overwhelming majority of websites will never run into any performance problems with either.
> By way of contrast several years ago I benchmarked a real application hitting 1000 requests/s on a $20 per month Linode box
I have Rails applications that hit the database on every request doing 1000 rps on $10 a month Digital Ocean boxes. 1000 rps is not that much and all of these performance metrics are meaningless without extensive knowledge of how the application works and exactly what it is doing.