> 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.
The difference between Elixir/Erlang and a statically typed functional language is that it's built for distribution.
In a distributed system where machines register on a cluster and messages are passed constantly across isolated heaps, processes and entire machines transparently all of the assumed protections of a static type system break down. You can't enforce static types across a cluster anymore than you can across a JSON requests to somebody else's API without a lot of extra overhead.
Static types are essentially contracts and in order to enforce a contract like that on a cluster of different machines that would mean you'd have to exchange contracts everytime a new machine joined the cluster...for all modules and functions...with every machine on the cluster. And then you have to determine how to handle contract violations.
Clustered message passing operates more like request routing in that regard. Send to this machine, to this module, to a function named this, with this arity, that matches this pattern.
The Elixir gradual typing approach balances this reality extremely well in my opinion. You get type checking if you want it and can specify it in more detail...but it won't promise something that it can't guarantee across the cluster, across deploys and across changes.
I beg to differ. FP with Clojure is pure joy. Spec, which is due out soon with 1.9, is also the next best thing to static typing. Some would even say it's better.
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 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.
> 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
You're just wrong there. There are plenty of languages that do something better than Java, but none of them do everything better than Java.
> 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
Now we are traversing into "my opinion is fact here".
> Python is a very slow dynamically typed language with a horrible deployment and concurrency story.
Who the hell uses Python for concurrency? It has a global interpreter lock... if your use case obligates concurrency and you pick Python you just don't understand what you are doing.
> C# is a real competitor but for the most part it's still tied to Windows.
Yes, let's dismiss every other language because Python is bad at concurrency and you don't like Go's package manager... Give me a break.
> I agree and I never said otherwise. I specifically addressed three of the languages you named (Python, Go and C#).
By pointing out things that they do decidedly worse than Java, which was exactly the opposite of my point.
> I'd love to see someone argue that Go or Python have superior tooling to Java and the JVM.
I never said they did, because they don't, in general. But Python is absolutely superior in some areas (statistical modeling, machine learning) because the tools it uses are, objectively, better.
> I'm not dismissing every other language, I don't even use Java regularly, I'm dismissing two of the "modern" languages you named.
Right, you're dismissing them for decidedly stupid reasons. Literally no one on the planet is going to think Python is a good option for concurrency. And you're opinion on Go is literally just an opinion, that many (myself included) would absolutely disagree with.
> 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."
> 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.
LOL. What? Did you poll every company doing ML work to arrive at that conclusion? C++, sure. Java and Scala? I've literally NEVER seen actual ML work done in either language at either of the 2 companies (both big 4) I've worked at.
> So having relatively poor tooling,
No. Is Java's tooling generally better? Probably. Does that make all other tooling poor? No.
> poor package management
Stop treating your preference as if it's fact.
> poor performance
Which matters sometimes, but not always. If performance were a metric that made a language live or die, nobody would use anything but C/C++.
> bad concurrency support
Only in Python. But that's moot, you don't need concurrency in every application. Do you realize there are ENORMOUS applications, in-use today, that scales dramatically and they are written in a variety of languages, including Python?
> Go and Python aren't even particularly well designed languages.
Your arguments here indicate you have very little understanding of basic language use-cases, so pardon me if I don't hold your opinion on language design to a very high standard.
> aren't good reasons for dismissing a language
They aren't reasons. They are your opinions and a fundamental misunderstanding of basic use-cases. Frankly, based on what you've said so far, your judgement about languages in general is on-par with what I'd expect for a new grad CS major that only used C++ or Java while in college.
> That's far more than you've given for dismissing Java and claiming that alternatives are "vastly better for a typical startup."
And yet I clearly explained why Java is generally not a good choice for a startup. And it seems, most startups agree since the majority don't use Java.
> 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.
> Most of the other things I said aren't even controversial
Most of the things you said were a straw man and nothing more. Go and Python are good at what they do. I see them as tools in a vast tool box. You think everything is a nail. Enjoy thinking that's a valid viewpoint.
> 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.
Yep and this is the problem. Initial library support isn't close to enough.
It needs to be extracted from a real project and then carefully groomed and enhanced based on real problems.
Otherwise you're just sitting there trying to invent something with no use case. You can't invent a beautiful API or account for edge cases that you don't even know exist.
This is why Rails will be around and thriving for another 10 years. Until something so drastic comes along that it fully disrupts everything we know about web development, I will still reach for Rails.
Right now all of these alternative solutions in other languages aren't offering enough benefits to even think about switching.
P.S., I'm not even a Rails fanboy. I use other techs too and tried to get on the bandwagon with Node back in the early days and did the same thing with Go. It took a long time to realize how much of an utter waste of time it is to chase the new shiny thing.
