At least Python as DSL for GPU JIT compilers is a thing now.
Yes, I know about PyPy in the corner looking for attention.
What are some of these better languages that you're referring to? (The usual dynamic language JITs I hear people praise are LuaJIT and Chez. And V8. And the JVM?)
And the usual, in Python everything is dynamic, well it is even more so in an image based live coding environment, where any break into the debugger, with code changes and resume execution can come back to a complete different world.
Additionally there are features like Smalltalk become: message, where two objects can change places everywhere they are used in the image, and current execution.
That trace back to Apple's efforts with MacRuby, or Sun's (for a while Netbeans even had Ruby support).
The Ruby JITs I mentioned are used in production.
While other dynamic language comunities embrace their JITs, in Python world, outside using it as a DSL for GPGPU JITs, it is pretty much let's just keep using CPythion with C and C++ extensions. Adding a JIT to CPython only became a thing after Facebook and Microsoft decided to push for its development.
I actually liked D very much, and WB had been a personal hero of mine when I was in college. But I am not betting my career on an ecosystem built around by a single brilliant guy. For high-stakes projects, a wise decision is building on a platform with several deep-pocketed backers.
And for toy/personal projects... do you even need a language anymore? Just ask your favorite LLM to generate you an executable which does what you want (partially joking here).
It's not perfect, as some people cannot resist using the C preprocessor for some bizarre constructions.
I used to write those bizarre things myself in C, and was proud of my work. But one day I decided to remove them all, and the code was better.
For C# Microsoft eventually embraced NuGet their package manager, and used it to put core packages that don't need to be fully available OOTB but can then benefit from frequent updates on a per project basis as opposed to updating the entire language runtime.
For Go it was the out of the box packages, like if I want to make a website, I can pull in net/http and their templating packages that come out of the box with Go, maybe a reasonably simple core maintainer package or packages that go into Dub would be a strong selling point. Right now Vibe.d is the only option for web dev, but there's no reason a much simpler web server couldn't exist.
For Rust, I just really love Cargo, I think its one of the nicest package managers I've ever used.
The other thing that would really help D is if something significant is built around D, whether it be a framework (like what Rails did for Ruby) or some major application that needs D to function at its core and is used by many, this could be a groundbreaking modern IDE, or anything really, a database that uses the best bits and pieces of D to scale, or even a really rich cross-platform GUI stack (my kingdom for std.gui to be a thing in D, and reasonably exhaustive).
I wish I had unlimited time and money, I would invest it in D. Alas, I'm not a language maintainer, just a guy who loves really good tools.
To the parent's point of startups, betting the farm on something like a particular language out of some sense of superiority might mean you are not focusing on the right problems. But if the founders happen to know a less widely used tool it doesn't seem inappropriate either. The type of employee that can drive a startup or a big tech project forward is not going to be thwarted by a language, and they might find something new to learn fun.
Maybe it exists and I am just ignorant but it doesn't seem to be in the list of supported languages.
Yes it isn't here today, just like it took several decades for optimizing compiler backends to do a very good job.
In fact one of the reasons why Matt Goldbolt created Compiler Explorer was to have a way to settle arguments he was having in the games industry.
... and the job of a programmer will be to explain, in as precise terms as possible, what they need the executable to do. (Reminds me of the idea of programming based on a natural language.)
Python's syntax is closer to written human language, and it uses more obvious words.
> TypeScript preferred over Dart or even JavaScript
Typescript is a strict superset of JavaScript.
> Go is preferred over Crystal and D
Go is backed by a big Corp
Python won over Ruby because of performance. Ruby is easily the slowest of all mainstream languages.
Also all languages you mentioned support complex code and OOP.
The same argument applies to C++. No one is forcing you to create complex nested templates or other difficult features.
Yet many criticisms to the language are in the form: "But it is possible to write very complex code that no one understands!"
It is absurd.
The devs are working on 5.0 as we speak!
Its really calming that Haxe is not moving as fast as the JS/TS ecosystem. You upgrade once every 3-4 years. Everything just usually "works"
We use Haxe for PHP and its really a secret hidden superpower, im amazed people dont know about / use.
Its mostly marketing, i guess. But i wish more devs tried it as an alternative to PHP or TypeScript, as the language is WAY better in almost every way.
... Perhaps what you're describing is having a niche opinion. If you had some opinions, like a preference for "Everything must be done in as many ways as possible with funky characters" or "I hate indentation", it would certainly seem that the world is against you. But, perhaps, you just really smart and can remember the intention of all the complicated code you wrote a year ago, so you don't even need to write comments, and thats great. However, being special does not mean that some technolgoy is objectively inferior, unless you can actually come up with a provably objective metric.
Overall, the technology that is there, solving most of the problems for most of the cases is the technology that is superior, by the law of the universe, not the other way around.
I don't agree with any of your examples, but I have my own, like Pascal is a better language than C, by many metrics. I can also accept that C, is what people who invented unix, also invented. And that makes Pascal inferior to C, now, as choice for any project that requires that you hire embedded software developers. That's what the universe decided.
Are you sure you're not talking about Perl here? Because there are very few "funky characters" in Ruby and code written in it tends to be very readable, more so than Python in many cases.
I agree with OP. While Python is not a bad language, Ruby is a better language in general, and I'm reminded of it every time I have to work in Python (which is pretty often nowadays, due to Python's dominance in ML ).
I can give many examples as to why, but here's a quick toy example to show off the difference in philosophy between Ruby and Python. You have a list of numbers, you want to keep only odd numbers, sort them, and convert them to a string where each number is separated by comma. Here's the Ruby code:
xs = [12, 3, 5, 8, 7, 10, 1, 4]
ys = xs.filter { |x| x.odd? }.sort.join(", ")
xs = [12, 3, 5, 8, 7, 10, 1, 4]
ys = [x for x in xs if x % 2 != 0]
ys.sort()
ys = ", ".join(str(y) for y in ys)
xs = [12, 3, 5, 8, 7, 10, 1, 4]
ys = ", ".join(str(y) for y in sorted(x for x in xs if x % 2 != 0))
This all makes sense to a person who knows the language a lot, but wrinkles the brain of a newcomer. Too many concepts to juggle in order to understand. On the other hand, the Python one reads quite easily, even if you may have to go right to left.
xs.filter(x => x & 1).sort().join(", ") // JavaScript
xs & filter odd & sort & map show & intercalate ", " -- Haskell
For Python, you don't really have to use list comprehensions in the place of multiple for loops, you can sacrifice the brevity afforded to write the same thing in a more easily understandable fashion.
I get that this is just a rhetorical question to make a point about newcomers, and I do agree it's not immediately obvious, but for the record: you can imagine any "if"s and "for"s in a list comprehension are nested statements in the same order. So, for example, this:
l = [
y.foo()
for x in my_list
if x.blah() > 7
for y in x.ys()
]
l = []
for x in my_list:
if x.blah() > 7:
for y in x.ys():
l.append(y.foo())
The order is mentioned right in the docs, for Python 3:
https://docs.python.org/3/tutorial/datastructures.html#list-...
>Note how the order of the for and if statements is the same in both these snippets.
And it is mentioned even more clearly in corresponding section in the Python 2 docs - last I checked, years ago,
Update: IOW, the nested list comprehension syntax is confusing only to newcomers or even experienced devs who are lazy or stupid enough to not read the docs for the language feature they want to use, before using it, IOW, "winging it", whether to try to seem cool or due to peer pressure or other reasons, all of which are stupid ones, even in the short term, because the cost is higher than the benefit in most cases.
The hostility in your response to "lazy or stupid" devs is really funny given what a bad response it is.
Questions such as
> why does it not have parentheses around it but the `", "` passed to `join` does?
would be exactly the same for JavaScript, Go or D. Ruby has the best syntax with regards to blocks/lambdas/closures.
A bit of Smalltalk shining through Ruby.
I don't understand this argument. You are a beginner only for a tiny fraction of your time using a given programming language. Why are we optimizing a programming language for people who don't know it, instead of optimizing it for people who actually program in it?
Everyone who actually programs in a language was once a person who didn't know it. Languages which optimize for succinct terseness might be powerful once you master them, but they will never enter mainstream use, which I guess is not necessarily the aim.
ys = sorted(x for x in xs if x % 2)
# vs
ys = sorted(filter(lambda x: x % 2, xs))
ys = ", ".join(str(y) for y in ys)
And then the d2 fiasco sort of blew it all up. Doesn't help that the language always felt very heavy to me. Likewise Rust feels heavy and cumbersome itself.
So it ends up that I'm another one of those who feels the itch getting scratched by zig.
Only a small amount of D uses the garbage collector. It's quite easy to write D code that doesn't use it.
> in my opinion the boost shared pointers (later adopted into the standard) solved and shut the door on memory leaks as a serious issue.
Reference counting is slow and memory intensive.