51–60 of 663 posts
[flagged]
Eh, Rust is kind of "immutable by default" but not really enforcing that + "constants" in the way I think Carmack advocates for. Other languages does better in that regard. Examples: https://play.rust-lang.org/?version=stable&mode=debug&editio...
[flagged]
> I wish it was the default, and mutable was a keyword. I wish the IDE would simply provide a small clue, visible but graphically unobtrusive, that it was mutated . In fact, I end up wishing this about almost every language feature that passes my mind. For example, I don't need to choose whether I can or can't append to a list; just make it unappendable if you can prove I don't append. I don't care if it's a map, lis…
I don't think this is the best option, there could be very hard bugs or performance cliffs. I think I'd rather have an explicit opt-in, rather than the abstraction changing underneath me. Have my IDE scream at me and make me consider if I really need the opt-in, or if I should restructure. Although I do agree with the sentiment of choosing a construct and having it optimize if it can. Reminds me of a Rich Hickey talk…
Why loops specifically? Why not conditionals? A lot of code needs to assemble a result set based on if/then or switch statements. Maybe you could add those in each step of a chain of inline functions, but what if you need to skip some of that logic in certain cases? It's often much more readable to start off with a null result and put your (relatively functional) code inside if/then blocks to clearly show different l…
There’s no mutating happening here, for example: if cond: X = “yes” else: X = “no” X is only ever assigned once, it’s actually still purely functional. And in Rust or Lisp or other expression languages, you can do stuff like this: let X = if cond { “yes” } else { “no” }; That’s a lot nicer than a trinary operator!
let x: Int
if cond {
x = 1
} else {
x = 2
}
// read x here[flagged]
No Twitter clone has supplanted the original. Bluesky is a joke. Federation doesn't work. Threads isn't close. Musk's ownership isn't such a negative that it outweighs everything else.
If it was just his ownership that would be one thing but his aggressive support for turning the site into /pol/ has ruined it.
Immutability was gaining huge traction with Java... then large parts of the industry switched to golang and we hardly make anything immutable.
In JavaScript, I really like const and have adopted this approach. There are some annoying situations where it doesn't work though, to do with scoping. Particularly: - if (x) { const y = true } else { const y = false } // y doesn't exist after the block - try { const x = foo } catch (e) { } // x doesn't exist after the try block
const y = (() => {
if (x) {
return true;
} else {
return false;
})();> I wish it was the default, and mutable was a keyword. I wish the IDE would simply provide a small clue, visible but graphically unobtrusive, that it was mutated . In fact, I end up wishing this about almost every language feature that passes my mind. For example, I don't need to choose whether I can or can't append to a list; just make it unappendable if you can prove I don't append. I don't care if it's a map, lis…
Proposing making immutable by default in C or C++ doesn't make sense due to backwards compatibility reasons. New languages like Rust have easier time making better choices with immutable by default.
Earlier quoted context omitted.
Functional programming languages (almost always?) come with the baggage of foreign looking syntax. Additionally, imperative is easier in some situations, so having that escape hatch is great. I think that's why we're seeing a lot of what you're describing. E.g. with Rust you end up writing mostly functional code with a bit of imperative mixed in. Additional, most software is not pure (human input, disk, network, etc)…
Rust is not very suitable for functional programming because it is aggressively non-garbage-collected. Any time Rustaceans want to do the kind of immutable DAG thing that gives functional languages so much power, they seem to end up either taking the huge performance and concurrency hit of fine-grained reference counting, or they just stick all their nodes in a big array.