you are learning what it takes to keep a machine up and running. You still witness the breakage. You can still watch the fix. You can review what happened. What you are implying from your question is that compared to doing things without AI, you are learning less (or perhaps you believe nothing). You definitely are learning less about mucking around in linux. But, if the alternative was not ever running a linux machine at all because you didn't want to deal with running it, you are learning infinitely more.
You can learn a lot from watching your doctor, plumber or mechanic work, and you could learn even more if you could ask them questions for hours without making them mad.
You learn less from watching a faux-doctor, faux-plumber, faux-mechanic and learn even less by engaging in their hallucinations without a level horizon for reference.
Bob the Builder doesn't convey much about drainage needs for foundations and few children think to ask. Who knows how AI-Bob might respond.
The full picture of what exactly? How that fact is even relevant to this post? Do you expect anyone affiliated with AI to mention that every time they talk about AI? That's just ridiculous.
I expect someone writing a blog about AI agents help you run your home server to disclose that they are "helping companies automate operations with AI" as their job, which they get money for.
Why wouldn't you bring it up, or even lead with it?
Doesn't it make sense to want to know this? It's not far fetched at all that there is a conflict of interest. How can they be unbiased in the validity of the approach if this is exactly the same stuff they sell for money?
If international law had any effect people would believe in it. You're mixing cause/effect. This situation has been going on for years and the lack of response by international organizations makes people lose all confidence in them.
I'm unfortunately on the same situation. We made a consultation with people from Baptist Health Miami and it seems like there are several non trivial requirements for such treatment (histotripsy), like the number and location of mets. Hope that this improves in the mear future.
Well, I guess? Using TRAMP with large projects is not a pleasant experience. It works great for one-off files and remote bookmarks etc, but for working with large projects you're better off mosh/ssh-ing into the server and using Emacs there. With things like term-keys [1] you can use all the keys there as well. Basically only missing out on images and variable fonts, both of which are none issues for me at least when programming.
> Zig must also be good for eliminating the same ones.
But Zig does not eliminate them, but rather it might catch them at runtime. The difference here is that Rust promises that it will detect them at compile time, long before I ship my code.
> The property of memory safety is itself not binary in both languages
In this case it is: either you catch the issue at compile time, or you don't. This is the same as type safety: just because Python can detect type errors at runtime it does not mean that it's as "type safe" as, for ex. Haskell. This might be due to imprecise usage of terms but that's just the way it's discussed in the craft.
Aren't green threads and async-await orthogonal concepts?
As I understand it async-await is syntax sugar to write a state machine for cooperative multitasking. Green "threads" are threads implemented in user code that might or might not use OS threads. E.g.:
- You can use Rust tokio::task (green threads) with a manually coded Future with no async-await sugar, which might or might not be parallelized depending on the Tokio runtime it's running on.
- ...or with a Future returned by an async block, which allows async-await syntax.
- You can have a Future created by an async function call and poll it manually from an OS thread.
- Node has async-await syntax to express concurrency but it has no parallelism at all since it is single-threaded. I think no green threads either (neither parallel or not) since Promises are stackless?
Is this a new usage of the term I don't know about? What does it mean? Or did I misinterpret the "but"?
As a non-Haskeller I guess it doesn't need explicit async-await syntax because there might be some way to express the same concept with monads?
You don't need "monads" (in plural) since GHC provides a runtime where threads are not 1:1 OS threads but rather are managed at the user level, similar to what you have in Go. You can implement async/await as a library though [1]
Well, I haven't used Haskell in a few years, so I could absolutely be wrong. That being said, I'm almost sure that I saw a presentation by Simon Marlowe 15-20 years ago demonstrating GHC with a multicore scheduler (alongside `seq` and `par`). Also, from the very same Simon Marlowe, there's a package called `async` https://hackage.haskell.org/package/async which basically provides async (no await, though).
> Knowing if a function will yield the thread is actually extremely relevant knowledge you want available.
When is this relevant beyond pleasing the compiler/runtime? I work in C# and JS and I could not care less. Give me proper green threads and don't bother with async.
Knowing when execution will yield is useful when you want to hold onto a thread. If you run your GUI related async tasks on the GUI thread you don't have to worry about locks or multi threaded data structures. Only a single GUI operation will happen at a time.
If yields are implicit, you don't have enough control to really pull that off.
Maybe it's possible but I haven't seen a popular green threaded UI framework that let's you run tasks in background threads implicitly. If I need to call a bunch of code to explicitly parcel background work, that just ends up being async/await with less sugar.
> I am spending time using software, learning
What are you actually learning?
PSA: OP is a CEO of an AI company
reply