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

D

Deleted member 70435

Guest
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.

 
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.
 
Phishfry said:
95% of the people here despise anything new.
Click to expand...
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 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.
Click to expand...
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.
 
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.
 
Dimitri Chuikov said:
maybe you guys don't like a new idea, but i had a good idea and i need your opinion.
Click to expand...
"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.
 
  • Like
Reactions: mer
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?
 
mer said:
It's trivial to create an http server listening on a port in Node.js, takes a bit more effort in C++.
Click to expand...
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:
Code: 
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.
 
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.
 
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.

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.
Click to expand...
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.
 
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.

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.
Click to expand...
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.
 
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.
Click to expand...
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.
 
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
 
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.
 
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
Click to expand...
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.
 
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.
 
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.
Click to expand...
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.
 
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.
Click to expand...
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?
Click to expand...
That depends on if Cargo can be used to use code, without needing a compiler. That's which I've asked about.
 
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.
 
You must log in or register to reply here.
Back
Top