Fadlangs in base.

It seems like every three seconds someone suggests rewriting something in Rust, or Zig, or some other language that released five minutes ago that no-one cares about besides "langbros". I mean, FBSD works fine as it is. If FreeBSD added every new language when it was released, it would be a bloated mess. Why don't people consider these two things:

1. Do we need it?
2. Will this have bad repercussions (buildworld, obsolescence, cruft)

I really think that FBSD is fine as it is and does not need any more languages in base, unless they UNDOUBTEDLY have a purpose.

As someone I met once said: "Sometimes it feels like people just make up new languages for the sake of making up languages"
 
I see nothing bad with making new languages. But there should be a real benefit when using it. C and descendants have some bad spots from their past, basically anything that says "undefined behavior" in a standard. C++ is simply too big to implement correct to the standard. But fixing that in a new language and porting everything (re-develop, as a simple rewrite will most likely not suffice) will cost. It may eleminate bugs, but surely introduce new ones. Writing new stuff in new languages is fine, but please use your head before replacing other things.
 
For example, imagine rewriting mv in Rust. That is an example (that I just made up on the spot) of what rewriting components in new languages for the sake of rewriting components in new languages.
Well, when it comes to Rust language, there's a LOT of stuff getting re-written in it. Hell, RedoxOS, an entire OS written in Rust is gaining steam (oh, and you can even install Rust language and dev stack on SteamDeck, I hear)
 
Well, when it comes to Rust language, there's a LOT of stuff getting re-written in it. Hell, RedoxOS, an entire OS written in Rust is gaining steam (oh, and you can even install Rust language and dev stack on SteamDeck, I hear)
Rust will peobably just be one of those things that goes obsolete in 5 minutes. It smells of a fad.
Do you have any links for such suggestions?
You suggested rewriting components in Rust. Look in your post history!
 
You suggested rewriting components in Rust. Look in your post history!

No, what I did is bring a discussion about such activity over from the mailing lists to this forum. Personally I have not made up my mind yet, hindered by the fact that I have other topics to learn first before I can tackle Rust (which I might decide against in the end).

I am sympathetic to claims that C is deficient as a language, though. But at the end of the day Lisp is the only language that allows you to write programs that are not just readable and writeable but also changeable. Replacing one Algol like language with another random one is not the breakthrough I am looking for.
 
No, what I did is bring a discussion about such activity over from the mailing lists to this forum. Personally I have not made up my mind yet, hindered by the fact that I have other topics to learn first before I can tackle Rust (which I might decide against in the end).

I am sympathetic to claims that C is deficient as a language, though. But at the end of the day Lisp is the only language that allows you to write programs that are not just readable and writeable but also changeable. Replacing one Algol like language with another random one is not the breakthrough I am looking for.
Sorry. I just misunderstood your post. I agree that it is not a breakthrough and I go one step further by wanting a no-new-languages-unless-you-can-explain-their-purpose-without-whatifs-and-buzzwords rule.
 
From Lisp's perspective C is the newcomer :)
I know, but I mean purpose-wise, what is Rust good for in a system that already is written in C. C came first, it is good at it's job, and in already existing projects there is no need to complicate things with more languages that don't serve a new purpose. Lua serves a purpose. Rust overlaps with C.
 
Possibly we need Rust for LinuxKPI in the future.
If the target is really Nova driver only for now, we wouldn't need to be too worried about, but kinda "Rust bindings" in LinuxKPI could be wanted, if nvidia stops providing current form of drivers for FreeBSD (I think unlikely for now, though), or the target extends to more GPUs and/or WiFis.

But I think Rust can still be external tool chain at least FreeBSD makes LinuxKPI to be independent distribution from kernel.txz (in current form here) into kernel.txz and linuxkpi.txz.

Don't forget that these are still "possibilities in the future" and not in hurry.
 
A small distinction between Zig and Rust is that Zig is also a C compiler.

You can create an object file which contains both regular battle tested C code + Zig code side by side, without any FFI shenanigans.

I wouldn’t recommend including Zig in base yet though… it’s an amazing and highly ambitious compiler toolchain for programmers who think in C, but it’s mutating too quickly at the moment.

Once it’s stable though .. is worth a serious look at.
 
Rust doesn't belong in the base system of FreeBSD at all. While it's in the extended C family, it's too different than C. That will cause bloat, and won't be a standard system anymore. Rust is too derivative from the written in C language in base.

For those who want Rust in base, please use Redox: it's close to being a standard general purpose OS. It has USB input and wired Ethernet/Internet ability now, unlike a decade ago: today its capabilities are similar to what NetBSD had a decade ago. Use your traditional C or C++ based program on top of Redox. Alternatively, if you still insist that Rust goes into the base of your favorite BSD, fork it. Redox is the better option for Rust in base. Using Rust from ports on your favorite BSD is fine: no criticism here.

In base, as for modern languages that closely resemble C and are safer, as long as it can fit in better than C++ does. Also, possibly, if its compiler can also natively compile C. That's not redundancy. So, Zig or C3 may be ok, but it may be too early to tell if something better that learns lessons from them come along. A task like that would have to wait until all of GCC tools in base are replaced with LLVM tools, which isn't far.
 
It seems like every three seconds someone suggests rewriting something in Rust, or Zig, or some other language that released five minutes ago
I understand and agree with this point. While Rust had a growing following, you never heard too much about it until the US government recommended its usage for security purposes. Then, all of a sudden, there were articles everywhere stating everything had to be written or re-written in Rust immediately. (Or so it seemed.)

It's too quick to determine that Rust is the answer and there are Rust experts in all of us.
 
I understand and agree with this point. While Rust had a growing following, you never heard too much about it until the US government recommended its usage for security purposes. Then, all of a sudden, there were articles everywhere stating everything had to be written or re-written in Rust immediately. (Or so it seemed.)

My memory is that civilian enthusiasm is older than the government memos on memory-safe languages.
 
Anyway, if I understand correctly, FreeBSD vendor imports LLVM per-directory and build only really-required-for-base parts of it on base (thus, the same version of LLVM exists in ports, too).

So the most straightforward thing to add new languages into base would be to choose from any of languages (other than already picked clang and clang++) that LLVM project officially has in their releases. If there's none that is wanted there, simply, it's tooooo early to consider, unless FreeBSD switches (again) to different toolchain project.

If Rust is incorporated, Rust can be the candidate. If Zig (repeat). If (some others) (repeat). But there seems to be flang alone for now. Just my opinion to minimize maintainance workloads.
 
Back
Top