I think the thing missing here is that the killer domain isn't necessarily intrinsic to the language or its design. Some languages are designed for specific domains, but some find their domain based on large projects that happened after the language was out in the world. My understanding is rails came almost a decade after Ruby, numpy etc came well after python. This post says that you shouldn't try to use a language outside of its domain, but if everyone believed that, languages would never find a new domain.
I strongly think that R has outgrown just having statistics as its killer feature. The killer feature of R is data analysis
I have yet to see any software that rivals dplyr, data.table, and ggplot2 in the balance of power and ease of use. It also has all the auxiliary packages you need to fetch your data (DBI, httr, rvest), model it if necessary (parsnip, caret) and visualise it (ggplot2, plotly, shiny)
I know python is more popular here but I would choose R in a heartbeat 19 times out of 20
Possibly. I think R is actually easier to learn for people who have never studied or done programming before.
1. It's easier to get up and running as RStudio is much more 'batteries included' than other popular IDEs, it's harder to get into the case of multiple different python versions, and you install packages through the R interpreter rather than via pip at the command line
2. I would say R data analysis packages are easier to learn than the python equivalents. Because the dataframe is a native structure in R there has been a lot more packages that have tried alternative syntax approaches to try and find the 'optimal' one. Python has really only had pandas, polars, and pyspark (all of which have implemented their own data structures and therefore have focused more on performance than syntax)
3. This doesn't hold if you're studying a language to be a general purpose programmer. Then python is much better. Anything to avoid the hell of the R standard lib. But if you need to do a bit of coding to analyse data and you've never done any before, my vote would be for R.
However, these are thoughts from my own personal anecdotes rather than any pedagogical theory
I haven’t used matlab for 10+ years, but back then Matlab used to provide engineering packages for vibrations and non-linear models approximations, I’d imagine the effort of going Python/ open source code to just to redefine your model for both purposes and then validate and verify the results would be a 10-50 fold cost of paying for a license
C# is definitely popular for game development, but saying no other language comes close does not seem to be true. Looking at the most popular game engines and frameworks, it seems to be about as represented as anything else.
Game engines:
Unreal - C++, Unity - C#, Godot - GDScript (Python) + second-class C# support
We don't know for sure what AAA companies rolling their own engines use, but the industry standard would be written in C++, exposing C++ for programmers and Lua for non-programmers/modders.
To me, Python is a great language for anything that needs to be written quickly and executed a few times and/or on a small scale. I'm a C/low-level guy primarily but I write a lot of Python code (probably more than C these days) for various purposes, and none of it is related to statistics or machine learning.
Because you haven't extrapolated from Python's niche. Those domains are derived from Python's accessibility. Python might be the most accessible big boy language.
I'm currently learning Python for my ML/Tensorflow online coirses. I thought bc I know C++ it'd be super easy but theres a lot of differences between them. Turns out an "easier" big boy language still has a bit of a learning curve
I wonder what Common Lisp's 'killer domain' is in this framework... general purpose computations? Which was a bit much to handle for businesses and even a lot of programmers, hence its niche (yet actually very resilient) status?
Elixir/Phoenix → web, various parallel processing stuff?
Haskell → dunno, but it’s pretty cool
Erlang → dunno again, maybe some low-level stuff for Elixir?
F# → business apps for MS when you get sick from C#
Crystal → web, I guess?
Ruby is good for web, but it’s also useful when metaprogramming tricks work for you in your particular domain. Same with Python (it’s also insanely good for web!).
Elixir has a ton of really good libraries and a very active community. Erlang's is trying to catch up and they have my support as well but for the moment I find Elixir easier to deliver a full app to production.
You mostly can use Elixir libraries in Erlang but due to how Elixir macros are done and their pervasiveness, the usefulness of that feature is effectively limited. F.ex. Phoenix and Ecto, both extremely prominent and important libraries in the ecosystem, make heavy use of macros due to their nature and feature-set. And they are unusable in Erlang code.
Or at least that was the case some year ago. Haven't checked lately. I know there are ongoing efforts towards convergence.
Hmm, yeah, I think if you want to integrate Phoenix into an existing Erlang application, you’ll probably want to use Elixir as the “main” language and use existing Erlang code from the Elixir app. Or if you really need to run Phoenix inside Erlang, you could make a clean cut and write a portion of the app in Elixir, with an easy way to call it (e.g. start a server) from Erlang.
Neither option allows you to use Phoenix without writing Elixir code, though. But since you’re integrating an Elixir lib, writing at least some glue code doesn’t seem like a big deal?
(I’ve got to say that I’m not proficient at all neither in Erlang nor in Elixir – I’ve played around with both, but nothing serious.)
Surely there is somewhere a number, but my educated guess is that 90% of all new / greenfield deployments go into a Linux (or a Lambda/Docker variant).
Did C# really catch on on other platforms? C# was somewhat popular on Linux with Gnome for a while but my impression is that this has completely died down.
While it is technically possible to use C# on Linux and MacOS, it doesn't seem to have a significant mind share.
For the development of the platform, like desktop apps, no. But as web server, api or just whatever logic layer, definitely. Big times. On Linux in containers or lambdas.
> Only Ruby lists Ruby on Rails as its killer app, but that's basically it.
Concrete examples: Dart with Flutter, Elixir with Phoenix,
Arguable ones: JavaScript and browsers, Go and Kubernetes
I kind of disagree with the "killer app" concept because most languages can work in a lot of domains, but there are more examples if you're willing to think about it
Rust needs to focus in systems programming domain as top priority and get better at working with C++, or it risks staying a niche language. Without strong support for existing C++ code, it could eventually be passed up by other languages with better C++ integration — even if those end up being technically worse, like Carbon,Zig or something similar.
Rust isn't a niche language by a long shot anymore.
CXX[0] is fine. Personally, I just always use a C ABI to communicate between the two. I've had to do it for every other language anyway. Languages that have native C++ interop are significantly more rare than ones that don't. Most languages have some way of talking to C, though.
What this skips over is that some languages are better than all others in a domain, sometimes multiple domains. And also some languages are not best in class in any domain.
Would you pick Brainfuck over Java for anything (real)?
If alternative programming exercise counts as a domain, then yes ..
along with Turing Tape machine coding, corewars, that one from Knuth ..
outside of that domain of interest, not so much.
But that is one domain of interest.
It's also true that real world industrial scale dam control isn't a killer application domain for Brainf*ck .. but FGS, have you seen many SCADA implementations?
Scala was absolutely killing the "we need JVM because all our Hadoop era tech uses it but we're a new generation of JVM data tooling and so we need a language in which the functional programming based abstractions we're using for our data processing are first class language features" niche for a while in the late 2010s.
Was a really big part of Kafka and Spark ecosystems until they supported Python well enough that a lot of people just stuck with that instead of teaching their devs to write Scala.
Scala screwed up by having no filter. Implementing every idea someone with a PhD thought of from the entire history of programming seems like a good idea until you have to use the language. Everybody doing whatever they want because of the freedom and no guidelines didn't help. And build times killed it
Kotlin feels like it has a much better plan and it seems like so far it won't suffer the same death.
I agree about no filter*, I disagree with your reasoning. Scala (2) as a language is quite simple. The complexity came from the incredible power of its building blocks (e.g. implicits and path-dependent types). The lack of filter, as I felt, was moreso on how different two Scala codebases could be. That was part of the point though -- a scalable language, which means changing to the needs of each team.
Which also means less transferable knowledge. That killed it for me. If you muscle through it you'll get there, sure, but in the meantime I found languages that have smaller surface, are just as (or more) productive, and you can be onboarded in a project in half an afternoon.
A simple example is that people who start with Python think the list comprehension with all the colons and negative numbers is actually good instead of a hindrance. Python relies on pandas, Polars, and Pyfunctional to prop up a bad language design choice.
