Unfortunately it seems to me we're going in the opposite direction. I remember reading something extolling the virtues of Web Assembly, and one of them was that it bypasses the MMU and is therefore faster... What is old is new again.
Well almost any language provides that (or rather the C underneath the languages provides it).
Sadly, no. Pretty good, but not nearly enough.
My assumption for Rust is
--crate-type=cdylib on build commandline or #![crate_type = "cdylib"] in configuration. Am I wrong?I think so, too.
If I understand correctly, LLVM generates intermediate code to use for final native code generation. So my assumption is to make LLVM have the frontend for Rust just like for C (clang) by LLVM project is the best thing to introduce for FreeBSD base.
It would possibly be a good solution. Though I do feel that it is leveraging a "gimmick" of LLVM (IL) which will make the future creation of compilers (from different vendors / technologies) difficult.
I don't think you are wrong, but ultimately this isn't really needed either (Dynamic linking is just a bonus). The .o files can be directly linked by any language that supports native code (provided that name mangling and calling convention have been cleaned up).
If the (future candidates of) compilers supports all languages that FreeBSD base is using at the moment and every objects it generates (from any of the supported languages) links together sanely, there would be no (or less, if its object format is different from LLVM's ELF and not 100% assured to be linked together) problem.
I thought cdylib is mandatory for it, reading Linkage part of The Rust Reference. staticlib doesn't seem to be good enough, especially for cases the Rust part is depending on (still not rewritten or impossible to be rewritten mutually-unsafe-as-of-hardware-spec drivers) C codes.
Yes, and LLVM is relatively young. It's unlikely, but not impossible, that some new compiler collection could arise to compete with GCC and LLVM.
?
Sure, all languages have rough edges, but a read that has a write as a side-effect? That doesn't just violate the POLA, that's world-class BS semantics.
It is the problem with the definition of what to do if a key does not exist. It makes sense to provide the default item for writes (as it will be overwritten) but not for reads. If the language would distinguish between l-value and r-value references, it could be solved. You might throw an exception then, or return a default. But that is not possible (to my knowledge), so we need to manually check if the key is present before reading it. Or only map classes where the default constructor traps to the debugger.
Yep, you put some effort up front, and it will pay off big time in the long run. ?
Like say, for example, return null? But that's not allowed with C++ references. It's a feature, not a bug. Languages without null struggle with expressing "don't know" which is important, it turns out.
Read the comments for some spicy internal Rust politics. That, more than anything, has confirmed my bias. I'll be skipping that language.
No it doesn't, there are many things wrong with his opinion; for example:
What the hell is an "optional" component? It goes against one of FreeBSD's key concepts of a deterministic "base" install. There is nothing in FreeBSD that allows that, not even the damage that PkgBase is going to do will handle this.
So his goal is to reach a large number of new components, then whine that FreeBSD is missing out on "all this great stuff" and then push to make them non-optional. This will happen in ~3 years and be premature, pulling in a load of crap. Instead, new components should be written in C, so then every one can benefit and no mess is made.
Don't forget that this is a Proof-of-Concept, investigating how to define the starting point (or stop starting). Just my guess.
The Rust community is a niche minority so don't have the man-power to truely undertake a thorough investigation. Instead they just want to generate lots of noise and reach maximum market penetration with what little resources they have available in the vague hope that they can trap others into their broken ecosystem.
No I don't think that seems right. FreeBSD's base often gets new additions. None of them are optional; they are either in base or in ports. Perhaps he means filesets you can choose during the installer?
Much larger ecosystem like python would have the same problem. Too large to manage by themselves. Too rapid growth easily makes such situations.
Not sure at this moment. But possibly, only if merged into base. Anyway, Shawn would be mentored by Warner (and maybe by Alan, too) for this Proof-of-Concept.
Agreed. Python and Rust are not core parts of production operating systems because of this.
Based on the mailing lists, I don't feel Alan is a good choice (if I recall, he only pushed for Rust because he didn't understand and was unwilling to learn correct C++ in the FUSE subsystem). Hopefully they don't wear Warner down and exhaust him with nonsense.
Dunno, the "nonsense" sounds pretty reasonable and technical to me:And that's coming on the heels of "Nontechnical nonsense" !
