-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
> It's especially helpful that the library doesn't require you to opt into its own dedicated types, and instead defines extension methods on existing types.
Fun fact: bstr 0.1 went the route of defining its own dedicated types! See: https://docs.rs/bstr/0.1.4/bstr/
But it did indeed quickly prove to be pretty annoying. Because you still really want to use &[u8] in places because it's so ubiquitous. But to get access to the byte string methods, you had to explicitly convert it to another type.
The reason why I went that route initially was so you'd always get the good Debug impl. But it ended up not being worth it sadly. This issue discusses it a bit more: https://github.com/BurntSushi/bstr/issues/5
I think that would be an interesting API design to explore, absolutely. I think you'll have a lot of issues making it fast though. There is a fair bit of SIMD going on under the hoods in both the substring routines and the UTF-8 validation routines, for example. Building APIs based around iterator adapters that munch one byte at a time are difficult to square with SIMD optimizations that want to operate on a whole bunch of bytes at a time.
Consider, for example, how you might use a routine like memchr[1] if all of your public APIs are generic iterator adapters.
And then once you get into things like regex engines, modifying them to work on Iterator is a highly non-trivial affair. It is of course possible to write a regex engine that works on such things, but it's going to be limited in performance or capabilities. The way to make regexes and streaming work together is probably something more like Iterator (which is perhaps roughly analogous to what Hyperscan does). You really want blocks of bytes, not one-byte-at-a-time.
[1]: https://github.com/BurntSushi/memchr/blob/8037d11b4357b0f07b...
1) No. I think semver is just fine for its intended purpose. I mean, I'm sure its spec could be improved in various ways, but its fundamental idea seems fine to me. I think it's just important to remember that semver is a means to an end, and not an end itself. It is a tool of communication most useful in a decentralized context.
2) No.
3) See: https://github.com/rust-lang/rust-semverver --- But also, this is only ever going to be a "best effort" sort of thing. Semver isn't just about method additions or deletions, but also behavior.