Yes, by deciding on when, where and how you pass it. You know when it is created and destroyed because you wrote the code that either does that directly, or follows the convention (destroy when out of scope, or use of arc - it is programmer's decision).
> Much of the business world, especially those things that must be done properly, still rely on having physical records and manual process.
Can you name one business that is using physical records where this is not mandated by law? All accounting around me, including banks, is done digitally. The only one I can think of are businesses run by people born before computers where a thing (some still exist). Note that governments and regulated industries can change very slowly, but that's almost always result of not needing to compete, not an intentional choice.
> Why would you need to treat a web browser like a virtual machine?
There are many reasons. Performance, ability to bring concepts from other domains, ability to do things browser has no api for, ability to provide controlled experience and behaviour that goes beyond common browser usage.
> surely we can't keep adding to css and the dom api's for 20 more years?
We can. Just every now and then some new way of working becomes popular, and at some point combining them with older ones will become undefined or unsupported.
> why did some of them find (and take) room in coin hoards?
People who had access to gold used some of it to create jewellery.
> Why have they been found all over Gallia, Germania, and Britannia, but not Italia, Hispania, or the Oriens?
Certain types of jewellery can be found in certain regions. This can be attributed to specific trading network or local preferences. I don't know if that could be proven, but makes sense to me.
Knitting - specifically knitting jewellery - explains that. Different holes allow you to create chains of different sizes, which in case of jewellery, also does not need to be standardised (lack of any standard or markings makes theories of some measurement device unlikely). That also explains regional popularity and proximity to gold (several of those items were found close to places were gold coins were produced or stored).
> it's obvious that they are magic methods and not intended to be part of the public API
Is there an alternative API? No. This is public API regardless of anyone's intentions. Though "it's weird" is really not a very strong argument against it.
Public API refers to the user of the class, not the implementer. You never call __init__ directly. __new__ allows modifying object creation itself for the implementer, but the user of the class will never call it.
There are private and public methods. Private methods are only supposed to be called within other methods, as in privately. Public methods are the ones that are normally called through the code, repl, by the user or whatever. You are not supposed to write `myclass.__add__(x)` anywhere except where you define the class itself and its methods.
Internal is more convention as the language doesn't really do anything with it, but it does with munged, and magic methods are specifically for things implemented in the language.
Internal and munged don't exactly map to private and protected, but are kinda similar ish.
Oh right. I am not really into python, had read some doc about naming conventions some poitns.
In any case I actually like how one can use underscores to point on how exposed some method is supposed to be. Makes it simpler to actually know what to skip and what not.
There are several alternative API's. @dataclass is one, Pydantic offers another, there's also attrs, plus less general things like namedtuple.
Admittedly it's obnoxious when you've got habits for one and you're on a team that uses another--totally flies in the face of the zen re: "there should be only one obvious way to do things".
...but that was always a rather ambitious goal anyway. I'm ok navigating the forest of alternative API's if it means not being locked into something that I can only change by choosing an entirely different language. I'm happy that it's very easy to tell when somebody is mucking about with python internals vs when they're mucking about with some library or other.
Look at prql for example of better alternative. I'd love to have something that works with modern programming languages without translation. Also is extensible. The list of complaints one can have SQL is long, and many modern databases leave it behind.
> but neither Go or C# have issues with dependency hell like Rust or even more JavaScript, because they have exceptional std libs
They also have a lot narrower scope of use, which means it is easier to create stdlib usable for most people. You can't do it with more generic language.
I would say C# gets used almost everything at Microsoft between GUIs, backends, DirectX tooling (new PIX UI, Managed DirectX and XNA back in Creative Arcade days), Azure,..., alongside C++, and even if Microsoft <3 Rust, in much bigger numbers.
Indeed, it has no bearing on binary size at all, because none of it will be included. If you are coming from the perspective where the standard library is entirely unusable to begin with, then improving the standard library is irrelevant at best. It also likely means that at least some time and effort will be taken away from improving the things that you can use to be spent on improving a bunch of things that you can't use.
I feel like this is an organizational problem much more than a technical one, though. Rust can be different things to different people, without necessarily forcing one group to compromise overmuch. But some tension is probably inevitable.
> Indeed, it has no bearing on binary size at all, because none of it will be included.
That depends on the language. In an interpreted language (including JIT), or a language that depends on a dynamically linked runtime (ex c and c++), it isn't directly included in your app because it is part of the runtime. But you need the runtime installed, and if your app is the only thing that uses that runtime, then the runtime size is effectively adds to your installation size.
In languages that statically link the standard library, like go and rust, it absolutely does impact binary size, although the compiler might use some methods to try to avoid including parts of the standard library that aren't used.
Embedded Rust usually means no_std Rust, in which case no, neither the standard library nor any runtime to support it get included in the resulting binary. This isn't getting externalized either; no_std code simply cannot use any of the features that std provides. It is roughly equivalent to freestanding C.
What you say is true enough for external-runtime languages and Go, though TinyGo is available for resource-constrained environments.
Well, Rust's standard library has three components, named core, alloc and std
The no_std Rust only has core but this is indeed a library of code, and freestanding C does not provide such a thing = freestanding C stdlib provides no functions, just type definitions and other stuff which evaporates when compiled.
Two concrete examples to be going along with: Suppose we have a mutable foo, it's maybe foo: [i32; 40]; (forty 32-bit signed integers) or in C maybe they're int foo[40];.
In freestanding C that's fine, but we're not provided with any library code to do anything with foo, we can use the core language features to write it outselves, but nothing is provided.
Rust will happily foo.sort_unstable(); this is a fast custom in-place sort, roughly a modern form of introspective sort written for Rust by its creators and because it's in core, that code just goes into your resulting embedded firmware or whatever.
Now, suppose we want to perform a filter-map operation over that array. In C once again you're left to figure out how to write that in C, in Rust foo impl IntoIterator so you can use all the nice iterator features, the algorithms just get baked into your firmware during compilation.
