Assume mainstream adoption as used by around 7% of all github projects
Personally, I’d like to see Nim get that growth.
Esperanto.
Haskell. I think that more people being familliar with Haskell concepts would be good for programing culture and it would increase the odds of me being able to write Haskell professionally, which is something I enjoy a lot when writing hobby code at least. Having more access to tooling and a bigger eco system would be nice as well.
I’m not a 100% sure about my answer though. For one, I might grow to resent Haskell if I had to use it at work, and there’s also a risk that it would be harder to do cool innovative stuff with the language when more big companies depend on it.
Crystal. The language is killer but there’s a real lack of libraries for it.
Malbolge
R
I know is not considered a “proper” programming language by some, but I’ve been working with it for years for scientific data analysis and I love it
{-# LANGUAGE OverloadedStrings #-} import qualified Data.Text as T (Text) correctAnswer :: T.Text correctAnswer = "Haskell"Zig hasn’t been mentioned yet, so I’m just going to drop that here.
I personally have enjoyed the meta-programming, the ease of integrating with C libraries, and like that it’s pretty straight-forward to compile.
If we’re saying 7% is the bar for mainstream, then Rust is my vote.
C# is not even mainstream by that standard.
I’d also like to see Julia used more.
Many here will hate this, but I am looking forward to just using English language to program and let AI handle all the minutia.
I don’t know why you’re being downvoted, but this could truly be the future of programming languages. We don’t have to manually compile everything to assembly today, do we? Imagine simply using English for pseudocode, with an AI compiler that writes the most performant code… How much would that speed up development time? Noone would need to know different languages… The learning curve for programming relatively basic shit would be low.
I dunno, but I’ve seen a lot of unecessary hate for AI in the left leaning communities…
Syntax has never really be an issue. The closest thing to plain english programming are legal documents and contracts. As you can see they are horrible to understand but that the only way to correctly specify exactly what you want. And code is much better at it. Another datapoint are visual languages like lego mindstorm or LabView. It’s quite easy to do basic things, but it doesn’t scale at all.
Syntax has never really be an issue.
But it has tho… For example, I do not know rust. I want to add the notifications functionality to Lemmy. Lemmy is in rust. To implement this relatively simply api, I need to learn rust to a degree. Then, I need to look at Lemmy’s file structure to understand the project further to actually do what I want to do. What if this all could be abstracted by me simply saying “post xyz to the expo-notifications server whenever someone messages someone.” An AI English-to-rust interpreter could easily do this.
The closest thing to plain english programming are legal documents and contracts. As you can see they are horrible to understand but that the only way to correctly specify exactly what you want.
This is what would define the smartness of the AI, wouldn’t it? Your project manager doesn’t tell you exactly what they want. You have the brains to interpret what they mean and do stuff accordingly, correct?
This requires many assumptions that you or any computational system have no formal reason to make. Having an interpreter that just guesstimates exactly how you want the program structured, is going to run into problems when you, say want to extend the program.
codsu
hi
Rust! Memory leak free code would make our world a better place!
Rust doesn’t guarantee the lack of memory leaks anymore then java/C++ does, so sadly not sure if it would help here. :)
Help me understand your point of view. How does Rust not prevent memory leaks?
There’s built in functions to leak memory that are perfectly safe. You can also do one really trivially by making a reference count cycle. https://doc.rust-lang.org/book/ch15-06-reference-cycles.html
Rust only prevents memory unsafety - and memory leaks are perfectly safe. It’s use after frees, double frees, etc. It prevents.
You are absolutely correct that rusts safety features don’t extend to memory leaks, but it’s still better than most garbage collected languages unless you abuse Rc or something, and it does give you quite fine-grained controll over lifetimes, copying and allocations on the heap which in practice means that rust is fairly good about memory leakages compared to most languages.
Reference counting is a GC though ?
It’s a bad one sure and will leak memory in cases of a cycle which most tracing GC are able to do.
It’s main advantage is that there are no GC pauses.
I think you know what I mean when I contrast Rust with GC’d languages, we can call it opt-in garbage collection if we’re being pedantic.
How would rust fare any better then a tracing GC? Realistically I’d expect them to use more memory, and also have worse determinism in memory management - but I fail to really see a case where rust would prevent memory leaks and GC languages wouldn’t.
If you just Rc everything (which I’d count as “abusing Rc”) Rust is significantly worse than a language with a good GC. The good thing about Rust is that it forces you to aknowledge and consider the lifetimes of objects. By default things are allocated on the stack, but if you make something global or dynamically handled (e.g. through Rc) you have to do so explicitly. In Rust the compiler has greater compile time information about when things can be freed which means that you need less runtime overhead to check things and if you want to minimize the amount of potentially long-lived objects you can more easily see how long objects might live by reading the code as well as get help by the compiler to determine if a lifetime-based refactoring is sound or not.
