> It mostly all seem to be an attempt to blame Russia for internal problems.
Agreed. The vast majority of the time I see Russia brought up it's being used by mainstream Democrats to dismiss criticism from both the right and the left. Basically anyone that's not a staunch neoliberal gets accused of being a Russian or a Russian puppet.
They're using it as a scapegoat and it seems to be working.
Phoenix is much more straightforward and explicit but macros are used a lot in both Phoenix and the Elixir standard library. I think most of the macros are fine but opinions vary widely on that.
I've used both and honestly it probably wouldn't change much. Unless you're building an application that deals with tons of persistent connections and websockets there aren't really that many advantages. The Python ecosystem is also much, much bigger than the Erlang and Elixir ecosystem and it has far more mature libraries.
If you really want to learn a functional programming language I'd strongly suggest looking at Haskell, Ocaml or F#. Functional programming only really starts to shine with a good static type system and dialyzer simply doesn't cut it.
I'd normally also have to select packages for sending emails, running background jobs, internationalization, templates, validation, file uploads and caching at a bare minimum. Then I'd have to make sure they all work well together, setup testing and probably have to write additional functionality that Rails or Django already covers.
Frameworks like Rails and Django cover a ton of functionality and gluing together and maintaining a set of packages to cover even a fraction of that functionality is a ton of work that's often for very little gain.
> I've literally NEVER seen actual ML work done in either language at either of the 2 companies (both big 4)
I work at one of the big 4 right now and almost all the serious ML is done in C++ and Java. Python is purely used during exploratory phases and even that is being phased out. Most of the other things I said aren't even controversial so I'm just going to ignore you from now on. Enjoy thinking Python and Go are well designed languages.
> because the tools it uses are, objectively, better.
Bullshit. Python is often used for early exploration but the people doing serious work in ML almost always end up using C++, Java or Scala.
> you're dismissing them for decidedly stupid reasons
So having relatively poor tooling, poor package management, poor performance and bad concurrency support aren't good reasons for dismissing a language? Go and Python aren't even particularly well designed languages. That's far more than you've given for dismissing Java and claiming that alternatives are "vastly better for a typical startup."
I don't use Java much but out of the languages you named none of them are better at much and with the exception of C# all of them have far, far worse tooling.
Go is hardly a "modern language" from a language design perspective so you're not gaining much over Java here. It has horrendous package management and the IDEs, debuggers, profilers and live monitoring tools are probably a decade or more behind the tools available for Java and the JVM. It's also much harder to find Go programmers than it is Java programmers.
Python is a very slow dynamically typed language with a horrible deployment and concurrency story. A lot of big companies justifiably won't even consider a dynamically typed language. Again all the tooling from package management to profilers to debuggers is way behind what's available for Java and the JVM.
C# is a real competitor but for the most part it's still tied to Windows. This is slowly changing but the vast majority of C# libraries still require the full .NET runtime on Windows and the open source community around C# is a small fraction of the size of the community around JVM languages.
> The set of 10 to 15 requirements every project has is basically there.
Even a lot of the really basic stuff like file uploading and image handling libraries aren't in a good state yet. For example, there's nothing that comes close to Carrierwave, Paperclip or Shrine and the Image Magick libraries are nowhere close to their equivalents in Ruby or Python.
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.
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 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.
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.
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.