I believe that if you start from an annotation-only stance, then you will look at the language, its defaults and possible extensions differently, because annotations are “visually” more expensive than slapping yet-another keyword on something.
I. e.:
“no visibility modifier” should probably mean “public”
defining the external API should move to the module-level altogether
we should probably use var instead of let mut
#[cfg(target_os = "windows")] is just bad design overall
instead put different targets into different folders: much easier, works better
async should not exist at all
(though not related to annotations vs. modifiers, but because the whole idea is a language design dead-end)
So the code from your example would literally be …
fun some_func: Unit = {var my_var = 3u2
// ...
… in my design.
Rust’s syntax with #[...] is not that great in this regard, as it triples the amount of symbol involved for simple annotations compared to something using @....
Jfc that’s a bit of a stretch. You basically just said “you are wrong to use those features, and if you don’t use those features then my solution is great”. Like yeah, no shit, if I wanted a toy language I’d go back to using Logo.
“no visibility modifier” should probably mean “public”
For-fucking-real?
instead put different targets into different folders: much easier, works better
Ahh, yes, file-based programming, the most usable and ergonomic pattern for cross-cutting concerns. /s
async should not exist at all
The most I’ll give you there is that it’s used more frequently than it should. But it is far and away the best abstraction for bare-metal concurrency without a runtime. Your “dead end” comment reeks of writing off an entire language feature because you don’t understand it or why it solves problems no other language feature solves as well.
Normally I’m open to discussing the merits and comparing drawbacks to certain approaches, but of course I’m going to be cross if you dump a bunch of confident horseshit on me. Like, wtf man??
I spent the necessary effort to experiment/work with the various approaches to form an opinion, and your main counter argument is largely … being sarcastic, trying the hardest to misunderstand things to ridicule them and being generally offended?
Let’s end this here, your comments are a poor use of my time.
Statements like “async is a language design dead-end” is the confidently correct misinfo that I’m talking about. You can’t expect anyone to take you seriously if you authoritatively present your opinions as gospel.
Should I instead have interpreted it as “async is a language design dead-end, and by dead-end I mean overfitted standard for the problem space?” Because I really have to be charitable and put words in your mouth to paint your argument in a good light.
I believe that if you start from an annotation-only stance, then you will look at the language, its defaults and possible extensions differently, because annotations are “visually” more expensive than slapping yet-another keyword on something.
I. e.:
varinstead oflet mut#[cfg(target_os = "windows")]is just bad design overallinstead put different targets into different folders: much easier, works better
asyncshould not exist at all(though not related to annotations vs. modifiers, but because the whole idea is a language design dead-end)
So the code from your example would literally be …
fun some_func: Unit = { var my_var = 3u2 // ...… in my design.
Rust’s syntax with
#[...]is not that great in this regard, as it triples the amount of symbol involved for simple annotations compared to something using@....Jfc that’s a bit of a stretch. You basically just said “you are wrong to use those features, and if you don’t use those features then my solution is great”. Like yeah, no shit, if I wanted a toy language I’d go back to using Logo.
For-fucking-real?
Ahh, yes, file-based programming, the most usable and ergonomic pattern for cross-cutting concerns. /s
The most I’ll give you there is that it’s used more frequently than it should. But it is far and away the best abstraction for bare-metal concurrency without a runtime. Your “dead end” comment reeks of writing off an entire language feature because you don’t understand it or why it solves problems no other language feature solves as well.
Normally I’m open to discussing the merits and comparing drawbacks to certain approaches, but of course I’m going to be cross if you dump a bunch of confident horseshit on me. Like, wtf man??
I spent the necessary effort to experiment/work with the various approaches to form an opinion, and your main counter argument is largely … being sarcastic, trying the hardest to misunderstand things to ridicule them and being generally offended?
Let’s end this here, your comments are a poor use of my time.
Statements like “async is a language design dead-end” is the confidently correct misinfo that I’m talking about. You can’t expect anyone to take you seriously if you authoritatively present your opinions as gospel.
Should I instead have interpreted it as “async is a language design dead-end, and by dead-end I mean overfitted standard for the problem space?” Because I really have to be charitable and put words in your mouth to paint your argument in a good light.