There are many use cases where having a value stream is very useful. I do agree having a separate simpler byte only stream would make sense though. I think the current capabilities of web streams should be kept and an IOStream could be added for optimizing byte streams.
Ideally splitting out the use cases would allow both implementations to be simpler, but that ship has probably sailed.
I don't like AI writing because it's bad writing. It's convoluted and inefficient and doesn't get to the point. If someone writes something that feels like AI, it doesn't matter if it was or not because it's still bad writing. I'm not talking about having a cliche here and there, but rather when the text is just incredibly inefficient.
If someone uses AI to help them write, and they reviewed it, and it's high quality writing, I don't care how much they wrote by hand. But, if I can tell it was written by AI that's just a proxy for telling that the author did not put time and care into what they were writing.
AI bloats text and every other task it does into convoluted redundant cliches. This is true for text and code. Whether it was written by an AI or not, it's not worth my time. If you wrote it 100% by hand and it still sounds like AI, it's still bad writing and still not worth my time.
It used to be better? I use android daily and was given an iPhone for work, and using it is incredibly painful because of the keyboard. I was wondering how people have been putting up with it for so long. When I've asked other long time iPhone users about it they just nodded along so I though it was a long running issue.
Very good questions! I still need to flesh out the patterns. While streams of streams are common in functional programming environments, I simply haven't seen them in class based streaming patterns anywhere so they're things to figure out.
Of course, more streams means more resource utilization, there's not getting around that, but that's the cost of parallelism. The use of `yield*` should keep the overhead to a bare minimum. Since the streams are being left alone and aren't consumed until needed, that should preserve some of the back-pressure behavior, although I do need to look into that more deeply.
How the system handles errors probably doesn't have a single solution that works for all frameworks, so I think it should be up to the specific requirements of each use case, but there's also definitely more work to do to explore the options and the patterns.
These are all things I definitely want to hear ideas for as well!
The next thing I'm exploring is applying these patterns to web rendering which will be a real stress test for how they can be used.
They cited the demo of a port having performance issues several months before release. That seems like a complete non story to me. It's brand new hardware and nobody has experience porting to or optimizing for its specific specifications yet. Early ports being unstable and requiring optimizations all the way up to or even past the release date is standard at the point in a hardware cycle.
I think there is a need for the AI counseling use case, but it should not be provided by a general purpose AI assistant. It should be designed by professional psychologists and therapists, with greater safeguards like human check-ins to make sure users get the help they need.
The best way to stop this is to make those safeguards stronger and completely shut down the chat to refer users to seek help from a better service. Unfortunately those services don't really exist yet.
There would be false positives and that'll be annoying, but I think it's worth it to deal with some annoyance to ensure that general purpose AI assistants are not used for counseling people in a vulnerable mental state. They are not aligned to do that and they can easily be misaligned.
Ideally splitting out the use cases would allow both implementations to be simpler, but that ship has probably sailed.
reply