JS is backwards compatible: new engines support code using old features.
JS is not forward compatible: old engines don't support code using new features.
Regarding your iPad woes, the problem is not the engine but websites breaking compat with it.
The distinction matters as it means that once a website is published it will keep working. The only way to break an existing website is to publish a new version usually. The XSLT situation is note-worthy as it's an exception to this rule.
No it doesn't. A global flag is a no-go as it breaks modularity. A local opt-in through dedicated types or methods is being designed but it's not stable.
I believe that you are describing `Vec::with_capacity` which allows to change the initial reserved memory on construction.
`reserve` and `reserve_exact` are used when mutating an existing vec. What you provide is not the total wanted capacity but the additional wanted capacity.
`reserve` allows to avoid intermediate allocation.
Let's say that you have a vec with 50 items already and plan to run a loop to add 100 more (so 150 in total).
The initial internal capacity is most likely 64, if you just do regular `push` calls without anything else, there will be two reallocations: one from 64 to 128 and one from 128 to 256.
If you call `reserve(100)`, you'll be able to skip the intermediate 64 to 128 reallocation: it will do a single reallocation from 64 to 256 and it will be able to handle the 100 pushes without any reallocation.
If you call `reserve_exact(100)`, you'll get a single reallocation for from 64 to 150 capacity, and also guarantee no reallocation during the processing loop.
The difference is that `reserve_exact` is better if these 100 items were the last ones you intended to push as you get a full vec of capacity 150 and containing 150 items. However, if you intend to push more items later, maybe 100 more, then you'd need to reallocate and break the amortized cost guarantees. With `reserve`, you don't break the amortized cost if there are follow-up inserts; at the price of not being at 100% usage all the time. In the `reserve` case, the capacity of 256 would be enough and let you go from 150 to 250 items without any reallocation.
In short, a rule of thumb could be:
- If creating a vec and you know the total count, prefer `Vec::with_capacity`
- If appending a final chunk of items and then no longer adding items, prefer `Vec::reserve_exact`
- If appending a chunk of items which may not be final, prefer `Vec::reserve`
That's a nice idea, thank you. I have personal blog, I'll try to clean it up a bit and provide performance measurements so it's worth posting.
Regarding the official documentation, I've returned to read them. I agree that the docs would benefit from more discussion about when to use each method. In particular, the code examples are currently exactly the same which is not great. Still, the most critical piece of information is there [0]
> Prefer `reserve` if future insertions are expected.
If anyone wants to reuse my explanation above, feel free to do it; no need to credit.
> I'm not sure if this isn't as common as I think it is - but what's wrong with typing `ip` into a terminal (that's always open anyway)?
I'm a regular Linux user, but I wouldn't know how to get all the data from the Wi-Fi applet using the Command Line. GUI have the advantage of discoverability over CLI: with a GUI I get a bunch of useful info in a single place, with a CLI I first need to know that a data is available and then I need to look-up the right invocation to get this data.
UI also represents an opportunity for standardization, which is a powerful force for onboarding non-technical users and in time, turning them into power users. Standardized patterns illustrate to users that there's a method to the madness and that computers are finite, learnable systems and not seemingly arbitrary chaos or unintelligible techno-wizardry.
Pypi doesn't have any issue distributing binaries either these days? The issue is (a) diversity of CPU/GPU microarchitectures inc. CUDA (b) diversity of OS-es.
I've never had to compile a native Node library on a POWER9 GPU cluster, but I have had to compile Python ones.
And the JS world has ESM modules, CommonJS, various polyfills for compatibility, and other quirks that need to be accommodated by the package manager. With native code compilation affected by these settings.
> I don't know much about go, and I've only scratched the surface with node, but as far as node goes I think it just distributes JS?
As a sibling comment posted, Node packages have no issue distributing non-JS assets. Since the very beginning, the "package.json" file had support for the "arch" and "postinstall" fields to distribute precompiled binaries or compile on install, for example using node-gyp. If you split your precompiled binaries and use optional dependencies then only the right package for your machine is downloaded.
In all package managers, distributing native code may be uncommon but it's always supported well enough (Node/npm/yarn, JVM/Gradle, PHP/Composer, Ruby/gem, Rust/Cargo, etc). What's unique about Python is how messy all the packaging handling is compared to other languages.
the amount of data i have stuffed into json as base64 encoded text makes me sick.
i wrote a glTF model converter once. 99% of those millions of JSON files I wrote were base64 encoded binary data.
a single glTF model sometimes wants to be two files on disk. one for the JSON and one for the binary data, and you use the JSON to describe where in the binary data the vertices are defined, and other windows for the various other bits like the triangles, triangle fans, textures, and other stuff are stored. But you can also base64 encode that data and put it in the JSON file and not have a messy double-file model. so that's what I did and I hated it. but it still felt better than having .gltf files and .bin files which together made up a single model file.
It's not cleanly one or the other, really. It's UCS-2-y by `str.length` or `str[i]`, but UTF-16-y by `str.codePointAt(i)` or by iteration (`[...str]` or `for (x of str)`).
Generally though JS's strings are just a list of 16-bit values, being intrinsically neither UCS-2 nor UTF-16. But, practically speaking, UTF-16 is the description that matters for everything other than writing `str.length`/`str[i]`.
• Regular indexing (also charAt and charCodeAt) is by UTF-16 code unit and produces UTF-16 code units.
• codePointAt is indexed by UTF-16 code unit, but produces Unicode code points (normally scalar values, but surrogates where ill-formed).
• String iteration doesn’t need indexing, and thus is Unicody, not UTF-16y.
• Approximately everything that JavaScript interacts with is actually UTF-8 now: URIs have long been UTF-8 (hence encodeURI/decodeURI/encodeURIComponent being UTF-8y).
• Where appropriate, new work favours UTF-8 semantics.
—⁂—
Overall, I’d say it’s most reasonable to frame it this way:
① JavaScript models strings as potentially-ill-formed UTF-16. (I prefer the word “models” to the word “represents” here, because the latter suggests a specific storage, which is not actually necessary.)
② Old parts of JavaScript depend on indexing, and use potentially-ill-formed UTF-16 code unit semantics.
③ New parts of JavaScript avoid indexing, and use Unicode semantics.
JS is backwards compatible: new engines support code using old features.
JS is not forward compatible: old engines don't support code using new features.
Regarding your iPad woes, the problem is not the engine but websites breaking compat with it.
The distinction matters as it means that once a website is published it will keep working. The only way to break an existing website is to publish a new version usually. The XSLT situation is note-worthy as it's an exception to this rule.