I am happy for most software to move from C into almost anything else. Something unlikely to have memory exploits, or with standardized tooling for dependency management and compilation.
- There are no dynamic binaries. Everything it's static. But binaries and the userland are tiny and usable.
- Cross compile it's dumb easy. [0-9]c, one number per arch.
- Every OS comes with compilers, libraries and sources for every arch.
- Security it's handled by separated modules, a password/login daemon/server and namespaces. Totally different. That will be the future in 10 years, and not Rust.
The kind of "security" that you get by using a safer language like Rust (instead of C), can't be achieved by using anything that can be described as a "module" in an unsafe language.
Nim and Crystal feel like they are in exactly the same space? GC, fast, single executable compilation without runtime (I would also throw Go into this list).
Nim's new ARC gc, which will be default soon-ish in 2.0, does not have a "runtime" as commonly understood.
It is fully deterministic, so it simply injects alloc/free calls in the generated code at compile time. It even has an option that can show you where the calls are injected.
Everything has a runtime nowadays. Even C, even if it isn't all that large (including for example the memory structures necessary to keep malloc and free working).
I think that’s too expansive of a definition of “runtime.” The context required by C and Rust programs is generally internal, meaning that interacting with the dynamic allocator doesn’t require the programmer to be aware of the implementation’s invariants. This is in contrast to a managed language like Java, where using a managed object from C via JNI requires coordination with the runtime (which in turn preserves the invariants).
But you have to know that as well for C - there are for example several Linux system calls you really should not call manually because that would fuck up the internal state in LibC. Yes, the runtime is really small, comparatively speaking, but it is still a runtime.
Which system calls are you thinking of? The only ones that I can think of would be brk(2) and sbrk(2), but any recent libc should be resilient to calls to those.
That being said, I'll grant that the distinction between "tiny runtime" and "no runtime" isn't useful and that C can be said to have a runtime insofar as most systems provide a `crt0` or equivalent.
Pony does stricter sharing semantics than Rust (multicore) with actors and allegedly one of the fastest GCs ever developed. Its community is even smaller than Crystal's. Pony was developed essentially as a PoC to demonstrate the GC.
You can ditch Nims GC and runtime and bring your own if you want. Of course you'd lose access to most of the stdlib but this is why Nim can be used and is popular for embedded / bare metal.
Tmk Crystal still lacks Windows support as well and probably other os's / archs's compared to Nim
It is a resource strapped project. I doubt they have the bandwidth to throw in additional languages. Plus, Lua is perfect for this niche: small, easily embeddable, fast, and simple enough to pick up in an hour. There are even a variety of languages which can transpile down to Lua.
So many great features in this release. Love the .args and subprocess support. I have been toying with redbean on and off, and I have been wanting to see if I could kludge together a poor man's long running job (scheduled) runner (something like Celery).
Try hitting ctrl+shift+r in your browser. Sometimes browsers don't respect the cache headers which say 1 hour max and I haven't figured out why. This new release includes functions like setitimer() to help the primitives be there for anyone wanting to use Lua to build something like Celery.
HTTP has some strange rules about using stale caches so usually you want to add must-revalidate to your cache-control header. That ensures that the browser must revalidate once the cache goes stale.
Personally I've opted for "stale only" caching, so everything is served with Cache-Control: max-age=0,must-revalidate and a Last-Modified header and the browser will always make corresponding If-Modified-Since requests. This means significantly more requests per page, even if the responses are mostly 304 Not Modified, but getting to avoid all forms of cache busting makes developing a lot nicer.
It's definitely cheap to execute, the problem lies in the network overhead. With sub-resources (css, js, images) you can go from 1 request per page to 10 or 100 which is still negligible for fast connections (10 mbps+, http2) and servers with low request overhead - but the worst case scenario is high latency http1 connections where each request really matters.
However if you are serving clients with highly restricted bandwidth you're probably going to want extremely cacheable resources (public, immutable) and perhaps even a completely different site architecture.
Maybe that depends on the OS? Firefox on Linux does a normal refresh for me when doing CTRL+R but a hard refresh (without any cache) when I do CTRL+SHIFT+R.
This is standard at least across Chrome and Firefox on Linux and MacOS— (ctrl|cmd)+R does a normal page refresh, (ctrl|cmd)+shift+R does a "hard refresh" where it reloads every resource on the page without caching.
Also, in Chrome, if and only if you have the dev tools open, right clicking the reload button will give you a menu with the options "Normal Reload", "Hard Reload", and "Empty Cache and Hard Reload". The third option will ensure that requests initiated by JS or that otherwise weren't part of the page load also won't be served from cache.
Ok MacOs (Chrome), I'll usually open View and hold down shift. 'Reload This Page' changes to 'Force Reload This Page' and I like the visual feedback that it's actually doing what I intend.
But it hasn't always been easy to find documentation about it, thanks to a combination I think of "simplifying" everything and Google not delivering correct results since somewhere around 2010.
Thankfully now there is Kagi that actually makes a bug report if you provide them with an example that doesn't work.
I think I've been using that shortcut for as long as I can remember. In web development circles it's certainly common knowledge, as you always end up in a situation or two where you need to reload without cache, but you don't want to clear the entire browser's cache.
I am still waiting for a seL4 based router, firewall, DNS server, file server, etc. Even better if we could get it into critical infrastructure (water treatment, electricity, etc). Something that is exposed to the insanity of the internet, but may not necessarily have high performance requirements. We have super computers in our pockets, we can take some performance hit if it eliminates large security concerns.
Specifically targeting compounds is an active area of research. Example: all oncotherapies are essentially just poison. The trick is to deliver the toxin to the 0.001% of cells in the body that are cancerous.
It is amusing you should say ways that avoid reaching the brain. The blood-brain barrier impedes a large number of therapeutics from entering the brain. It is incredibly difficult to engineer the constraints of something that: is potent enough to have an effect, can survive in the blood, cross into the brain, targets the cells of interest, has a meaningful half-life, does not decompose into something toxic, etc.
Linux barely works as it is. I no longer have any interest in debugging my desktop technical problems. Which means my best option is to use the most popular environment so when I do encounter an issue, there is likely to be someone who has already encountered the same issue and reported a solution.
Until Ubuntu switches to KDE, I am stuck in the Gnome-lets-remove-desktop-icons-because world.
I wouldn't call it official, it's a side project run by the community. 'Official' would be something created and supported by Canonical. It's a moot point though since you get the exact same thing by installing Ubuntu without a gui and then doing 'apt install plasma-desktop'.
