I would imagine so depending on software / use case.
I run Windows Server 2022 to support IIS / SQL Server so it's not a perfect fit for me personally, but I suspect for many home servers or NAS setup it would work well.
Couldn't you just pass a reference to your value (i.e. `&T`)? If you absolutely _need_ ownership the function you call could return back the owned value or you could use one of the mechanisms for shared ownership like `Rc<T>`. In a GC'd functional language, you're effectively getting the latter (although usually a different form of GC instead of reference counting)
I think I could. But then I would need to put & in front of every argument in every procedure definition and also deal with working with references inside the procedure, with the syntax that brings along.
Correct. If you then want to subsequently re-reference or dereference that reference (this happens sometimes), you'll need to accordingly `&` or `*` it, but if you're just using it as is, the bare syntactical `name` (whatever it happens to be) already refers to a reference.
Fil-C is impressive and neat, but it does add a runtime to enforce memory safety which has a (in most cases acceptable) cost. That's a reasonable strategy, Java and many other langs took this approach. In research, languages like Dala are applying this approach to safe concurrency.
Rust attempts to enforce its guarantees statically which has the advantage of no runtime overhead but the disadvantage of no runtime knowledge.
> but in practice fails, because of pervasive use of `unsafe`.
Yes, in `unsafe` code typically dynamic checks or careful manual review is needed. However, most code is not `unsafe` and `unsafe` code is wrapped in safe APIs.
I'm aware C already has a runtime, this adds to it.
> Yes, in `unsafe` code typically dynamic checks or careful manual review is needed. However, most code is not `unsafe` and `unsafe` code is wrapped in safe APIs.
Those are the excuses I heard from C++ programmers for years.
Memory safety is about guarantees enforced by the compiler. `unsafe` isn't that.
The stuff Fil-C adds is on the same footing as `unsafe` code in Rust- its implementation isn't checked, but its surface area is designed so that (if the implementation is correct) the rest of the program can't break it.
Whether the amount and quality of this kind of code is comparable between the two approaches depends on the specific programs you're writing. Static checking, which can also be applied in more fine-grained ways to parts of the runtime (or its moral equivalent) is an interesting approach, depending on your goals.
> The stuff Fil-C adds is on the same footing as `unsafe` code in Rust- its implementation isn't checked, but its surface area is designed so that (if the implementation is correct) the rest of the program can't break it.
It’s not the same.
The Fil-C runtime is the same runtime in every client of Fil-C. It’s a single common trusted compute base and there’s no reason for it to grow.
On the other hand Rust programmers use unsafe all over the place, not just in some core libraries.
Yeah, that's what I meant by "depends on the specific programs you're writing." Confining unsafe Rust to core libraries is totally something people do.
There’s no reason to believe that one program is inherently representative. sudo-rs eschews dependencies and so is likely to be higher than most programs.
Furthermore, 170 uses in a 200 line program vs a one million line program are very different. I don’t know off hand how big sudo-rs is.
Even in embedded OS kernels, it’s often around 1%-5% of code. Many programs have no direct unsafe code at all.
I mean, again, yeah. I specifically compared the safe API/unsafe implementation aspect, not who writes the unsafe implementation.
To me the interesting thing about Rust's approach is precisely this ability to compose unrelated pieces of trusted code. The type system and dynamic semantics are set up so that things don't just devolve into a yolo-C-style free-for-all when you combine two internally-unsafe APIs: if they are safe independently, they are automatically safe together as well.
The set of internally-unsafe APIs you choose to compose is a separate question on top of that. Maybe Rust, or its ecosystem, or its users, are too lax about this, but I'm not really trying to have that argument. Like I mentioned in my initial comment, I find this interesting even if you just apply it within a single trusted runtime.
I just tried Zed and it is definitely really pleasant to use. I'd need at least a Java LSP to use it for real (and preferably general LSP support so I can code in my own programming languages with it) but I can see a lot of promise. If they ship a Linux release so I could use it on my desktop too they could win me over from Sublime Text/IntelliJ.
About 70% of the programming I'm doing right now is in my own language. But like, my full time work is programming language research so I accept that's an uncommon use-case.
There's a machine called the Meticulous which is launching a kickstarter soon which is attempting to somewhat do this. It's a lot simpler mechanically because it's just an automated lever machine (i.e. no pump).
The downside is no steam wand but tbh if I didn't already have a Decent DE1Pro I'd probably get a Meticulous or a Flair 58 and that new nanofoamer pro for milk.
Node.JS and Deno are both running with V8. fetch() isn't part of the JS standard library, it's a Web API. Deno just made (the good imo) design decision to support WebAPIs over something more custom despite the fact that it's not a runtime for web apps.
Server-side WASM is the future for FaaS imo, sandboxing built in and an effective object-capability approach to dependency safety is amazing.
I made one called MicroPad a few years ago (https://getmicropad.com) and just launched v4 a few weeks ago.
It's pretty full of features and each note is an infinite whiteboard/canvas where you can embed elements anywhere (for example I go horizontally for tangents)
