My view is that languages don't matter only libraries and engines. If you want to make an iOS app then Swift is for you. If you want to make an Unreal Engine game then C++. If you want to make a website then JavaScript. If you want to play with Bevy or Servo libraries then Rust. If you want to play with Blender or do anything with AI then Python.
I think that argument is on increasingly shaky ground these days as the barriers are starting to come down in a lot of ways.
First in the sense of hand crafted interop solutions that modern languages provide.
Take Dart for example as something that has a (by comparison) very small package ecosystem.
However it has support for interop across: JavaScript, Java, Objective C, C, C++, Rust, Swift, Kotlin and Go I believe off the top of my head.
Then you also have efforts like WebAssembly and specifically the in-development component model which seeks to totally break down that language specific package ecosystem and make importing and working with another language as easy as it is when importing a package from your own language ecosystem.
So with those things in mind, however true that might be today, I don’t think it’s a strong argument moving forward.
I am not sure but your comment seems to make the point of the person you're answering to.
Dart is used probably and exclusively in one context (= library): Flutter. Nobody would dream of writing anything else with it and put it in production.
Why? Because despite the interop, all the libs are still in the original language and they shine in the language they were written with. And Dart has no ecosystem comparable to the top 5-10 most used languages.
Try to build bindings for QT in Dart. That alone would require a company just to make that happen. You'd have to pay developers just to make that interop work - that's what Riverbank did with pyqt. No other companies did that, as far as I know (until Nokia developed pySide). And what for?
So I somehow agree with the previous comment, unless someone writes really good bindings. That's rare, though, and from my experience it's mostly to put something in legacy mode.
There's at least 2 bindings for QT in Dart (in general, darts a pretty big pond, there's been a strong steady uptake of Flutter that's not delineable enough in a way to concisely update impressions it's small)
Yeah, and I agree with you, I would think its nuts too. A couple years ago I didn't have any experience to tell me otherwise and would never have done that -- I'm only up for it now because I've had a great and literally painless time wrapping ONNX, llama.cpp, and a couple other C++ libraries using generated bindings.
I agree strongly on that it is good to make software architectural decisions, involving business, based on if you have a bunch of other people with the same problem shape as you.
And on specifically the idea that Darts not exactly hosting multiple UI frameworks, even though it theoretically could. (I don't know enough about Qt to know who uses it and why, my understanding vaguely is Linux UI. Canonical is all-in on Flutter, for whatever reason, so I discount the probability that Dart would naturally gain Qt bindings, if it was non-small)
There is a circular dependency — the language strongly influences what libraries/engines can and will be written.
Bevy and Servo wouldn't exist without Rust. Unreal probably wouldn't succeed without C++.
Languages may also matter for other reasons than just their feature set. Node.js got traction specifically because it was JavaScript.
Even though Fortran had state-of-the-art numeric libraries, Python enabled numpy to have the sweet spot of usability with good enough speed.
The killer libraries need years of effort to build them. That won't happen if users don't want to use the language, or the language isn't good enough for the task.
For Swift to have killer libraries, users must first choose Swift to build them. Catch22.
Spot on, for a long time, the project and platform dictactes the languages I use, not the other way around.
Being a YXZ Developer trying to fit YXZ into every domain, means that for many scenarios one ends up yak shaving until the foundations are in place for the actuall work one is supposed to do.
And even then, the tooling (IDE, debugging, build, libraries) will fail short from the platform native experience.
My motto is to always be curious and learn what is out there just in case, however in what concerns production work, only what is directly supported out of the box by the platform matters.
Typescript is maybe the exception, then again it is really a JavaScript linter in practice, the team has learned not to add additional language features.
