this post was submitted on 19 Apr 2026
1 points (57.1% liked)

Programming

26579 readers
124 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[โ€“] soc@programming.dev 1 points 5 hours ago* (last edited 1 hour ago) (1 children)

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 @....

[โ€“] sidelove@lemmy.world 1 points 11 minutes ago

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??