3 ms·

> I actually really like Rust the language but I think I don’t like Rust codebases basically. And > everyone always reaches to the most clever way to do thin

• Conscat 2y ago
  There already exist many affine-typed languages with fewer features than Rust. When you phrase it like "Rust but with weaker type safety and higher-overhead abstractions" one might see why this premise fails to gain much traction, though.
• aw1621107 2y ago
  > By "no dependence on run times." I mean no async/await. It is an abomination in Rust Out of curiosity, what alternative would you have preferred to see, if any?
  • worik 2y ago
    Non blocking standard library functions I find it astounding that so many people think asynchronous programming means async/await Asyc/await is a way of letting programmers who do not want to learn how, do asynchronous programming. It has poisoned the well
    • xedrac 2y ago
      I've been doing asynchronous programming for decades, and async/await is a notable improvement for many use cases. Event loop + callback hell, or condition variable/mutex/semaphore approaches are great in some cases, but they suck in others.
      • worik 2y ago
        > I've been doing asynchronous programming for decades, and async/await is a notable improvement for many use cases. I think that goes to taste. > Event loop + callback hell That was always due to indisciplined programming. Async/await offers up other hells. I think it makes some sense in memory managed systems. But in a system with static compile time management like Rust async/await forces all sorts of compromises. Mostly these fall on library authors, but it is its own hellscape. `Pin`? > great in some cases, but they suck in others That is a universal refrain for software systems!
    • aw1621107 2y ago
      > Non blocking standard library functions What approach are you thinking of for the API of those functions, since async/await is not something you'd like to see?
      • mfenniak 2y ago
        I believe this is reference to Go's approach, where code can be written in a linear straightforward fashion with normal function calls, but, if they are syscalls then they become async automatically. I don't think it's appropriate for the level of coding that Rust is targeting... But... It would be nice.
        • aw1621107 2y ago
          I suppose that makes sense given OP's definition of "no dependence on run times", but I think I'd have to agree that that approach probably wouldn't work well for the niche Rust is trying to target.
        • worik 2y ago
          > I believe this is reference to Go's approach, I am unfamiliar with GO. I am thinking of the way the C library does it. > I don't think it's appropriate for the level of coding that Rust is targeting That would be low level system programming. In part
          • aw1621107 2y ago
            > I am thinking of the way the C library does it. What way is that? I didn't think the C standard library had any understanding of blocking/non-blocking.
            • worik 2y ago
              O_NONBLOCK
              • aw1621107 2y ago
    • dwattttt 2y ago
      I very much do not want to go back to the days of "read up to 4 bytes off the wire to see how big the next chunk is. Oh I only read 3 bytes? Guess I'd better save those 3 + the fact I need to read 1 more, then drop back out to the event loop"
      • worik 2y ago
        > I very much do not want to go back to the days of .... Not what I recommend. The C library does much better than that. In asynchronous programming you can only deal with the data you have, so you buffer it. I have not counted bytes like that - for the purposes of reading from a file, in decades.
        • dwattttt 2y ago
          But that's where non-blocking leads; it can't block until it reads all the bytes you asked for, that has to be handled somehow. A fancy C library could buffer the partial read for you rather than you needing to do it, and it could even maybe deal with turning your function into the state machine required to resume the function at the partial read. But then you look around and realise you've created another async/await.