131–140 of 265 posts
A quick search has it listed it as a synonym, but I can't find any usage outside tech and it sure seems like a tech-industry/coding erroneous neologism trying to balance the seemingly logical "post" -vs- "pre".
Am I way off the mark here?
Earlier quoted context omitted.
> Rust is, indeed, just syntactically insane to a new learner (honestly, worse than perl ever was). Can you elaborate?
I'll bite. For context, I'm very much a rust beginner with probably a couple dozen hours at most. I find that anything having to do with lifetime parameters is hard. I think this is even worse than C++ templating in some sense since it behaves differently than type templating. Otherwise, I think the syntax is fairly reasonable.
This is way way off-topic but: I have never seen the word "postfix" used in this way. "Suffix" is the normal/common English word for this as far as I've always been aware. A quick search has it listed it as a synonym, but I can't find any usage outside tech and it sure seems like a tech-industry/coding erroneous neologism trying to balance the seemingly logical "post" -vs- "pre". Am I way off the mark here?
Earlier quoted context omitted.
> Rust is already a weird language to come to from the likes of python, Java, or Javascript Every time I see a statement like this, I remember a (paraphrased) statement from Rich Hickey: "[musical] instruments are made for people who can play them!". I think unless you are specifically designing a beginner language (like Scratch), you should not take into consideration "ease of use" or "familiarity" arguments.
I wouldn't use a programming language whose designer had this attitude.
It's not a binary choice for the most part.
- Ease of use will not be promoted over long term growth or power (I.e., the instrument should be designed such that it can ideally facilitate indefinite growth of skill. It shouldn't be a toy that only works up to a certain point.)
- Very often, ease of use can be optimised in such a way that it does not conflict with the first point, rendering the entire discussion moot.
- Familiarity is a non-goal unless the familiar design has the same properties as the optimal design, with regards to the first point.
This is not to say that easier, beginner friendly designs that _does_ sacrifice the long term power or growth aren't valuable. It's a different design goal, though.
Reading this feels like a person with no good choices trying to convince themselves there's no other way than their best bad one. "This is the best proposal, except the syntax doesn't make sense, we don't know if we can implement it, and conversation has broken down to the point where we are running in circles and we don't expect to have any more ideas." I am curious what the current way to do non-blocking code in Ru…
It raises my esteem of the Rust lang leadership that they eventually realized what they had to do and picked something.
"It has also devolved into a situation in which many commenters propose to reverse previous decisions about the design of async/await on which we have already established firm consensus, or otherwise introduced possibilities we have considered and ruled out of scope for now. This has been a major learning experience for us: one of the major goals of the “meta” working group will be to improve the way groups working o…
It's just means there is lack of trust to core designers. They haven't proven themselves to users, that they are capable of addressing their problems and align with their interests. Obviously core devs of Google backed language cannot do better. They can only gain that trust from users within Google, not outside of Google. Not sure about Rust though.
I don't think that can explain the observations I've made. Either that or the sort of trust you describe is simply impossible, because I've never seen it in any language community I've been in.
I'd lean more towards a lack of clear description to the community for what they're looking for, and the community buying in enough that when communicating amoungst themselves they also do some lightweight enforcement of the expectations.
Earlier quoted context omitted.
"And no one argues about syntax." No one argues about the syntax, because everybody "wins" and gets their own syntax as a result, which is often held up as a key part of the explanation for why the Lisp family languages are wonderful and fun and mind-expanding and just awesome in every way... yet rarely escape from "niche" status and are yet to even threaten to break into the really top-tier languages. Because langua…
Fragmentation cannot really be an issue for adoption, as it happens after adoption.
Earlier quoted context omitted.
So the Linux desktop will only become fragmented after the mythical "year of Linux on the desktop"?
I'd say fragmentation hurts retention, which only has secondary effect on adoption.
I have no idea how you come to that conclusion. Any conceivable model for adoption I can imagine is a differential equation which contains "current adoption" as a term going into the first derivative. If people are leaving a language faster than people are coming in (and I speak in general, not claiming this about any particular language), retention is going to have major effects on adoption and the lack thereof.
Earlier quoted context omitted.
Not even if you paid me to have that fight, no. Edit: OK, one tiny crumb: https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html -- Read through that thinking about how other languages express the same fundamentally simple concepts, and consider how Rust invents new syntax for basically everything, and then sticks it all together by re-using syntax from other areas. Why does a parametrized enumerant look like a…
> Why does a parametrized enumerant look like a function call and not a struct? Because tuples are considered good things to have in a modern language. Structs and enum variants are just named versions of tuples (denoted with parentheses) or records (denoted with braces—unnamed records don't exist in Rust). To follow languages like Python, they're written "(1, 2, 3)". (It would be weird if tuples were written "{1, 2,…
That is the case in Crystal. Doesn't feel weird - if anything it is consistent in that ()s always denote something to do with execution. Both ()s and {}s have multiple different other syntactic usages though, so it is not as if either is optimal.
Earlier quoted context omitted.
> Rust is, indeed, just syntactically insane to a new learner (honestly, worse than perl ever was). Can you elaborate?
Not even if you paid me to have that fight, no. Edit: OK, one tiny crumb: https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html -- Read through that thinking about how other languages express the same fundamentally simple concepts, and consider how Rust invents new syntax for basically everything, and then sticks it all together by re-using syntax from other areas. Why does a parametrized enumerant look like a…
If anything, Rust's managed to be a whole lot simpler than other languages. Python, JavaScript and C++ have some of the worst string encoding stories I've ever seen. And most popular languages don't even have sum types, so it's like they have an "and" and no "or".