Tesla's charger was proprietary so other manufacturers couldn't use it. Meanwhile CCS is an open standard that anyone can use.
What's changed is that last year Tesla decided to publish an open standard. Now that other manufacturers can use the plug, they gave agreed to use Tesla's physical plug design, but with the CCS signaling protocol.
So NACS going forward is more of a new hybrid of the two rather than a switch to Tesla's existing charger. One of the outcomes is that cars equipped with CCS will be able to use NACS with a simple adapter.
Why not use Tesla's signaling protocol? I don't know the details. Maybe Tesla isn't ready or able to create an open standard for that part. Or maybe other manufacturers want to keep the signalling they have to keep adapters simple. In any case only one vehicle and charging station manufacturer (Tesla) will have to make updates on the software side, and to people who don't know the difference between the plug and the software it'll look like Tesla won the charger war.
Oh, interesting! I'm not the most up-to-date on this, but I don't think I was all wrong about what I said. My understanding is that cars with CCS adapters currently cannot use Tesla chargers (except the Magic Dock ones), but Tesla now says they will change the signaling so that soon CCS cars will be able to use Tesla chargers with an adapter.
AFAICT "NACS" is a new thing as of November 2022. Maybe it's basically a renaming of Tesla's existing thing. But the shift to NACS includes important details around published specs and interoperability.
Just in case you're not aware, Soros conspiracy theories are a dog whistle for the less-publicly-acceptable "jews control the world" conspiracy theory. Of course it's not racist to criticize a specific person for specific actions. But that's not what the vast conspiracy theories around Soros are. Whether or not you are acting in good faith, you are repeating antisemitism (maybe unknowingly) when you bring this stuff up.
As someone who is not listening in on the flake stabilization process, and who just wants to use Nix my thinking is, what's the alternative? To me it looks like people can either build on the feature that exists now, or put plans on hold for who knows how long while getting by with some lesser solution, passing up public enthusiasm that could be directed to growing the Nix ecosystem in the meantime.
I'm getting the hint that some people aren't happy with the current state of flakes. But right now it's the best solution for a certain large class of problems so it's what people are going to go with. Again, as a relative outsider I see flakes as The Way Nix Works with the requirement of enabling experimental features just being a part of the Nix process. Nix is rapidly growing in popularity with a lot of people drawing the same conclusion as me. Maybe there is a better alternative to flakes in the horizon, and when it's ready I'll consider switching. But I'm not going to wait to use Nix in the meantime, and for me the best way to use Nix currently is flakes.
On the positive side hooks provide a lot of options for declarative abstractions. I expect that to a large extent the built-in hooks will be used as building blocks for new libraries. I think it is likely that this will outweigh the negatives.
On the other hand, hooks rely on hidden side effects so that each hook invocation returns something different depending on which component instance in the component tree is being rendered when the hook is called, and the number of times the hook has already been called while rendering that instance. This introduces semantics that are unlike anything I know of in the language. A redditor, u/hardwaregeek, pointed out that hooks behave kinda like a state monad, albeit emulated with imperative side-effects.
I'm happy to see this kind of detailed criticism. I would be happy to use a new tool if it is similarly general, and has a declarative style. Other commenters brought up Bazel, which I am looking forward to learning about.
Good point - cross platform issues are a concern. I've noticed in the past that OS X machines tend to run older versions of Make (unless the owner has installed a newer version with Homebrew). It is a good idea to pay attention to the Make features that you use, understand which features were added in recent versions, and be aware of which features are specific to GNU Make. In my projects I recommend that users make sure that they are in fact using GNU Make.
Some systems might not support the `-p` flag in `mkdir -p`, or the `-rf` flags in `rm -rf`. There are scripts distributed on NPM called `mkdirp` and `rimraf` to work around such issues.
I know that "Go vs Rust" has been written about before. The perspective I wanted to take with this post was to examine specific ways I think Go could be improved.
What's changed is that last year Tesla decided to publish an open standard. Now that other manufacturers can use the plug, they gave agreed to use Tesla's physical plug design, but with the CCS signaling protocol.
So NACS going forward is more of a new hybrid of the two rather than a switch to Tesla's existing charger. One of the outcomes is that cars equipped with CCS will be able to use NACS with a simple adapter.
Why not use Tesla's signaling protocol? I don't know the details. Maybe Tesla isn't ready or able to create an open standard for that part. Or maybe other manufacturers want to keep the signalling they have to keep adapters simple. In any case only one vehicle and charging station manufacturer (Tesla) will have to make updates on the software side, and to people who don't know the difference between the plug and the software it'll look like Tesla won the charger war.