IMHO, if the bail is too high for the accused to be able to possibly pay, it is excessive. The wealth (or lack thereof) of the accused should be a consideration in setting the bail.
I'm fairly liberal, but I don't think we should bail out a hypothetical murderer that happens to be homeless for $0, simply because that's what they can afford.
I do feel like we need a low-cost solution to monitored release. Something like an ankle monitor that isn't ridiculously overpriced, or just an app on the defendant's phone for misdemeanors. Maybe someday you can have the defendant swallow an AirTag that adheres itself to the stomach for a few months, and perhaps monitors pre-trial conditions such as discontinuing alcohol or drug use.
Totally agree. By the same logic, we shouldn't release a billionaire murderer just because they can afford it. Being rich doesn't always correlate with risk.
> 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.
> At each level a caller might need 5% of the functionality of any given dependency.
I think that is much more of a problem in ecosystems where it is harder to add dependencies.
When it is difficult to add dependencies, you end up with large libraries that do a lot of stuff you don't need, so you only need to add a couple of dependencies. On the other hand, if dependency management is easy, you end up with a lot of smaller packages that just do one thing.
I don't know of cases where the US federal government uses them, but it isn't that uncommon for state or local governments to have them. Although the laws around them differ between jurisdictions.
reply