Thanks for the great insights! Really appreciate your suggestions.
We haven’t tried doing an AMA yet, but that sounds like a great idea. As for use cases, we’ve written some, but they might be too high-level—more focused on what users are building rather than how they’re implementing it in detail.
Do you think deep-dive technical breakdowns (e.g., architecture decisions, implementation challenges) tend to spark more discussions? Or have you seen good examples of projects that did this well?
Thanks for the input! You're right, the OSS license, active committers, and accepting outside PRs are key points. We'll include them next time. Appreciate the suggestion!
In my experience no/low code tools are fine until they are not, and until you follow the narrow path.
It's highly likely you'll have some requirements that cannot be satisfied by the tool.
If you are a dev, code is the best interface. If you are not a dev, don't want to be one, and you can shoulder the risks, sure go ahead.
If you are a manager and want to push a no code tool, you will regret it and your team will resent you.
Balancing usability with control is an art. It's crucial to offer tools that are accessible yet robust enough to not leave users feeling like they've lost control over the customization and scalability of their projects.
The completion level is impressive! I can hardly tell the difference from a human voice, especially with the natural pauses and laughter, which surpasses ChatGPT’s quality. However, there’s a noticeable electric noise at the end of sentences, which feels unnatural. (As a native Chinese speaker, I find the Chinese output even better in comparison.)
Exactly. If he hadn’t been under the influence then the door latch system wouldn’t have had a defective design
>The suit blamed the “propensity of the vehicle to catch fire, as well as the defective design of the door latch system entrapping him in the vehicle.”
Not parent-poster, but I did a bit more digging since (the linked article is terribly incomplete) and found out that not only did the driver also die, but the passenger was also tested (posthumously?) as being over the legal BAC limit.
> If he hadn’t been under the influence then the door latch system wouldn’t have had a defective design
So... Poe's Law here. I can't tell if this is a sarcastic comment pointing out that a defective design remains defective even if someone is drunk, or whether this is a serious comment implying it wasn't really defective in normal circumstances.
In any case, the person who was trapped-and-died was the passenger, and we don't know if or how-much they were drunk.
The driver survived... or else they're making a lawsuit from beyond the grave.
Correction since I can't edit: Both driver and passenger died and the plaintiff(s) do not include the driver. That said, I blame this on the linked-article being crap: Despite discussing the passenger's death, it never says any other person in the car died, which normally means they survived.
Instead, the driver died on the scene and the passenger later in a hospital [0]. More digging shows driver and passenger were (probably posthumously) tested at 0.21 and 0.17 BAC respectively. [1]
That wasn't what the case was about. It was about the propensity of the car to catch on fire and faulty door latch design that prevented the passenger who survived the impact from getting out.
> Tesla maintains there was nothing wrong with the car. It said the data event recorder showed that Speckman kept her foot on the accelerator pedal before the crash and never attempted to brake.
The family settling could seen as support for this claim. If it really did accelerate randomly, that seems like more of an NHTSA (or whoever) sort of thing more than something that could be settled.
This wasn't an unintended acceleration case or a driver assistance case. The case is entirely about the car catching fire and being impossible to escape.
Nah: If anybody was actually holding Musk "ultimately at fault regardless of anything else", we wouldn't be talking about settling a product-safety lawsuit, but instead about a criminal trial for manslaughter.
Since that's not the case--and I don't think anyone has even suggested it needs to be--we can safely infer that there's already a high degree of nuance and splitting of different levels and layers of responsibility going on.
At the end of the day, "operator error"--even drunken operator error--is not enough to automatically negate all safety flaws.
Thank you for the insight and advice. I initially created multiple accounts to confirm if my posts were visible to others, but I understand now how that can be problematic. I appreciate the reminder and will be more mindful going forward. Thanks again for your help!
