Thanks for the link.
It would be interesting, whether this handles macro-expansion as well (I doubt that, haven't looked into detail yet though).
Actually it's been so stable for me for at least a year (not sure when I switched exactly), that this post kind of surprised me, I thought it was > 1.0 already
True, Python has a very big userbase and a lot of cool libraries and is nice to quickly hack something together.
Though the title of the post is
If you had to choose one programming language that you had to use for the rest of your life, what would it be?
So TMU I want to predict the future in a way that it positively affects me, and find a language that fulfills this role best (throughout the stack, so that I'm not limited). And honestly I wouldn't want to touch Python with a long stick, if the project is moderately complex (and isn't easily off-loadable to native libraries that Python builds upon) and say > 5000 LOC, the super dynamic nature of python is a curse in this regard.
Behold, Rust is blazingly fast in approaching the most popular language :)
Also, in comparison to Python you can do pretty much everything throughout the stack, which would be the reason I would go for Rust (not mentioning all the other niceties it has to offer).
Also learning Rust nowadays is much more approachable compared to say 7+ years back (ecosystem got way better)
Drew Devault’s Hare language
Ok, they say "use your distros package-manager", that's basically asking for the same disaster as C or C++. I think cargo is one of the selling points of Rust.
At least say something like we use "Nix" for default package-management (which does a lot of things right)...
I think it's not that bad yet, when comparing with npm. Usually the dependencies I use are of very high quality. But I'm also very selective with dependencies. I'm rather writing a simple part myself, than using a not-really maintained low-quality dependency...
Btw. I have not looked into the Hare language yet (will do that now), but if it's similar as deno, I won't like it. You want to have some kind of package management IME...
Not him, but I much more like the type-system of rust (e.g. enums).
Yes, and Rust with incremental compilation is pretty fast to iterate as well, as long as you don't use massive libraries/build-scripts etc.
Yeah the way you need to maintain two codebases: one for types and one for actual logic is annoying.
Also nix is purely functional (which is necessary, for more information read the Nix Pills), Typescript is not, so unless it's only a purely functional subset or severely limits Nix (in the form of abstractions, after skimming over it, I think this is the case), it will run into issues...
The curse of OOP (java style...).
I mean why do you need to write getter and setter methods. I have wondered at the beginning of university 10 years ago, and am still wondering why you would need something like that...
Really? Is it necessary to ban people about making a valid argument. I know and also don't like people asking a low effort "What's the status of this" (and would totally get why such a thing would be marked off-topic, but a ban over something like this is still to harsh IMHO, they will learn, that such questions are not well-received over just the marking it as off-topic).
But the comment discussed here has a valid concern (quickly closing issues that don't have satisfactory solution yet, without getting feedback).
A better reaction would be to just ask, whether the issue at hand is still relevant, having [these] alternatives at hand etc.
$0.7k annually? Is it anyhow possible to live with that low salary in India? I can't even live a month with that here, even if I don't buy anything but the cheapest food and live in the smallest apartments here...
Yeah my thinking as well.
Addtionally, why I think other system language competitors like Zig or Nim aren't succeeding long-term, is because of fast growth and already big ecosystem of Rust. Zig may be better though for some use-cases (when you want to avoid all the mental overhead, and the application stays simple).
On another look, though, we have to keep in mind, though that this is code-golf, so in no way representative for actual code-bases.
Hmm interesting, I would've thought that Haskell would rank much higher
All good, well maybe not exactly the issue: https://github.com/LemmyNet/lemmy/issues/3580 (maybe you find something else there, otherwise, just open an issue there)
Also just discovered via this, that there's already a "Show Read Posts" setting in the settings
Pretty sure, that there's already a github issue on lemmy itself (too lazy currently to search it though)
I don't think this will be a very big issue for the majority of the cases though. As long as it's configurable and not a (very) controversial change. Especially, since I don't think that feature requests on a programming focused community will be that much controversial...
What I have observed so far: I think the maintainers are relatively open to changes (compared to a few other open source repos).
Depends on what you mean exactly with "file format".
If declarative functional programming falls under that, I think something like Nickel, the already mentioned Dhall or Nix. Though Nix more so for packaging and some kind of system management (NixOS?), it's not easily embeddable into a runtime (your app?). Nickel or Dhall is better for that, as they are built from ground up with that in mind, Nickel is maybe the successor of Nix as it is inspired by Dhall and Nix (one goal is to use Nickel as frontend).
The reason why I recommend a simple declarative language, is that they are IMHO much better composable as it lets the user hide boilerplate via functions. I almost always feel limited by static configuration formats like yaml, json etc..
Although I'm fully in camp functional, I doubt that. There are problems that are inherently stateful and rely on mutability. Modelling that in Haskell often results in unnecessary abstractions. I think Rust hits a sweet spot here (when you're that experienced to write idiomatic Rust, whatever that exactly is). Also being lazy by default has its own (performance) implications, strict + lazy iterators (like Rust) is a good default IMO.