Are you referring to the zipapp library? I had no idea this even existed until now but that seems pretty clever. Huh. Why can't it also dynamically unzip a shared object library?
I have found it difficult to track cash spending. I picked up using GNUCash this year, and that helped a bit. I at least can capture most cash spending to see if I'm within budget in different categories. But every few week's I still need to make a 'correction' transaction for ~$10, which is annoying.
I disagree about replacement programmers--at the moment, practically every graduating electrical engineer and computer engineer will have a working knowledge of C. Embedded C has lost some ground to C++, but primarily in ARM and x86 architectures, since for more memory constrained AVR/PIC/etc. microcontrollers, you absolutely avoid template inheritance because vtables are untenable, there often isn't an available STL for the chip toolchain anyways, templates balloon the program space, and you are still constrained to using just stack allocation. That right there pretty much means there will always be a space where C is more pragmatic.
I see this pattern a lot on HN. Many aren't aware that there are fields alive and well that require the use of unsafe, deterministic C that can compile to programs on the order of kb.
I think their point was that even if PyCharm uses more, the intelli-sense and IDE features are more advanced than in VSCode, where all your RAM is consumed to run Electron.
This isn't true at all. Most engineers never get a PE. It's not worth it unless you are working on public works projects or civil engineering things. It's very reductive to say that work isn't engineering unless you have a PE.
AWS Glacier provides a pretty cheap[0] backend for such a service. You could store 1TB for 1000GB * $0.004/(GB * mo) = $4.00/mo, which is dirt cheap, all things considered. Retrieval is about 10x that, per GB, but generally if you are storing backups, you aren't concerned about retrieving it too often, so that cost is acceptable. Compare this to the S3 bucket costs for the same storage size($10/mo for infrequent access, and $24/mo for standard), or to google drive 1TB tier ($10/mo, but no API as far as I know).
A heads-up display to tell people in front or behind you on the road to turn off their brights. People either don't know or don't care that they are blinding others. I'm probably never going to do it because it would also attract negative attention.
I suppose something close might be OCAML or Haskell, since they have similar type safety to Rust (whose syntax is loosely based on OCAML from what I understand) but have some nice features that Python and Nim use like list comprehensions and generators, lazy evaluating, etc. But also with Rust macros you can sort of make your own sub-DSL's which add some of those features.
There is a cost to using FOSS, though it's much less sinister than that of using Android or Google Apps. You are giving up convenience in exchange for software that respects you. In terms of the user becoming the product, I suppose that would be harder to argue. Maybe one could say the users become co-opted to promoting the cause/agenda of FOSS.
There's a difference between the product made by a manufacturer, and the OS distributed by Google (their "service"). If we are talking about Google's incentives, than we have to look at their relationship with Android as a product. They are giving away Android to manufacturers for free. It's _Google_ that has the incentive to sell the users' data. That we purchase devices preloaded with Android doesn't pass that sale off to Google (like it would to Microsoft with a Windows computer), so it doesn't take away their incentive. So for the purposes of determining at what social cost you use Android, it might as well be gratis.
It might be true that libre software can break that rule. AOSP isn't libre, and the libre forks are so hobbled by limited access to Apps and the Play Store that there IS a cost to using them: the cost of losing very useful features that are only available in AOSP.
Android may have always been available at no cost, but it was never free. Always assume if you are given a service gratis, that _you_ are the product being sold. This doesn't just apply to Android, but to gmail, Drive, Docs, etc.
Well I suppose backwards compat might have been the wrong phrase here. I'm thinking more that it's a language whose v1.0 release was only 3 years ago before which it was "difficult to maintain projects written in Rust, since the language and standard library were constantly changing" [0]. That's not to say that it isn't a stable language now (and I actually quite like it) but with only 3 years of stability to show, "nuclear reactors" and "submarines" are strange things to list as applications for the language.
There are some pretty good lynda.com tutorials that I've watched. I've found an advantage to those is that I also learned a few things about statistics too, which is useful outside Excel.
I don't think any embedded systems engineers are programming in Rust for nuclear reactors or subs, and I don't think they are considering it either. No amount of safety constraints in Rust make up for the fact that the Rust team is sometimes willing to forgo backwards compatibility to keep the language clean. Not to mention those are usually legacy codebases from before Rust even existed, and no one is convincing the DoD or the DoE to "rewrite in Rust".
Compiling the hello world with -betterC yields a binary of size 8.2K. Seems small but when your microcontroller has 8K of program space that's just untenable. Of course those small micros are getting rarer nowadays when a large AVR and ARM micros are cheap, but there is still an entire range of minimal microcontrollers that are extremely limited in resources.
If you got the bitcoin originally through mining, then it never has to be converted from another currency. Bitcoin is anonymous, but only if you mine instead of purchasing on an exchange.
A while back I was interested in learning more about programming compilers, so I checked this project out. I actually added array map, filter, reduce, and sort methods to the language, which was fun and a learning process.
I think you've got the wrong idea on "self-hosted". That just means the compiler is written in the language itself. Rustc is written in rust, so it is self-hosted (even if it has an LLVM backend). And likewise, all three D implementations are written in D, despite having either baked-in code generation, a gcc backend, or an llvm backend. You can check the repos on github: all three of DMD, LDC, and GDC are written in D-lang, so they are self-hosted.
Same. I generally try Docker first. With multi-stage builds, you can reduce container build times by a lot (after your first build), as opposed to reprovisioning an entire vm every time you need to nuke your dev environment and start from a fresh image.
Quick note: my favorite way to extract columns is:
`cut -d' ' -f1, 5`. You won't be getting a running total but for selecting columns I find it useful.
Not really. An interpreter doesn't convert the language syntax tree into machine code, instead it just performs the operations. It sounds like Swift's REPL actually converts the lines into opcodes and runs those.
I second Gnucash: I've been using it since January, including the budgeting features. There were some weird settings involving which account categories to count as negative/positive transactions to get the budgeting to work.
There's not much atmosphere on Mars (approx. 0.6% of Earth's) to get in the way of the sun, so there's not much advantage to beaming down solar energy. You might as well just have solar panels on the rovers themselves, which unsurprisingly is exactly what NASA did.