5 ms·

I want colored functions. I want to know which code is running synchronously and which doesn't, which raises errors and which doesn't. Color is just a descripti

I want colored functions. I want to know which code is running synchronously and which doesn't, which raises errors and which doesn't. Color is just a description of the function's properties (and effects) and how it's compatible with other colors. There is also nothing fundamentally bad with cooperative scheduling in scope of a single process.

jerf 3y ago
I got into programming in the 1990s. At that point in time, there was still a large contingent of programmers loudly insisting they needed assembly language to do everything. And to be clear, I mean, everything. Not "Yeah, I can't really bring up an OS without a bit of specialized assembly" but "every programmer should write every program in assembly". The vast majority of them were already wrong. They only got more wrong. You may just be used to knowing what code is "synchronous" and what isn't because it's been shoved into your face and you've adapted your thought process to it. In practice, "everything important is doing something 'asynchronously'" turns out to be the vast majority of what you need, and the vast majority of your mental energy you are dedicated to splitting the world in two is a waste. For the little bit that remains, by all means use something specialized, but it's just not something that everyone, everywhere, needs to be doing all the time, any more than everyone everywhere should be manually allocating registers, or any more than programs need to have line numbers because otherwise how can they work? (One of my favorites because I remember having that conception myself.)
- the_af 3y ago
  I think you have your analogy backwards: the "assembly programmer" in this situation is the person who doesn't understand why one would "color" functions and/or express a fundamental property as part of their types. "Why do we need to express this in their type? Every programmer should be able to understand this without help".
dgb23 3y ago
To me this kind of sounds like circular reasoning. Without function coloring there's no distinction that you need to know of. Can you elaborate?
- brigadier132 3y ago
  > Without function coloring there's no distinction that you need to know of Why do you think you don't need to know of it? I want to know if the function I'm calling is going to make a network request. Just because I can have a programming language that hides that distinction from me doesn't mean I want that. Ideally I want to have the fundamental behavior of any function I call encoded in the function signature. So if it's async, I know it's going to reach out to some external system for some period of time.
  - dgb23 3y ago
    > I want to know if the function I'm calling is going to make a network request. That has nothing to do with function coloring. > Ideally I want to have the fundamental behavior of any function I call encoded in the function signature. There is no distinction of async functions if you don't have function coloring that you can encode in type signatures.
    - brigadier132 3y ago
      > That has nothing to do with function coloring. Sure, in the same way that types have nothing to do with enforcing logical correctness of software. > There is no distinction of async functions if you don't have function coloring that you can encode in type signatures. What are you trying to say with this statement?
      - kprotty 3y ago
        getaddrinfo() is a synchronous function that can do network requests to resolve DNS. The network property isn't reflected in its function signature becoming async. You can have an async_getaddrinfo() which does, but the former is just a practical example of network calls in particular being unrelated to function coloring.
- hgomersall 3y ago
  It's nonsense. Async in rust is just syntactic sugar around a function signature. You can merrily call async functions from sync rust, you just have to know what to do with the future you get back.

jerf 3y ago

I got into programming in the 1990s. At that point in time, there was still a large contingent of programmers loudly insisting they needed assembly language to do everything. And to be clear, I mean, everything. Not "Yeah, I can't really bring up an OS without a bit of specialized assembly" but "every programmer should write every program in assembly". The vast majority of them were already wrong. They only got more wrong. You may just be used to knowing what code is "synchronous" and what isn't because it's been shoved into your face and you've adapted your thought process to it. In practice, "everything important is doing something 'asynchronously'" turns out to be the vast majority of what you need, and the vast majority of your mental energy you are dedicated to splitting the world in two is a waste. For the little bit that remains, by all means use something specialized, but it's just not something that everyone, everywhere, needs to be doing all the time, any more than everyone everywhere should be manually allocating registers, or any more than programs need to have line numbers because otherwise how can they work? (One of my favorites because I remember having that conception myself.)

the_af 3y ago
I think you have your analogy backwards: the "assembly programmer" in this situation is the person who doesn't understand why one would "color" functions and/or express a fundamental property as part of their types. "Why do we need to express this in their type? Every programmer should be able to understand this without help".

dgb23 3y ago

To me this kind of sounds like circular reasoning. Without function coloring there's no distinction that you need to know of. Can you elaborate?

brigadier132 3y ago
> Without function coloring there's no distinction that you need to know of Why do you think you don't need to know of it? I want to know if the function I'm calling is going to make a network request. Just because I can have a programming language that hides that distinction from me doesn't mean I want that. Ideally I want to have the fundamental behavior of any function I call encoded in the function signature. So if it's async, I know it's going to reach out to some external system for some period of time.
- dgb23 3y ago
  > I want to know if the function I'm calling is going to make a network request. That has nothing to do with function coloring. > Ideally I want to have the fundamental behavior of any function I call encoded in the function signature. There is no distinction of async functions if you don't have function coloring that you can encode in type signatures.
  - brigadier132 3y ago
    > That has nothing to do with function coloring. Sure, in the same way that types have nothing to do with enforcing logical correctness of software. > There is no distinction of async functions if you don't have function coloring that you can encode in type signatures. What are you trying to say with this statement?
    - kprotty 3y ago
      getaddrinfo() is a synchronous function that can do network requests to resolve DNS. The network property isn't reflected in its function signature becoming async. You can have an async_getaddrinfo() which does, but the former is just a practical example of network calls in particular being unrelated to function coloring.
hgomersall 3y ago
It's nonsense. Async in rust is just syntactic sugar around a function signature. You can merrily call async functions from sync rust, you just have to know what to do with the future you get back.