# what we can do with rust is beyond what we can imagine



## Deleted member 70435 (Apr 10, 2022)

Hello when I mentioned that rust can give us a good programming base I said in the way we can implement things, I see the FreeBSD kernel code for example is something very simple and something that can, if written easily.

maybe you guys don't like a new idea, but i had a good idea and i need your opinion.

https://crates.io


----------



## sidetone (Apr 10, 2022)

Crates seems to be in competition with ports. It's fine, but on FreeBSD, it seems redundant. I've used programs from ports that were in Rust, and they ran faster than similar programs in C, which I didn't think was possible. For instance, shells/ion is fast, but takes a long to compile, because it has a lot of ports and Cargo dependencies

There's Redox OS (MIT licensed), which is written in Rust. A few years ago, it didn't have network functionality, but I don't know if that's changed. Tock (Apache and MIT licensed) is for secure embedded applications. Thesus (MIT licensed) was developed at Rice and Yale for research applications, than basic typically expected functions. Redox, Thesus and Tock are interesting and worth looking at. They seem good for your stated purposes. Redox is the most complete in terms of a desktop. I would like to think of some of these as being like a Rust version of Minix's purpose of being educational or for their design.

There are a few other operating systems written in Rust, https://github.com/flosse/rust-os-comparison, but they aren't far along. On first glance, these seem primitive or limited in purpose and function.

As for FreeBSD's base, it needs to stay as C. A Kernel fork would be cool, but it should remain as a separate project. Or some programs ported to Redox OS in Rust. Maybe a port system in Rust, and perhaps also in Cargo, that works independently of FreeBSD's ports, and works on top of FreeBSD.

I did look at Rust with fascination before. It belongs with a Rust framework, however it's used as: a port system written in Rust on top of an OS written in C, or in an OS written in Rust. I never learned Rust; I wanted to before, and lost interest in learning it. I want to still learn C, but it seems like a lot for me to start on.


----------



## mer (Apr 10, 2022)

Phishfry said:


> 95% of the people here despise anything new.


95% of the people here despise being told what they despise 

My opinions, me personally, I don't really care about what others think about a language.  I like to investigate pretty much everything because almost everything has a good idea or two, it's the realization.

Java, Rust, Go, Node.js, < insert your favorite here >

A lot of these claim all kinds of benefits, but often the reality is short of the theory.
Java, "run anywhere" but there is an awful lot that depends on the interpreter.
Rust, Go:  at a language level, theory level, yes there are some advantages.   But again, both depend highly on the run time libraries and environments to prove/benefit.  If you have a compiler that takes the language down to machine code, then you are back to "how good is the compiler and the libraries". 
It's trivial to create an http server listening on a port in Node.js, takes a bit more effort in C++.  Node depends a lot more on supporting libraries/packages than C++ but you need to decide.

Anyway, new languages, new design paradigms are worth at least looking at/investigating, but like a lot of things in the Internet world, the hype may be more than the reality.

Again, my opinions, based on my experience, feel free to tell me I'm full of crap, agree, disagree, "it's all good".

ETA:
Dimitri Chuikov I tried going to your link but got server not found.  Is there a typo?


----------



## sidetone (Apr 10, 2022)

https://crates.io/


----------



## mer (Apr 10, 2022)

sidetone Thanks.  Quick glance it looks to be "rust answer to node npm".


----------



## Deleted member 70435 (Apr 11, 2022)

sidetone said:


> Crates seems to be in competition with ports. It's fine, but on FreeBSD, it seems redundant. I've used programs from ports that were in Rust, and they ran faster than similar programs in C, which I didn't think was possible. For instance, shells/ion is fast, but takes a long to compile, because it has a lot of ports and Cargo dependencies
> 
> There's Redox OS (MIT licensed), which is written in Rust. A few years ago, it didn't have network functionality, but I don't know if that's changed. Tock (Apache and MIT licensed) is for secure embedded applications. Thesus (MIT licensed) was developed at Rice and Yale for research applications, than basic typically expected functions. Redox, Thesus and Tock are interesting and worth looking at. They seem good for your stated purposes. Redox is the most complete in terms of a desktop. I would like to think of some of these as being like a Rust version of Minix's purpose of being educational or for their design.


thank you very much my friend, did not know this project, I am a comrade and veteran on FreeBSD, I would like to have many projects in rust on FreeBSD I still have some difficulty is not as clear as we think.

I can be honest that I loved this project, I will even see how all the code was working the scope of the project, this will give me a great idea, we already have a base.


----------



## Deleted member 70435 (Apr 11, 2022)

some technical news in rust








						Announcing Rust 1.60.0 | Rust Blog
					

Empowering everyone to build reliable and efficient software.




					blog.rust-lang.org


----------



## ralphbsz (Apr 11, 2022)

A: If you want to program in Rust, go ahead. I've heard good things about the language; alas, I haven't had time to use it myself.

B: If you want to convince others to program in Rust, the best thing you can do is to demonstrate writing good software in it.

C: Whether Rust will be allowed in the FreeBSD kernel is a difficult question. The FreeBSD kernel is much more tightly organized and quality-controlled than Linux. If you want this to happen, you need to have a discussion with the FreeBSD kernel developers on the mailing list. It would probably help to demonstrate that you have a lot of experience in kernel programming. Maybe you could take a big kernel programming problem, and implement it in Rust as a demonstration, and offer the implementation to the developers as an example?

D: Crates.io has nothing to do with the kernel. It is a pure userspace system. And as others have said above, it solves a problem for which FreeBSD already a good solution. At this point, I don't know whether you understand the distinction between kernel and user programming.

E: Coming here and advocating for something without good technical arguments and without demonstrated technical (inside) knowledge is unlikely to help; on the contrary, it is likely to hurt.


----------



## kpedersen (Apr 11, 2022)

Dimitri Chuikov said:


> maybe you guys don't like a *new* idea, but i had a *good* idea and i need your opinion.


"new" has zero bearing on whether something is liked it or not. It also has zero bearing on whether it is good or not. I am going to assume English not being your primary language is where this confusion might have occurred.

crates.io is certainly not a new idea. You can draw almost exact parallels between CPAN, PIP, NPM, RubyGems. Can you really say that these have been successful when C and C++ (which lack any kind of language based package manager) still dominates the industry?

Language based package managers are in my opinion a naive attempt to solve the problem of managing many inevitable language bindings. A weakness of any non-C based language. Strap a C compiler into the Rust language and you will pretty much see crates.io fade away.

Rust as a language has some very important technical merits (and some can't quite be implemented into C++ unfortunately) but its ecosystem is extremely underwhelming.


----------



## Zare (Apr 11, 2022)

Language is nothing without the ecosystem. The number of C/C++ libs you can build out of the ports tree is staggering let alone everything on the Internet in source format.

Also for clean systems programming. Only if you're a Rust zealot and you wish to expand the reach of your favourite technology. Which is fine. For the rest of us, available code remains in C and embedded/restricted C++ on occassion. I have a billion lines of systems code in C at my disposal on the Internet, where is the Rust stuff?


----------



## jbo (Apr 11, 2022)

mer said:


> It's trivial to create an http server listening on a port in Node.js, takes a bit more effort in C++.


WARNING: self-advertisement incoming  --->  https://github.com/tectu/malloy
While I fully agree with your statement, the nice thing with modern C++ is that while the implementation is indeed more challenging, you can make it just as easy to use as python/JS/Go/Rust based solutions:

Here's your multi-threaded HTTP(S) & WS(S) server application:

```
int main()
{
    // Create malloy controller config
    malloy::server::routing_context::config cfg;
    cfg.interface   = "127.0.0.1";
    cfg.port        = 8080;
    cfg.doc_root    = "/path/to/http/docs"
    cfg.num_threads = 5;
    cfg.logger      = std::make_shared<spdlog::logger>();

    // Create malloy controller
    malloy::server::routing_context c{cfg};

    // Configure router
    auto& router = c.router();
    {
        using namespace malloy::http;

        // A simple GET route handler
        router.add(method::get, "/", [](const auto& req) {
            response res{status::ok};
            res.body() = "<html><body><h1>Hello World!</h1><p>some content...</p></body></html>";
            return res;
        });

        // Add a route to an existing file
        router.add(method::get, "/file", [](const auto& req) {
            return generator::file(examples_doc_root, "index.html");
        });

        // Add some redirections
        router.add_redirect(status::permanent_redirect, "/redirect1", "/");
        router.add_redirect(status::temporary_redirect, "/redirect2", "/");

        // Serve files from a filesystem directory
        router.add_file_serving("/files", examples_doc_root);

        // Add a websocket echo endpoint
        router.add_websocket("/echo", [](const auto& req, auto writer) {
            std::make_shared<malloy::examples::ws::server_echo>(writer)->run(req);
        });
    }

    // Start the server
    start(std::move(c)).run();

    return EXIT_SUCCESS;
}
```

It can of course do a lot more.


----------



## Profighost (Apr 11, 2022)

Having ideas, bringing them up and discussing them _is always a good thing._

But you always should be aware of having ideas and brainstorming is one thing.
Realization of ideas is something completely different.
That may be quickly overseen while brainstorming.
And what (software) developers may also quickly oversee when they are focused too much on their work of improvement, progress and realizing ideas is the whole purpose what it's all about: The User.
Without him all software would be no more than some kind of mental exercise, very interesting but in the end completely pointless at all.

This has to be be distinguished properly.

And that's why old farts like me (50   [There are people participating here over 70.]) are often misunderstood as boring poopers, because experience told us to stay on guard when ideas are brought up and we hold the horses.
This is not because of we don't like change or worried about ideas just because we are by principle against anything new just because only it's new (even if not seldom new ideas turn out being old ones brought up again every now and then.) That's silly narrow crap.
No, it's just because life and job experience simply teached us one thing or the other. 

One of those things is that not every new idea has to be necassarily good.
Also not every good idea is worth the effort of it's realization - _if_ it's even possible to realize. One has to check the available resources, too. Or you may end up in having unfulfillable demands, only.

Besides all that, ideas and realizations are something quite different.

And way more important is the human factor:
Everybody is fired up by new ideas quickly, especially if the idea is good. In particular progressive people who want things to be improved become quickly euphoric about good ideas.
Euphoria is like fire, much power for things to be done, but also danger. Euphoria may allure people to destroy mindlessly existing things. Because they are decided to be old and obsolete and will soon be replaced by better things. "How soon?" "Very soon!" - yeah, right, sure.
Besides that someone else may still have good uses for the so called "obsolote, old" things, one risk to end up in having nothing. Because of if the new things are not be realized for whatever reason or they are not proven to be at least an equal replacement you'll risk to end up having only destroyed what you already had.
First create new, additonally to hwat already exists. Than let the people decide if they want to change. Otherwise it's getting hard to receive acceptation, doesn't matter if the replacement is better.
That means two things:
1. You may risk doing all the work for nothing because you cannot be sure, your new creation is accepted. Forcing people only lowers acceptation.
2. It means _additional_ work, because drawing energy from existing work for putting it into the new creation may risk the loss of the existing things. That's bad, if the new creation did not became the new standard yet or even does not exists.

That's not to worry about as long as anything stays in brainstorming, and people are aware of seeing the difference between brainstorming and realization. And most of all _no decisions_ are rushed.
The next catch is when realization itself starts.
The casual, free spiriting of brainstroming ends and an actual project starts: Careful planning, evaluations, assements, ...and above all tideous, weary workloads that needed to be actually worked off, reviewed, controlled,...and it needed to be brought to an end that is at least slightly better than the already existing things or all effort would have been wasted completely.

And that's what life experience also teaches:
Most people applaud loudly to new ideas of improvement. But when the real work actually starts for realization most participators of the brainstorming are fucked off quicker before you even realize you are left alone in the open desert.
And take my advice: You'll better came with your own car, because of course all the cars are gone with them and they didn't even left you a bottle of water! 

You may start to work on your own. And if you made significant progress there are two kinds of people trying to join you:
Real friends who actual help you - the fewest. And many free-riders, who wants to sponge on your effort only, or even take your project over completely.
And you need to distinguish one kind of the other, which also is not always simple.

When I look at the FreeBSD project - its history, looking at the one or another presentation or document you may find on the internet such as for conventions, about what shall be done, what could be done and what needs to be done,...also looking at the list of names of all the people are currently and formerly involved and also being subscribed within one mailing list or the other, just to be curious about what's going on,...  - to me it seems the lack of ideas is the least problem of the FreeBSD project.
To me it seems most of the effort is used to organize all the work that already is needed just to have the poject stay sufficiently on its high level and keep it up and running.

With every project you need a certain percentage of work to be done just to keep it alive. This is called maintenance and it already consists of a buttload of work, which is not only quite often hopelessly underestimated. But it's also hard to warm people for doing it - especially if the work is not payed.
Nobody wants to maintaine, particulary not creative people such as programmers, and especially not sombody else's work.
Everybody wants to create new things.
But those will also need maintenance.
And if you neglect maintenance the amount of errors automatically rise by themselves. As an engineer or a software developer you don't need to be told that the more errors there are the quicker new ones occur. Thus resulting in the demand of more maintaining until the number of errors is brought down below a critical level again. Otherwise it's just a question of time until your project dies.

So maintenance has to be your top priority because of error's nature of automatic reproduction.
And you better keep maintenance on a relative high level from the start to keep the amount of errors below a critical level, and so the amount of maintenance at the lowest minimum possible.
Otherwise all you may produce at most is a shooting star: Very cool, hot new and fancy stuff, but very short term only.
In many cases so short term you may not even get a prototype. A waste of all start energy before series production or profit get to be at hand.
That's just basics of project engineering.

Because, as I also already said, nobody wants to maintain, all are focused on doing new things only, maintenance is not seldom downplayed, leading to underestimation.
The amount of maintenance effort is not below 10% or whatever not few people - especially salesmen - may dream of.
Technical real world system's values for maintanence are more about in the area of 30...40% - if you are lucky and really have a system that needs few maintenance.
60...80% or even more are realistic values for bigger software projects such like an OS.

You see, there is not so much room for bringing up lots of fancy ideas by the start.
But of course new ideas are also needed to keep its sustainabilty.

If one take a look of how many Linux distributions there are, one may ask "how it come?" and in particular "how it come, that there are so many, but only half a dozen are used by app. 90% of all users?". So finally one may come up with the question:
"So, what's the difference about the popular, commonly used - the big ones and the rest?"
You may be right with the answer about its size or popularity and advertising. But this would only be partially true.
If you peel it down to its very core you figure out, the difference is if the organization is successful or not.
Excluding the ones that only ment to be an experiment for a special single purpose only, most of the "dead-end-distries" had more potential of ideas as they can handle.
Many of them started by ideas of how to make things better as the others and ended before they are even really started because of there is more work to be done as it can be done by the people participated - and maybe other organization issues.
The popular turnkey distries - it doesn't matter if they are done right, wrong, well or worse - reached at least properly a level of completion that for a user is satisfactionary usable.
For that two things are mandatory:
1. Project planning, management - organization. Defining targets and distributing work.
2. Enough resources to do so in time - including the maintenance of what exists already, which is also growing over your project grows.
One may discuss and decide about the different possibilities of how this has to be done. But without any or even a sufficient amount of it a project is doomed by its start.

Inharent of any kind of project management/organization always is limitations, the restriction of liberties. One may discuss what to do, and how to do it. But then you have to decide, focus and stick to the target which means: there are no other targets or at least they are not followed, until something else is reached first.
If no target is defined, there is nothing that can be reached at all.
And if not enough focus is put to a target it will also not be reached.

That's a law of nature, quickly overseen, because it's not so much fun.
Especially creative people having more fun of casual, free spiriting brainstorming of ideas.
That's no problem. But you need to be aware of where you are and distinguish one thing from the other -  not mixing it up.
And of course not coming up with demanding ideas somebody else shall deliver. Especially not if you are not paying for it.
Of course I'm aware here this was not the issue at all. But I wanted to get this thought completely to its final point.

*So bottom line:*
Of course if free capacities and resources are available for doing more than maintenance one may discuss what to do with it.
But besides I believe there a way more ideas the FreeBSD project is capable to handle, and of course one may discuss priorities,
you have to ensure anyway:
- maintenance is still sufficiently done for the already existing things with highest priority
- the effort of the new idea needs to be worth to be done
- there are no there ideas needed to be done by higher priority first
- you have enough resources to bring it to an satifactionary end
- and you have enough resources to do the additional maintenance until you can skip something else, if you can skip something instead

Until then you need to be aware of you are staying in brainstorming and just collecting (good) ideas.


----------



## mer (Apr 11, 2022)

Profighost said:


> Having ideas, bringing them up and discussing them _is always a good thing._





Profighost said:


> This is not because of we don't like change or worried about ideas just because we are by principle against anything new just because only it's new





Profighost said:


> But those will also need maintenance.


The whole post is worth a read (or three) but these are the top three that jumped out at me.


----------



## Deleted member 70435 (Apr 11, 2022)

ralphbsz said:


> A: If you want to program in Rust, go ahead. I've heard good things about the language; alas, I haven't had time to use it myself.
> 
> B: If you want to convince others to program in Rust, the best thing you can do is to demonstrate writing good software in it.
> 
> ...


I think you misunderstood, what I said, with this implementation it is possible to load pieces of code from crates. both at the kernel level and at the user level it is possible, and very easily. we know that at the low level these things are just ideas.

my idea, is to run consistently working, with functions by layers. this user-level kernel-level thing, it's just theories. if you actually program a kernel you'll have a wide range of implementations you can do.

you judge me inexperienced, so tell me, what experience do you have, just because you have that title then you think it's something, i demand respect from you. we are all the same here. I don't feel better than anyone else. my english is rustic but solid.


----------



## Deleted member 70435 (Apr 11, 2022)

ralphbsz said:


> A: If you want to program in Rust, go ahead. I've heard good things about the language; alas, I haven't had time to use it myself.
> 
> B: If you want to convince others to program in Rust, the best thing you can do is to demonstrate writing good software in it.
> 
> ...


before commenting on something, you have to educate yourself to deal with people. because i'm talking to you politely

and you find out who has more knowledge, your head is confined in a pattern, that's why you think these things..
if you were more idealistic, we would have people working here.
in doing something new.


----------



## msplsh (Apr 11, 2022)

Dimitri Chuikov said:


> if you were more idealistic, we would have people working here.
> in doing something new.


I like Rust and I hope it buries C++ in the sand.

However.

There are plenty of people working on idealistic projects that don't gain traction.  Idealism has to balance with pragmatism for widespread success.


----------



## sidetone (Apr 11, 2022)

In terms of the code _itself_ without the dependency on the compiler, a kernel in Rust: would be faster, would have more potential for better security, and would be more efficient. Looking at having two compilers and two different programming languages for a base system and kernel together, would be too complicated for the gains. Linux has Rust in their code, but FreeBSD's core system is seen as better. I don't know if you were implying that Rust code can be used without a Rust compiler because of Crates?



msplsh said:


> I like Rust and I hope it buries C++ in the sand.


If Rust can be used in place of C++ which is already in base, without much heaviness on compiler code, then that would be suitable.

The way it would make sense is forking it. The core users of FreeBSD would stay with C, and this is what FreeBSD was founded on. Not more than a fraction will go away from using C. Redox, Thesus and Tock are where a lot of Rust development is. A fork with Rust code would be good. A better target for forking a kernel and perhaps a base system is Minix3, because it's smaller, and is based on a simple and resilient design. There would be less work for developers to accomplish this. Also, Minix3 can use packages from the BSD community, which are mostly in C.

Not having an ability to program (in low level languages), looking at Rust code overwhelms me. A lot of people think C is the best, and wouldn't move from it. Replacing the kernel or anything in base with Rust will require a fork, because FreeBSD staying with C is unlikely to change at this time. There's places for Rust, including forks and projects, where the majority are comfortable and great with developing in Rust.


----------



## Deleted member 70435 (Apr 11, 2022)

we are limited to say how an implementation would work on FreeBSD we will have to see this in practice I will have to sacrifice


----------



## sidetone (Apr 11, 2022)

Normally it could require supporting an infrastructure as large as FreeBSD's. There were few spinoff OS's including MidnightBSD, GhostBSD, MiniBSD, NomadBSD. From NetBSD, there was the spinoff of OpenBSD, which has enough of a community to sustain it.

It could be done more simpler without needing that much of a community, perhaps just a github page, if it's just a kernel and module project, with instructions on how regular FreeBSD users can compile a kernel from that separate project.


----------



## mer (Apr 11, 2022)

Note:  I'm not trying to start any arguments, I'm trying to gain understanding.


sidetone said:


> a kernel in Rust: would be faster, would have more potential for better security, and would be more efficient


Would that not depend highly on the "Rust to machine code" compiler?  Like how clang in the beginning didn't create code as good as gcc, but eventually it caught up and surpassed.
I believe that at one point in time these 3 points were also touted for Java (at least the better security and more efficient).

I think some of the things said about Rust (wrt array bounds checking, type checking other items) have been implemented in the language Ada.


----------



## jbo (Apr 11, 2022)

Same as mer: Trying to have an actual conversation here - not being pro or con rust or anything like that.

I don't doubt that it's possible to create a kernel in rust. After all, it has been done. What I'd like to add to this discussion is the following: A lot of these "modern languages" are unfortunately suffering from the modern hype-train problem. A lot of promises, everybody wants to jump on the wagon and eventually the end result might be something different than initially anticipated (again - not directing this towards rust). Meanwhile, an operating system like FreeBSD takes a lot of effort to develop & maintain. Moving, migrating or forking towards Rust is most likely technically very possible, but the question is whether it's sustainable. What will the world of rust really look like in a few years from now, in a decade, in two decades? It wouldn't be the first time that a modern language that "solves problems" ends up not taking off after the initial hype phase. Then you're stuck with a language in your operating system that becomes even more challenging to maintain and potentially you're loosing even those very advantages you were set out to gain initially.

I know that a lot of people don't like C/C++ - and often for very legit reasons. But the language has proven longevity and sustainability and maintainability. That is often also the reason why even today a lot of python & javascript modules/packages/crates/whatever are C/C++ with language bindings. Another reason for this is, but not relevant to this topic, the fact that one can create language bindings from C/C++ to a vast amount of other languages. That usually doesn't hold true the other way around.

On top of that, one of the differences between C/C++ and rust is that the former is a standard, whereas the later appears to be an ecosystem. This might not be important to a lot of people on this forum but there are plenty of custom C/C++ compilers that were developed for very specific purposes. Maintaining a standard rather than a set of tools provides a lot more flexibility.
Background: I know because I'm a developer of a C library that is officially support 73 different C compilers.


----------



## msplsh (Apr 11, 2022)

jbodenmann said:


> But the language has proven longevity and sustainability and maintainability. That is often also the reason why even today a lot of python & javascript modules/packages/crates/whatever are C/C++ with language bindings. Another reason for this is, but not relevant to this topic, the fact that one can create language bindings from C/C++ to a vast amount of other languages.


Most of these things are just byproducts of ubiquity and inertia.  That's the point of pushing Rust: to eliminate those "advantages" and compete on other grounds.  This viewpoint should be familiar to people pushing to use FreeBSD in places of other operating systems with more ubiquity and inertia.


----------



## sidetone (Apr 11, 2022)

mer said:


> Note:  I'm not trying to start any arguments, I'm trying to gain understanding.
> 
> Would that not depend highly on the "Rust to machine code" compiler?  Like how clang in the beginning didn't create code as good as gcc, but eventually it caught up and surpassed.


In your quote, all else around it was left out, which addressed what you asked about. It ignored the case I've made, that having 2 compilers wouldn't be favorable. If two compilers were used, it could be done as a separate perhaps github project, with instructions for users.


sidetone said:


> In terms of the code _itself_ without the dependency on the compiler, a kernel in Rust: would be faster, would have more potential for better security, and would be more efficient. Looking at having two compilers and two different programming languages for a base system and kernel together, would be too complicated for the gains. Linux has Rust in their code, but FreeBSD's core system is seen as better. I don't know if you were implying that Rust code can be used without a Rust compiler because of Crates?


That depends on if Cargo can be used to use code, without needing a compiler. That's which I've asked about.


----------



## ct85711 (Apr 11, 2022)

A lot of the reason rust code is "faster" isn't anything unique to that language.  The reason rust's code is faster, is because of 3 main reasons.  First, it forces you to start over (hence allowing devs to go over old code and write it cleaner).  Another main reason, is that rust does not support polymorphism and minimal inheritance (which is known to slow the system down).  The last major factor, is that rust's compiler is heavily focused around compile time type checking.  This factors heavily in the template system, as rust's compiler factors templates out and generates individual functions of each static type so there is very little run-time type checking done.

As far as pointers go, they have always been a double edged sword.  They can help, but you are just as likely to cut yourself.  Creates as a whole is simply just rushing to be just like npm.


----------



## msplsh (Apr 11, 2022)

sidetone said:


> That depends on if Cargo can be used to use code, without needing a compiler.


Cargo is a build and packaging tool.


----------



## Deleted member 70435 (Apr 11, 2022)

GitHub - johalun/echo: FreeBSD kernel module in Rust
					

FreeBSD kernel module in Rust . Contribute to johalun/echo development by creating an account on GitHub.




					github.com


----------



## sidetone (Apr 11, 2022)

My question was based on:


Dimitri Chuikov said:


> with this implementation it is possible to load pieces of code from crates. both at the kernel level and at the user level it is possible, and very easily.





sidetone said:


> I don't know if you were implying that Rust code can be used without a Rust compiler because of Crates?





msplsh said:


> Cargo is a build and packaging tool.


----------



## Deleted member 70435 (Apr 11, 2022)

well there is already and can be used, I will have an idea. many here still said that I don't have the competence for that. and this my friends is what we will see








						echo/crates at master · johalun/echo
					

FreeBSD kernel module in Rust . Contribute to johalun/echo development by creating an account on GitHub.




					github.com


----------



## jbo (Apr 11, 2022)

Dimitri Chuikov said:


> many here still said that I don't have the competence for that.


Unless I'm begin unintentionally oblivious here I don't think that anybody stated that you don't have the competence.
I think the intention was to communicate that these things usually require demonstration & proof-of-concepts to elevate a discussion from this from the current state to something more concrete that can be objectively evaluated.

Everybody in this topic/thread that you created appears to be participating in this discussion willingly - which is a good thing! 
Sometimes, brevity can be easily mistaken for offensive statements. Hence my posts are usually a bit longer than the average on this forum 

Thank you for sharing that FreeBSD kernel module written in Rust! Not something I would have actively searched for, but something I'd definitely want to check out!


----------



## sidetone (Apr 11, 2022)

GitHub - johalun/echo: FreeBSD kernel module in Rust
					

FreeBSD kernel module in Rust . Contribute to johalun/echo development by creating an account on GitHub.




					github.com
				





> *Requirements:*
> 
> FreeBSD machine
> Rust nightly
> ...


It will need the compiler because of the package/port, even if the compiler isn't needed and only Cargo is in the actual use. Come to think of it, compiling the kernel in C is a common user task for FreeBSD users. Compiling, rather than inserting code, would obviously need the Rust compiler.

As long as it can be used with existing kernel drivers written in C, which is likely. So much code like graphics modules is necessary for many people's uses, that will take too much to be written in another language as it's taken a long time for those to develop.

That's a project that Dimitri Chuikov can contribute to, and add Documentation, including a Howto, on how to use it.

Imagine if the FreeBSD kernel in Rust were used in https://www.minibsd.org/, which is a 16 MB FreeBSD fork. That would be halfway towards a whole new operating system.


Dimitri Chuikov said:


> many here still said that I don't have the competence for that.


I saw criticism of the idea, but I don't know if anyone said that. I don't have the ability to do lots of things which are complex and require a specific knowledge set.

I see criticism of ideas a lot, while I don't get offended by them, I get frustrated with my interpretation of them as people defaulting to, "you can't do this," "you can't do that", which seems like being stuck in a loop for what is or may be better. But, it turns out that Rust as a FreeBSD kernel module is a project that has been done before.

It's good that the project was found for those who like to try it. And it's good that the link to it and the thread will bring attention to it. It's fitting for the forum. It would be great to see its implementation be discussed in the near future as well. It would be cool to see and learn how that runs.


----------



## msplsh (Apr 11, 2022)

Rust - FreeBSD Wiki


----------



## schweikh (Apr 11, 2022)

I'm a committer and love rust for the two features it advertises most often: memory safety through the borrow checker and fearless concurrency. These are two error classes C is particularly vulnerable to that become non-issues with rust. That's a HUGE thing. If a fairy granted me a wish for the successor of C, it would be rust.

But I wouldn't hold my breath for seeing rust in the kernel. Datapoint being Linux, which ages ago tried to at least compile kernel code in C++ mode, expecting "better type safety" or other vagueness. That initiative failed for reasons I'm too lazy to dig up.
Then you need to convince a lot of smart people to invest time learning a new language. Rust is quite different from C, and if you're like me, never touched java or C++ because C is good enough, then maybe C is actually good enough for the FreeBSD kernel. And if it ain't broke, why fix it?


----------



## sidetone (Apr 11, 2022)

I don't like that two separate compilers would be needed, even if both are on top of the same LLVM. In the short term, we have that anyway. The base has its own compiler which (for most) comes in binary, then some ports always ask for a newer compiler version for C, sometimes asking for multiple versions of LLVM/C. The code in Rust would be faster and have improvements which would have an inconvenience of coming with two compilers, but those compilers would otherwise not have an effect on the speed of the code. If it were forked from MiniBSD, that would be a whole new operating system, which would rely on only 1 compiler chain for the base.

I would like to see discussions and experiences on here about the implementation of a Rust Kernel used in FreeBSD or any FreeBSD derivative.

The latest updates of the code of Echo (Rust kernel for FreeBSD) are 5 years old. It looks like a surge of interest in it can help with it getting patches and other updates.

Also, note from the Echo website:


> *Warning*
> If there are any bugs or faulty code the kernel will most likely hang.
> I recommend testing the module in a virtual machine.
> It keeps your system safe and it makes it easier to develop and test.



Note from Redox-OS website, which is a completely different project than Echo:


> Custom libc written in Rust (relibc)


That Rust has its own implementation of libc. Relibc seems to have its own problems:








						GitHub - redox-os/relibc: Mirror of https://gitlab.redox-os.org/redox-os/relibc
					

Mirror of https://gitlab.redox-os.org/redox-os/relibc - GitHub - redox-os/relibc: Mirror of https://gitlab.redox-os.org/redox-os/relibc




					github.com


----------



## msplsh (Apr 11, 2022)

sidetone said:


> The latest updates of the code of Echo (Rust kernel for FreeBSD) are 5 years old. It looks like a surge of interest in it can help with it getting patches and other updates.


Echo is just a PoC for writing a kernel module in Rust, not the kernel itself.  Doesn't need updates unless it doesn't work anymore.

Also the warning is basically for people who don't know that screwing up in kernelspace means Game Over.


----------



## sidetone (Apr 11, 2022)

GitHub - johalun/echo: FreeBSD kernel module in Rust
					

FreeBSD kernel module in Rust . Contribute to johalun/echo development by creating an account on GitHub.




					github.com
				





> *About*
> FreeBSD kernel module in Rust


----------



## Deleted member 70435 (Apr 11, 2022)

___Theseus_Crates___ - Rust
					

Overview of Theseus




					www.theseus-os.com


----------



## sidetone (Apr 12, 2022)

It's occurred to me, the Rust Kernel software for FreeBSD is 3 to 5 years old. Which FreeBSD version kernel did it work with? Would an older Rust kernel or this program work with a newer FreeBSD, or perhaps with all of the other kernel modules and parts of the base system? Echo is a kernel module that builds a Rust kernel based on a newer FreeBSD and kernel?

MiniBSD is also old from 2016. Though, it's a set of scripts to reduce the size of a FreeBSD system to a MiniBSD system. I thought it was an actual iso install of that full system. The tiny OS may lack the tools to build/install a Rust kernel.


Back up kernels is what I have on my system, with the bootloader to select from them on reboot, which is handy in the case of a kernel crash. Even if it means keeping at least 1 original working kernel in C. Perhaps manually copying them in, if there's no backups on a system.

/boot/loader.conf:

```
kernels="kernel kernel.old kernel.orig kernel.bk kernel.c kernel.rust"
kernel= "kernel" # default selection kernel
```
kernel.old always gets replaced, so can't be always dependable for a sure backup. The last one installed will become kernel. These kernel directories can be copied to new directories of a corresponding descriptive name. kernel.bk can be one in C of the original one of the FreeBSD version, or of one saved from any `freebsd-update` that works. The latest compiled Rust or C kernel can be chosen on each bootup as well. This menu can also be used to test performance of a compiled Rust vs C kernel on a different reboot.


----------



## jbo (Apr 12, 2022)

sidetone said:


> Echo is a kernel module that builds a Rust kernel based on a newer FreeBSD and kernel?


I don't think that this is correct. The echo GitHub repository initially linked by Dimitri Chuikov appears to be "just" a kernel module. It's not a kernel. It's just a kernel module. Just like you'd write a FreeBSD kernel module in C except that this one is written in Rust.


----------



## Profighost (May 20, 2022)

Rust: A Critical Retrospective «  bunnie's blog


----------



## Profighost (May 21, 2022)

Since you liked it tha much:
I got it from



			Hacker News Daily
		


which actually is a link on Colin Percival's website, who's (as you all already know ) member of FreeBSD's Primary RE Team (security I think.)


----------



## grahamperrin@ (May 21, 2022)

Profighost said:


> … member of FreeBSD's Primary RE Team (security I think.)



<https://www.freebsd.org/administration/#t-re> shows Colin Percival as _Deputy Lead_ within the Primary Release Engineering Team. <https://people.freebsd.org/~cperciva/> leads to security-specific <https://people.freebsd.org/~cperciva/funding.html>, and <https://www.daemonology.net/>. 

Recent comments in /r/freebsd include <https://old.reddit.com/comments/s67ymv/-/i8utndz/?context=1> about the ESP for 13.1-RELEASE; <https://old.reddit.com/comments/ut1dd6/-/i98s5my/> about Sony; and <https://old.reddit.com/comments/ur65ph/-/i9ekbj5/?context=1>, which led to FreeBSD bug 264113 – FreeBSD 13.1-RELEASE Installation Instructions: update


----------



## astyle (May 25, 2022)

just my 2 cents here, but last time I looked at Redox-OS,  it seemed to be a 'proof-of-concept' work. The only proper screenshots that I could find - they were in a VM. The rest were photographs of laptops running Redox-OS.  

I like some ideas put forth by Rust (memory safety and security), but rust-crates seem to be another case of reinventing the wheel (think Perl modules or Python modules). C/C++ libs (or Ruby libs, for that matter) are a similar idea. Code re-use is a nice idea, but in practice, it may not be that practical.


----------



## drhowarddrfine (May 26, 2022)

When Rust first came out, years ago, I pooh'ed it saying it was "not another language to save us all". Then took the time to study it and changed my mind remarking, "There's something to this after all. I kind of like it!" but never found the time or need to learn more. As time went on, I hear, more and more lately, about the steep learning curve. And now they added something to make life more difficult, iirc. 

No longer do I see people recommending Rust as their goto language. Always keep things as simple as possible. For me, that's C.


----------



## getopt (Jun 3, 2022)

Dimitri Chuikov said:


> Hello when I mentioned that rust can give us a *good programming base* I said in the way we can implement things, I see the *FreeBSD kernel code for example is something very simple *and* something that can, if written easily.*


That said with this impressive title
what we can do with rust is beyond what we can imagine​there is in deed something I couldn't imagine:

Rust cannot cope with the FreeBSD kernel > 11.0 unless *COMPAT_FREEBSD11* is set. Well GENERIC has set it for downward compatibility reasons.

But as the friends of lean and hardened custom kernel building know this may include risks one want to avoid by unsetting/removing such kernel options.

COMPAT_FREEBSD11 only works thanks to the following:

Apr 7, 2017 How to deal with breaking changes on platform ? [BSDs related]
Sep 17, 2021 Drop support for FreeBSD 10 from std
This is because the Rust ecosystem still depends on some FreeBSD 11 syscalls after the ino64 changes.

The timespan for having this *not* *fixed* is impressive given the mouthful "*something that can, if written easily".*


----------



## RoGeorge (Jun 3, 2022)

Never used Rust, but no amount of tech merits (even if they really were "beyond imagination", which I doubt) will convince me to use it, because of displays like this:

__ https://twitter.com/i/web/status/1267519582505512960_View: https://twitter.com/rustlang/status/1267519582505512960_



> Rust Language
> @rustlang
> Rust believes that tech is and always will be political- take some time today to invest in your community.



I'm from Eastern Europe and sick of propaganda, any kind of propaganda, no matter which side(s) is coming from.

( Don't have or use twitter myself, only found out accidentally about that tweet from https://www.eevblog.com/forum/programming/rust-is-political/ )


----------



## zirias@ (Jun 3, 2022)

You're confusing propaganda with political activism. Propaganda by definition uses manipulative techniques, while here, we have a clear statement not trying to hide anything.

Furthermore, refusing to use a technical product because its creators clearly express their opinions is, at least, political activism.


----------



## shkhln (Jun 3, 2022)

There are far more interesting aspects to the language than California-style social activism. On a side note, my favorite over-abused phrase is "x is a social construct". You know, _Cargo__ is a social construct_.


----------



## zirias@ (Jun 3, 2022)

I don't think giving a statement against police brutality can be directly linked to any talk about "social constructs". I _do_ think almost any individual is political, at least to some extent. Many software projects choose _not_ being political though, and there are good reasons: you avoid the inevitable "flames". I don't know whether anyone thinks, police brutality would be fine ... I suppose not (?) and still people seem to be offended by a project taking a position. This is just unnecessary. IMHO, refusing the project for that is just as unnecessary. Why not just relax....


----------



## RoGeorge (Jun 3, 2022)

Still an offtopic declaration for a software organization, though you made me lookup the dictionary:

Propaganda


> information, ideas, opinions, or images, often only giving one part of an argument, that are broadcast, published, or in some other way spread with the intention of influencing people's opinions


source https://dictionary.cambridge.org/dictionary/english/propaganda

Seems to me like that tweet fits each word from the definition of propaganda.

Whatever it would be called, I'm loathed of everybody spamming whatever cause or ideology they might promote all over other people's life.  I don't mind if they go make their own party, or own guerilla, or own organization for their political activism.

Hijacking other organizations or activities to use them for political activism is shitty, and also a dangerous practice.  I don't want to see that becoming the norm, so I would avoid Rust at all costs, and will recommend others to stay away from it unless they want to be brainwashed into whatever ideological conformance they might have been practicing there.

I know their behavior is wrong because I've seen this kind of activism done before (during Ceusescu's regime here, in Ro), with political activists taking over the other people's work, or taking over apolitical organizations.  It ended very bad here, and in the last couple of decades similar ideological takeovers started to happen again, this time in the western world.

It's the same Animal Farm story happening all over again.
Won't argue any further about this.


----------



## shkhln (Jun 3, 2022)

Zirias said:


> I don't think giving a statement against police brutality can be directly linked to any talk about "social constructs".


The brutality statement is in a _different_ tweet. "x is political" is exactly like "x is a social construct" or "black lives matter". It's not there for the content (we already know that to be true, there is nothing new or profound), it's a slogan a particular group of people use to identify themselves.


----------



## getopt (Jun 3, 2022)

shkhln said:


> There are far more interesting aspects to the language than *California-style social activism*.


Although you wording implies some anti-activism propaganda you are completely right! Let's talk on topic:

*Rust has a long term problem with newest FreeBSD kernels.*


----------



## zirias@ (Jun 3, 2022)

RoGeorge said:


> Seems to me like that tweet fits each word from the definition of propaganda.


A one-sentence definition is a bit weak, but the wording "part of an argument" points into the correct direction. To really understand what propaganda is and how it can be distinguished from simply activism, you will need a somewhat longer text. Actually, wikipedia's explanation of propaganda isn't the worst.

Whether activism is something you want to see in a software project or not, that's your choice. Just saying, refusing it because of that (and publicly talking about it) is activism as well.


----------



## shkhln (Jun 3, 2022)

getopt said:


> *Rust has a long term problem with newest FreeBSD kernels.*


For reference: some discussion at https://github.com/rust-lang/rust/issues/89058.


----------



## zirias@ (Jun 3, 2022)

This is less of a problem than you might think. The default FreeBSD kernel configuration includes compatibility as far back as FreeBSD 4, see https://cgit.freebsd.org/src/tree/sys/amd64/conf/GENERIC#n62

Nevertheless it should be addressed.


----------



## getopt (Jun 3, 2022)

shkhln said:


> For reference: some discussion at https://github.com/rust-lang/rust/issues/89058.


For reference: This reference was already given by me there:


getopt said:


> COMPAT_FREEBSD11 only works thanks to the following:
> 
> Apr 7, 2017 How to deal with breaking changes on platform ? [BSDs related]
> Sep 17, 2021 Drop support for FreeBSD 10 from std


----------



## getopt (Jun 3, 2022)

Zirias said:


> Nevertheless it should be addressed.


because Rust upstream does not care about FreeBSD.


----------



## shkhln (Jun 3, 2022)

getopt said:


> For reference: This reference was already given by me there:


My apologies.



getopt said:


> because Rust upstream does not care about FreeBSD.


I think they do, they just move very slowly.


----------



## zirias@ (Jun 3, 2022)

getopt, on the other hand, keeping backwards compatibility the way FreeBSD does has a downside: It doesn't _force_ projects interfacing directly with syscalls to move


----------



## getopt (Jun 3, 2022)

shkhln said:


> they just move very slowly.


In fact they did not move since years.


----------



## getopt (Jun 3, 2022)

Zirias said:


> keeping backwards compatibility the way FreeBSD does has a downside:


Yup! That's the way to look at it. Making it necessary to configure more sane kernels. Which results in failing to build Rust. Not that I miss it.


----------



## msplsh (Jun 3, 2022)

I read the threads and "I just figured that platforms wouldn't do this." has got to be the best summary of the problem.


----------



## astyle (Jun 3, 2022)

Y'all can say the same things about Tor, security/nnn ports, and the like, or even throw OpenBSD into discussion. Political activism can be done using any platform, any software. Some tools offer better protection against snooping, some tools offer better analysis capabilities to aid snooping, the point of political activism (and propaganda) is *information*, not the software tools used to process/move it. Bans on certain cryptography methods around the world are really attempts to control information spread. Conceptually separating *information* and *tools* can be a difficult case to make, but it's still an important distinction to be aware of.

Having said all that, I'd think that these forums are meant to be a place to discuss and understand the technical side of things. Let's keep politics out.


----------



## zirias@ (Jun 3, 2022)

astyle I'm all for keeping politics out of (opensource) software projects, _if possible_. It might not always be possible, you have a good example here with tor, some of the reasons for its existence can be characterized as political. For something like rust, it would be possible for sure.

All I said was: Rejecting some software project because they expressed some political opinion, and publicly talking about that, is political as well.


----------



## msplsh (Jun 3, 2022)

What's happening now is that things _have always been_ political (choosing FreeBSD over Linux is a political choice) and now people realize it's advantageous to state desired policy up front to keep undesired policy from hijacking the project from the back.


----------



## astyle (Jun 3, 2022)

msplsh said:


> choosing FreeBSD over Linux is a political choice


It was not the case for me... I simply liked the feature set of FreeBSD better. I like to think of my decision as 'Educated consumer decision', rather than a political one. Not buying LeBron-themed gym socks (and looking for high-quality alternatives) - now that is a political decision of mine.


----------



## msplsh (Jun 3, 2022)

But you set policy for yourself (use FreeBSD, not Linux), based on the values (features that are valued by FreeBSD) of FreeBSD.


----------



## RoGeorge (Jun 3, 2022)

Seems like political/politics is yet another fuzzy word:

Political - relating to politics
Politics - the activities of the government, members of law-making organizations, or people who try to influence the way a country is governed:
- the job of holding a position of power in the government:
- the relationships within a group or organization that allow particular people to have power over others:
Source:








						political
					

1. relating to politics:  2. relating to politics:  3. relating to politics:




					dictionary.cambridge.org
				











						politics
					

1. the activities of the government, members of law-making organizations, or…




					dictionary.cambridge.org
				




Let's take another dictionary:
Definition of political

1a : of or relating to government, a government, or the conduct of government
b : of, relating to, or concerned with the making as distinguished from the administration of governmental policy
2 : of, relating to, involving, or involved in politics and especially party politics
3 : organized in governmental terms political units
4 : involving or charged or concerned with acts against a government or a political system political prisoners
Source:








						Definition of POLITICAL
					

of or relating to government, a government, or the conduct of government; of, relating to, or concerned with the making as distinguished from the administration of governmental policy; of, relating to, involving, or involved in politics and especially party politics… See the full definition




					www.merriam-webster.com
				




-------------------

To sum it up, politics has to do with the established government, and with enforcing or combating its powers.

Not every individual choice, or any personal attitude, is aimed at the government or at its powers.  Therefore not everything is political.


----------



## msplsh (Jun 3, 2022)

Conveniently, you left out  ignored this one on "politics"

"the relationships within a group or organization that allow particular people to have power over others"

In M-W "relating to, involving, or involved in politics.." Well what does the politics entry say... "political actions, practices, or policies"

There's no divorcing the word politics from policy.


----------



## astyle (Jun 3, 2022)

msplsh said:


> But you set policy for yourself (use FreeBSD, not Linux), based on the values (features that are valued by FreeBSD) of FreeBSD.


I have to quibble with this... the BSD license is different from the GNU license. FreeBSD values the rights/freedoms afforded by the BSD license. As a consumer who is after technical capabilities for personal use, I never cared if the software is covered by BSD license or GNU license. Caring about that is political, IMHO. 

(Freedom to do what you want) is not the same thing as (having/not having a specific feature like ZFS, for example). Well, we have enough threads on these forums that split hairs like that.


----------



## tux2bsd (Jun 3, 2022)

astyle said:


> I never cared if the software is covered by BSD license or GNU license.


Software producers and distributors are the ones that have to care, not the user unless the user is psychotic passionate about licensing.  An example of license selection is Linus Torvalds using GPLv2 for the Linux kernel, he chose not to adopt GPLv3, because he does not agree with the v3 license (in short the v3 license is invasive and FSF overstepped).

BSD license is simple to understand, in short the code is surrendered to others once published.  BSD code simply exists with the license attached, and distribution of its derivative compiled code can be without source code.  GPL says distribution must be with source code, forcing the "original" to be potentially built upon out in the open i.e. it doesn't allow the code to become hidden (if the compiled code is being published).

Most SaaS vendors take advantage of either license, they leech and barely give anything back.

I'm not advocating for either license. (has to be stated because these forums choose to misread things constantly.  BSD licence, i.e. 2 clause / probably others)


----------



## astyle (Jun 4, 2022)

tux2bsd said:


> Software producers and distributors are the ones that have to care, not the user unless the user is psychotic passionate about licensing.  An example of license selection is Linus Torvalds using GPLv2 for the Linux kernel, he chose not to adopt GPLv3, because he does not agree with the v3 license (in short the v3 license is invasive and FSF overstepped).
> 
> BSD license is simple to understand, in short the code is surrendered to others once published.  BSD code simply exists with the license attached, and distribution of its derivative compiled code can be without source code.  GPL says distribution must be with source code, forcing the "original" to be potentially built upon out in the open i.e. it doesn't allow the code to become hidden (if the compiled code is being published).
> 
> ...


Technically speaking, www/apache24 (or any server for that matter) can be thought of as SaaS, buddy. 

A political question would be would be about Office 365 running in a browser - Just how did Microsoft pull that off, considering that o365 was a pretty blatant violation of the per-processor licenses that applied to Office 2010?  No way to do it without resolving internal politics to suit the new versions.


----------



## acheron (Jun 4, 2022)

getopt said:


> That said with this impressive title
> what we can do with rust is beyond what we can imagine​there is in deed something I couldn't imagine:
> 
> Rust cannot cope with the FreeBSD kernel > 11.0 unless *COMPAT_FREEBSD11* is set. Well GENERIC has set it for downward compatibility reasons.
> ...


And I'm sure you are working on a fix


----------



## tux2bsd (Jun 4, 2022)

astyle said:


> Technically speaking, www/apache24 (or any server for that matter) can be thought of as SaaS, buddy.


astyle you sure do love derailing forum threads, and you're wrong.  These forums are such a detraction from the good work the FreeBSD developers and other contributors do.


----------



## astyle (Jun 5, 2022)

tux2bsd , please cut out the personal attacks. I realize you have an admiration for FreeBSD and the work that the devs put in. If you want to point out that I got something incorrect, please collect some links to back up your point.



tux2bsd said:


> These forums are such a detraction from the good work the FreeBSD developers and other contributors do.


These forums do get visit from the Foundation devs for ideas. A couple of mine got heard, BTW.


----------



## tux2bsd (Jun 5, 2022)

astyle said:


> These forums do get visit from the Foundation devs for ideas. A couple of mine got heard, BTW.


Good for you.  Funnily enough my suggestion is in there too.  Joe deliberately made a post to ask on behalf of the foundation, that is very different from dozens of devs lurking to go into a coding frenzy if astyle happens to have an idea.


astyle said:


> If you want to point out that I got something incorrect, please collect some links to back up your point.


No.  I have zero time for forum users, like you, that attempt to trump others using inane bullshit.


----------



## stratact (Jun 5, 2022)

May I throw in something about Rust (and any "modern" system languages, like Zig)?

The problem with these new languages is that they suffer from a lack of maturity.

I don't know if it's practical to rewrite the FreeBSD kernel just for their perks, like memory safety, but at the moment these languages require you to upgrade your compilers after X weeks. From each upgrade, they may sometimes throw compiler errors that require changes from parts of the stdlib API to a "better renamed" version of them. If you're dealing with massive code bases, these constant API renamings can be a huge and unnecessary pain. Another problem is their third-party library ecosystems. Many developers of popular libraries/modules would constantly change the APIs of their libraries because they always "feel the need to innovate" and would never come to a stability point. This ends up with both library and application developers to selectively pull specific versions of libraries. But this makes it worse when you depend on libraries that would pull in the same libraries repeatedly but with many different versions from each of them. This ends up leading to a more greater dependency hell than necessary. I don't know if the Rust compiler developers even stabilized the ABI of their compilers yet.

With regarding all of this, they are far from being "mature" and ready for production in mission critical sectors or businesses. Any kind of breakages would be unacceptable for them.


----------



## Crivens (Jun 5, 2022)

The signal to noise ratio here is indication for a reloction of this thread into a secondary resource transportation vessel. You have untill tomorrow to prove me wrong.


----------



## getopt (Jun 5, 2022)

Crivens said:


> secondary resource transportation vessel


If this vessel is rolling gently in the Black Sea, where some belief the "Moscow" sunk due to "heavy storms", Rust builds faster in salty waters.


----------



## Crivens (Jun 5, 2022)

getopt said:


> If this vessel is rolling gently in the Black Sea


I don't think so. More likely is an exothermal size compaction process, also known as dumpster fire. Be careful not to be in the blast radius.


----------



## getopt (Jun 5, 2022)

God of rusty threads, if you are so mighty show your force.


----------



## astyle (Jun 5, 2022)

stratact said:


> May I throw in something about Rust (and any "modern" system languages, like Zig)?
> 
> The problem with these new languages is that they suffer from a lack of maturity.
> 
> ...


I like the point, but I think what's getting lost is that A`P`I != A`B`I. You can force the former to be identical, but the latter would get in the way.


----------

