The EV market has already hit a plateau, suggesting that it has exhausted the customer base for very expensive cars with short ranges. September 2019 sales were down (US and global) vs 2018, and 2019 Q3 sales were down vs Q3 2018 as well (also for the US and globally). These sales figures suggest that EVs need something new, like lower prices or more utility, to start growing again.
How do you determine sales (demand) plateau vs. sales (manufacturing capacity or brand loyalty having customers wait for their brand to ship) plateau vs. model availability plateau (i.e. no electric truck is shipping today, no fullsize SUV, no minivan, etc.)?
TCO my math has EV better than ICE already even in the US with lower fuel prices and typically higher mileage per day than EU.
It does have a lot of features but my beef with it is how its integration into Debian still leaves all the misleading old cruft laying about. Take the MySQL server package. Suppose you want to change the limit of how much shared memory it can use. Well, the package comes with an init script, let’s put the ulimit statement in there. Restart. No effect. Ok, limits.conf. Restart. No effect. Ok, edit mysqld_safe script. Restart. No effect. Oh I figured it out, systemd ignores all these things and you have to set limits in its service file. But if you set it to ‘unlimited’ it silently ignores the statement. You have to say ‘infinity’ for some reason.
All this crud has just been left here to confuse users and I hate it.
That isn't accurate. Sonos works perfectly well on an isolated network, reading your music from a local SMB share or getting it from the line-level input of any Sonos on the network.
I worked on trying to make flatbuffers work at google and it just never was as fast as proto2/c++. I guess the author of this piece would describe me as an amateur because like the authors of protocol buffers I only have about thirty years of industry experience. AMA.
I'd be really interested in hearing why it wasn't faster! I expect the answer is along the lines of: "Well theoretically the zero-copy design should be faster, but in practice factors X and Y dominate performance and Protobuf wins on those." I'd love to know exactly what X and Y are...
(I'm the original author of proto2/c++, but I'm mostly interested for any lessons that might apply to my work on Cap'n Proto...)
The C++ proto implementation is just already tuned to an absurd degree and it is hard to beat. Any place where copying was an important problem has already been eradicated with aliasing (ctype declarations) so flatbuffers' supposed advantage isn't there to begin with. It's much more important to eliminate branches, stores, and other costs in generated code.
I'm guessing you were trying to use it with Stubby?
Admittedly the networked-RPC use case is not a particularly compelling one for zero-copy (the mmaped-file case is much more so, and maybe even shared-memory RPC).
Still, I'd expect that not having to parse varints nor allocate memory would count for something. Wish I could see the test setup.
They are the same size as UTF-8 numbers but much slower to decode. I think the more-bit format is the only glaring mistake in proto that can never be fixed.
I agree. Preserving unknowns fortunately was recognized as mistake, and fixed in some more recent version, and presence can be worked around: it is still preserved for message types, so you only need to wrap your primitives into objects[1], Java style.
Sorry, I meant not preserving unknowns was also wrong. Proto2 did preserve them, then proto3 didn’t, and then they realized it was a bad idea and went back to preserving them.
This gets to the article's issue but from the dynamic typing angle as well.
By not allowing presence checks, one has to use convention _in every single class_ to determine basic things like PATCH semantics (https://github.com/protocolbuffers/protobuf/issues/359). This makes it impossible to treat protobuf as a general data format and requires object-specific logic to properly composite data structures. In some cases it's impossible to even do PATCH correctly without excluding sentinel values from the allowed range and having the application developer know about it.
There are so many other problems with Proto v3, but this one is glaring.
It can be approximated with a single-item `oneof` field. It's ugly and boilerplatey, but at least it's binary-compatible with proto2 and gives the original behaviour.
My main problem with proto2 these days is that I needed to interface with some C# code, and there is no proto2 library for C#!
Personally I even like this more since this feels much more explicit. The idea of depending on being set to the null value or unset at all gets my spider sense shivering and shuddering; someone is going to miss this, probably me.
Dude, there are tons of packages for doing Protobuf in C#, I've been writing systems in C# that used proto for over three years I think at this point. Here's one for starters: https://www.nuget.org/packages/protobuf-net
You can just skip messages, strings, and byte arrays you don’t need or can’t decode. They are length-prefixed. Also there’s nothing about proto that prevents it from being aliased to its network buffers (zero copy). The GPs complaint stems from their own ignorance, nothing to do with the nature of protos.
“Many” is almost underselling it. It’s literally EVERY web browser that anyone uses. I don’t know where people get these ideas. OP has a shallow understanding of programming languages, software development, and their history.
> It’s literally EVERY web browser that anyone uses.
And is a fine example of path dependence.
No one can write a browser in any other language not because C++ is necessarily better but because the activation energy to bootstrap to a useful browser is so large (for example, one must provide a smoking fast Javascript engine before one even considers the web page rendering pipeline).
It will be interesting to see how much of the Firefox codebase gets taken over by Rust as time passes.
Basically, C++ developers (like me) are stupid. We're like primitive species, stuck with C++ because we can't understand superior languages. The Lisp developers tried to bring us the light, but we chased them away by throwing rocks at them. Now the Rust evangelists are doing the same thing, but I'm afraid we might take a break from writing video games, stock exchange software, safety-critical software, CAD packages, web browsers, video codecs and the like, to throw rocks at them.
My point is: maybe C++ actually _is_ the superior language. It can't be a coincidence that all the best software projects tend to be written in C++, and not in Haskell or whatever.
> My point is: maybe C++ actually _is_ the superior language. It can't be a coincidence that all the best software projects tend to be written in C++, and not in Haskell or whatever.
If we're going by best software written, I suspect that means C is the better language than C++ by a wide margin. It would be interesting as to whether Visual Basic would be superior on that axis as well.
C++ is the better language--except that we always have to expose a C FFI because nobody seems to have enough critical mass to stabilize the library ABI. C++ is the better language--except that Apple wrote another language because they don't believe that and that Mozilla wrote Rust because C++ wasn't good enough. C++ is the better language--as long as you have a new codebase that only uses the latest features and Satan help you if you have stuff from pre-2005 because God won't be enough. C++ is the better language--as long as compile time isn't an issue.
I can go on if you wish...
I don't think C++ developers are stupid and those choosing to start new projects in it generally have really good reasons for doing so. I also think that many older projects are in C or C++ via path dependence because C++ was the superior choice when the project started and now they have far too much code to switch.
I also believe this will be why Rust eventually becomes a very important language--Rust allows you to modernize that old codebase in a piecemeal fashion.
Dunno. As a mainly C++ developer I think Rust is a real alternative because it tries to solve the same problems better. Lisp and Haskell do not solve the same problems. Huge Lisp codebases probably become hard to understand quickly, and both Lisp and Haskell don't produce very efficient code (or make it hard to produce efficient code).
Time will tell. At the moment I'm not convinced. Rust is a marginal improvement which is not worth the trade-offs in terms of immaturity, lack of libraries, books, standardization, etc. It might end up just like D. Or it might actually find itself a viable niche.
AFAICS D screwed up with its "optional" but really not optional if you want to use the standard library garbage collection. Rust contains no such mistakes, and seems to contain fewers mistakes than C++. Any experienced C++ programmer should know that C++ contains plenty of mistakes. Exceptions are very awkward, the string class is useless, hash maps are much slower than they could be (the std API enforces that), modules should have appeared 20 years ago, non-const references as stealth pointers are bad for readability, [...]
It's basically no better than vector<my_char_type> - i.e. it has no Unicode support whatsoever and very few string-specific convenience methods. Using algorithms is possible, but tedious.
Well, you just kinda answered your question. There is STL, Qt and Boost. Like all other languages. They do the same thing but in different capacities, you should select based on your needs. I think std::string can be supplemented for Unicode support, I am gonna say the fmt library was the supplement but I feel like I am wrong.
I used std::string and QString extensively for 4-5 years and find QString inexplicably bloated and un-intuitive for my use cases.
I don't understand your problem with QString, but anyway, AFAIK the common way to get Unicode support with std::string is ICU. ICU is quite large (~15-20 MB binary) and it breaks binary compatibility with every release.
> "[Lisp and] Haskell don't produce very efficient code (or make it hard to produce efficient code)."
Curious here. Are you speaking from experience -- i.e. you tried and failed -- or is this simply something you guess must be true? People write high-performance software in Haskell, and it's their tool of choice.
> People write high-performance software in Haskell, and it's their tool of choice.
I've heard of those but have never managed to see one. Do you have some examples ? (to give you my "baseline" - handling >500k messages/second on a desktop cpu for instance as this is something quite easily achievable in C++)
