so upon rereading this i kinda get why racket made each choice in turn, but one decision i personally don't like was the one to make parallel and coroutine threads interchangeable https://blog.racket-lang.org/2025/11/parallel-threads.html i have absolutely no doubt that doing so produced exciting benchmark improvements, but i kinda thought racket's thing was doing very powerful type safety you can really only get with a macro system?
Post
Replies:
7
@hipsterelectron type "safety" has never been a big part of racket. its mostly language expressivity through the macro system. the type system + macros are experiments in this line of research
@milo thanks a lot i really appreciate this
@hipsterelectron well... what they mean by safe gradual typing is type soundness, which means that the type annotations never lie about the actual values flowing through the program. some of the people working on racket having done a lot of work on the academic side for what type soundness means and therefore they have a somewhat narrow view, like for example dynamically typed racket is sound because it can only ever throw exceptions, not segfault
@hipsterelectron my point is that they aren't likely to go beyond this definition and claim things such as, the type systems could prevent concurrency bugs, because concurrency bugs simply aren't part of the definition of type soundness in this context
Racket is the first language to support higher-order software contracts and safe gradual typing. Programmers can easily deploy these tools to harden their software.
they said several times that they fixed the parallelism bugs (and i'm sure they did) but this bit on atomic mode irks me:
in many cases, Racket core libraries that need finer-grained locking more specifically need to move away from using atomic mode.
to me, making a change that suddenly turns existing code into a silently pessimal state sounds like the worst possible case for eventual performance improvement. i was so ready to be wowed by racket's powerful tools to represent data sharing!
Racket is the first language to support higher-order software contracts and safe gradual typing. Programmers can easily deploy these tools to harden their software.
they said several times that they fixed the parallelism bugs (and i'm sure they did) but this bit on atomic mode irks me:
in many cases, Racket core libraries that need finer-grained locking more specifically need to move away from using atomic mode.
to me, making a change that suddenly turns existing code into a silently pessimal state sounds like the worst possible case for eventual performance improvement. i was so ready to be wowed by racket's powerful tools to represent data sharing!
and then this part demonstrates my unfamiliarity w racket (and lack of standing to meaningfully critique) but this just surprised me:
Foreign functions that are called by Racket in a coroutine threads are effectively atomic operations when there are no parallel threads, since a coroutine swap cannot take place during the foreign call.
honestly i'm just gonna have to look up coroutine threads right now because i assumed coroutines were things you could explicitly stop and restart. it sounds like "coroutine" is describing the implementation and they're not linked to a language-level coroutine object
