Tokyo?
1,889 karma · joined November 25, 2022
It's very different from a lot of the languages that people are typically using, but all the big features and syntax came from somewhere else. See:
>The type system and the borrowing mechanism are good examples. Unless you are a type system nerd a lot of that is just gobblygook to the average Python or Javascript user.
Well, yeah, but they generally don't like types at all. You won't have much knowledge to draw on if that's all you've ever done, unless you're learning another language in the same space with the same problems.
'I'm not as good as learning things at you'
Or many other locations, by many other authors, at many other times, or simultaneously.
Your hierarchy is backwards. Borrowing for algorithmic code is easy, it's for writing libraries that can be used by others where it's hard. Rust lets you - makes you - encode in in the API in a way C++ can't yet express.
> I just very rarely have problems with memory errors in C++ code bases with a little thought applied to lifetimes and use of smart pointers
If these are sparing you C++ bugs but causing you to struggle with the borrow checker, it's because you're writing code that depends on constraints that you can't force other contributors (or future you) to stick to. For example, objects are thread-unsafe by default. You can use expensive locks, or you can pray that nobody uses it wrong, but you can't design it so it can only be used correctly and efficiently.
Note the preamble, FAQs, and that all of the winning entries are now neural networks.
Currently, it's ceded to a country hostile to mine. Great.
If you say browser developers need money from the search giant to compete in browser development, you are saying that - right now - you can't compete in browser development without it.
That is a cartel.
We only have four major browsers because only four players can play on a fair playing field. There are people who have been paid millions to create and perpetuate this system. Web developers worrying about feature development without it is their KPI. None of this is a coincidence, none of this is a natural law.
If you are a company that wants to have control over the browser market and ensure that it doesn't get taken away, you should contrive to have the funding depend on you continuing to control it.
The current situation is not an accident.
I will concede the features are very useful for developers to push algorithmic slop and walled gardens onto us.
As a specific example, expanding constexpr means a codebase I recently worked on can move away from template metaprogramming magic to something that is more idiomatic. That means iterating on that code will be easier, faster, and less error-prone. I've already done static dispatch using constexpr and type traits that would have taken longer to do with templates.
Currently constexpr programming needs you to know the specifics of what is supported - ideally you'll be able to infer that from first principles of the invariants that are available at compile time. That leads to faster, more confident development.
It's a similar story for reflection: we were using custom scripts and soon won't have to. The changes usually come out of the problems people are already finding solutions for in the real world, rather than gilding a lily.
That's a problem for the party trying to sell operating system updates.
Even as a premise. Your domain is enough of a concern for Bigcorp to spend executive time on. Bigcorp wants to acquire your employer because and they think they can get more value out of it than the asking price.
Your own executives will ignore the threat that due diligence means to your business in the case a deal fails to be completed, because this is their promotion cycle. But you are a potentially redundant cog that is unlikely to be a more efficient part at Bigcorp. After all, you don’t already work for them.
Unfortunately, the PVC used will off-gas even when they're not being played[1], so this even applies to the 48%[2] of record buyers who never play them.
It's immaterial though. They could instead face increased cost in taxes, decreased investment elsewhere, or good-old eminent domain for infrastructure expansion. The downstream effects of an infinite number of backup lines to guarantee service following an infinite number of track trespassers are not good for passenger satisfaction.
I think the real reason is less sensational: trains that go full in one direction still have to go back in the other direction whether they're full or not.