I opened with the fact that it raises interesting points. I'm not sure that classifies as leaning hard one way. I'm taking an issue with the arguments being weak rather than author's entire position.
I generally start with reasonable things, and then migrate to pushing into all the weird technical things (maintain safety while implementing base data structures on top of unsafe primitives), etc
This seems like a difficult thing to solve for a language with a C-like model of the stack.
I suspect so.
This is sort of like Concurrent Data Structures in AoT compiled languages. People say "Oh, we solved that." and then you ask "So, since we don't have GC, which thread gets charged for cleanup and when?" and suddenly they look askance and start mumbling. :)
I have solved this in a lot of different ways. Sometimes events; sometimes I track my own equivalent to the stack; etc. However, just because a language makes those possible doesn't mean that they weren't painful.
It's a silly because of the usual "we live in a society". There's barely anything we can do these days without "accepting endless amounts of violence" depending on how far you go with the definition of that concept. And then it's not even about the AI anymore, but the whole idea of how we organise the modern life. Escalating the wording to endless violence just leads to Tumblr style one-uping about purity.
Why is the notion of accepting that AI is built upon accepting the violence inherent to creating the models silly? The examples in the post are pretty clear on how these large corporations use violence to create their thing and how that relates to Fascism as an ideology.
Ya exactly! I built my wife's laptop out of older parts when I upgraded. When I upgrade to the stuff they just announced I'll probably end up with some extra parts.
I may hook up a mainboard to my NAS and run some more intense home server stuff. Or alternatively try and sell it
Why doesn't my blog count? It's my primary income source at the moment, and features Claude Code built for me there (the sponsor banners, the infrastructure for my new guides section) have already paid for Claude Code Max subscriptions many times over.
Most of the code I write is open source, which makes assigning revenue to it a little hard!
What I value is my time. Claude Code saves me dozens of hours a month, which is time I can spend on activities that make money - mainly consulting calls and writing/researching for my site.
A Context can be obtained at any point in the call stack with context.Background(), so it's not the same problem as "what color is your function" describes. You can also store contexts in things (even in global variables), which isn't possible with the abstract notion of deferrability described by JavaScript async etc.
The obvious comparison to JavaScript's async is Haskell's IO a, but:
Haskell has an escape hatch (unsafePerformIO); JavaScript has no way to block on an async function from within a non-async function.
Haskell programmers are more used to thinking about program architecture than JavaScript programmers, so the layout of functions returning IO is less likely to get tangled up with the non-IO logic.
A lot of the complaints about function coloring seems to be someone who dropped some IO deep into the middle of their program's business logic, and now they're unhappy that they have to propagate that monad up the call stack.
IMO the original function coloring article is about a problem unique to JavaScript.
Other languages solve it by having threads (either provided by the OS or runtime) and blocking synchronization. It's always possible to run a function in a sub-thread and just block on a mutex or channel or whatever until it finishes. There's no concept of "this function's API must be callback-based because its implementation uses a callback-based function".
JavaScript has no user-accessible threading API, so if you're in a normal function and need to use a setTimeout-based callback you're just screwed. It has Promise now but it's just a wrapper around callbacks -- you can't await some_promise; in a non-async function.
I opened with the fact that it raises interesting points. I'm not sure that classifies as leaning hard one way. I'm taking an issue with the arguments being weak rather than author's entire position.
Raytracer. Everytime. Why? I have no idea :D
I generally start with reasonable things, and then migrate to pushing into all the weird technical things (maintain safety while implementing base data structures on top of unsafe primitives), etc
agent-shell by xenodium. I use it for all interaction with Claude Code. Wonderful.
Magit.
I am most excited about the MNT Reform platform (and the latest "MNT Reform Next" iteration): https://mntre.com/index.html
Congratulations!
The example was JS, not Rust. In JS they start when created.
I suspect so.
This is sort of like Concurrent Data Structures in AoT compiled languages. People say "Oh, we solved that." and then you ask "So, since we don't have GC, which thread gets charged for cleanup and when?" and suddenly they look askance and start mumbling. :)
I have solved this in a lot of different ways. Sometimes events; sometimes I track my own equivalent to the stack; etc. However, just because a language makes those possible doesn't mean that they weren't painful.
You know what's even more competent than an AI agent, and costs nothing? Original thought.
It's a silly because of the usual "we live in a society". There's barely anything we can do these days without "accepting endless amounts of violence" depending on how far you go with the definition of that concept. And then it's not even about the AI anymore, but the whole idea of how we organise the modern life. Escalating the wording to endless violence just leads to Tumblr style one-uping about purity.
That's such a nonsense that I'm not even reading any further. :D
Why is the notion of accepting that AI is built upon accepting the violence inherent to creating the models silly? The examples in the post are pretty clear on how these large corporations use violence to create their thing and how that relates to Fascism as an ideology.
Exactly. That's why loops are the problem, and I would not recommend anyone doing it. :D
All the posts on this thread are great. 2 packages that come to mind that really changed how I interact with stuff moment to moment:
Ya exactly! I built my wife's laptop out of older parts when I upgraded. When I upgrade to the stuff they just announced I'll probably end up with some extra parts.
I may hook up a mainboard to my NAS and run some more intense home server stuff. Or alternatively try and sell it
Why doesn't my blog count? It's my primary income source at the moment, and features Claude Code built for me there (the sponsor banners, the infrastructure for my new guides section) have already paid for Claude Code Max subscriptions many times over.
Most of the code I write is open source, which makes assigning revenue to it a little hard!
What I value is my time. Claude Code saves me dozens of hours a month, which is time I can spend on activities that make money - mainly consulting calls and writing/researching for my site.
A
Contextcan be obtained at any point in the call stack withcontext.Background(), so it's not the same problem as "what color is your function" describes. You can also store contexts in things (even in global variables), which isn't possible with the abstract notion of deferrability described by JavaScriptasyncetc.The obvious comparison to JavaScript's
asyncis Haskell'sIO a, but:unsafePerformIO); JavaScript has no way to block on anasyncfunction from within a non-asyncfunction.IOis less likely to get tangled up with the non-IO logic.A lot of the complaints about function coloring seems to be someone who dropped some IO deep into the middle of their program's business logic, and now they're unhappy that they have to propagate that monad up the call stack.
IMO the original function coloring article is about a problem unique to JavaScript.
Other languages solve it by having threads (either provided by the OS or runtime) and blocking synchronization. It's always possible to run a function in a sub-thread and just block on a mutex or channel or whatever until it finishes. There's no concept of "this function's API must be callback-based because its implementation uses a callback-based function".
JavaScript has no user-accessible threading API, so if you're in a normal function and need to use a
setTimeout-based callback you're just screwed. It hasPromisenow but it's just a wrapper around callbacks -- you can'tawait some_promise;in a non-asyncfunction.evil, of course. Emacs is a nice operating system, but it needs a good text editor. evil addresses that very competently.
The best color is context.Context