However, we’re still implementing IPv6, so how long until we could actually use this?
We can already use custom verbs as we please: we only need to have clients and servers agree on a contract.
What we don't have is the benefit of high-level "batteries included" web frameworks doing the work for us.
Why restrict to 54-bit signed integers?
Because number is a double, and IEEE754 specifies the mantissa of double-precision numbers as 53bits+sign.
Meaning, it's the highest integer precision that a double-precision object can express.
I suppose that makes sense for maximum compatibility, but feels gross if we’re already identifying value types.
It's not about compatibility. It's because JSON only has a number type which covers both floating point and integers, and number is implemented as a double-precision value. If you have to express integers with a double-precision type, when you go beyond 53bits you will start to experience loss of precision, which goes completely against the notion of an integer.
I wouldn’t call bad readability a loaded gun really.
Bad readability is a problem cause by the developer, not the language. Anyone can crank out unreadable symbol soup in any language, if that's what they want/can deliver.
Blaming the programming language for the programmer's incompetence is very telling, so telling there's even a saying: A bad workman always blames his tools.
can I write modern C++ code using the newer standards and still compile with libraries from older standards?
Short answer: yes.
Longer version: It depends on what compiler suite you're using. In the end the main requirements are that a) include headers are valid C++ in any of the standards you're targeting (i.e., don't expect to build a C++11 project which includes language features introduced in C++20) b) it generates symbols that can be resolved and linked on all binaries.
This should be done as a last resort, though. The problems you might experience won't be trivial to troubleshoot or common.
how do I even organize a C++ project?
One of the main advantages of C++ is that it does not enforce any project tree layout. It doesn't even require a specific file type or file extension. You are free to follow what works best for you.
If you want a guideline, that can also be provided. See for example this link:
https://github.com/vector-of-bool/pitchfork
how do I install dependencies?
C++ does not enforce any dependency resolution system. To keep things simple but debatable, you can give Conan a try.
Companies hate giving out cash. Even if it’s for software they critically need.
I think for most cases getting the cash is the easy part, and the hard part is getting all the paperwork in place to validate payments to random external entities. If that was easy, nothing would stop any low-level manager from making cash payments to random users with a GitHub account.
From the announcement:
Another frequently mentioned feature in this series is Git’s “partial clone” mechanism, which allows interacting with a repository containing a limited subset of its objects.
Has anyone tried partial clones yet? If you did, how was the experience?
There’s no bulky management of a virtual environment, no make files, no maven, etc. Just a human-readable cargo.toml for your packages
In your perspective, what's the difference between a cargo.toml and a requirements.txt, packages.json, pom.xml, etc? Is there any?
So, is anyone itching to buy one?
I’m not a very trusting person and work alone though so this might just be an emotional decision. But it is nice having a project be composed of code that does just what is needed and nothing else. It makes it easier to fix bugs and especially to maintain the code.
And that's one of the reasons microservices are a thing.
But sudo-rs seems to have a bit of a different usecase since it is intended as a drop in replacement for sudo, hence it must be able to handle the sudoers file aso.
Other than being yet another "standard tool X clone written in Rust" project, does it actually provide any tangible value?
If there was a single language, afterwards the same broken logic would be applied to frameworks and libraries, and we all know how many people bitch and whine over Java and it's extensive standard library.
Your comment feels half-baked at best. You start to talk about "best editors" but you proceed to present your two best examples and neither has anything remotely related to editors.
CLion is undoubtedly the absolute best IDE for C++ projects, and it's multiplatform on top of it. It's not even a competition, specially if you're using CMake. Using Git integration as your best and single example to refute this is extremely puzzling by how silly it is.