Hi Stefan,
Thank you for the article. I think I will have to give this some more
thought.
In any case, your input has been very helpful!
Best,
Simon
*From:* Stefan Eissing [mailto:ste...@eissing.org]
*Subject:* Which programming language should be used for newly developed
modules?
*Date:* Monday, May 16, 2022, 11:03
*To:* modules-dev@httpd.apache.org
Am 12.05.2022 um 15:41 schrieb Simon Studer:
Hi Stefan,
Thank you for the quick and extensive feedback!
To be honest, I was not expecting there to be so many good reasons not to use
Rust but I think I see your point that it would be difficult to maintain and
that compatibility would absolutely be a concern.
From what I gather most of the problems arise the moment you add the
abstractions and if you do not add such abstractions there is not much reason
to use Rust in the first place.
Golang had been cheered for when I first asked the question. Do you know by any
chance if there would be similar issues with Golang? If not, I might give that
a shot instead.
A good article about (against, actually) about Go and its
shortcomings:https://fasterthanli.me/articles/lies-we-tell-ourselves-to-keep-using-golang
Kind Regards,
Stefan
Best,
Simon
On 5/12/22 12:13, Stefan Eissing wrote:
Hi Simon,
Am 12.05.2022 um 11:28 schrieb Simon Studer:
Hi everyone,
When I read about Apache's use of rustls I thought of this thread again.
For mod_tls, the module itself was written in C linking to the rustls-ffi. I
have been wondering if it would be desirable to implement the modules
themselves in Rust as well and how you would go about doing that. This is
something I have superficially looked into in the past but never really
followed through with.
I looked around and foundhttps://github.com/majorz/apache2-rs which has been
inactive since about 7 years ago. There are also a number of forks which are
more recent but also appear to be inactive and left in an early development
state. There appears to be one fork that has only just been worked on recently
with minor tweaks but it is still the same for the most part.
When I started the work on mod_tls, I was pointed to that abandoned project as well. The
main issue I see in this approach is that one does "duplicate" Apache APIs and
those duplications do not follow any updates/improvements that the server will do over
time. This may lead to various breakages, even when the API is extended in a C-backward
compatible way. This happens quite often in the 2.4.x release line.
Examples of that:
- Adding an enum: if a new HTTP status comes up, the sever adds a definition to its
enums, but the "pub enum Status {...}" (as defined
inhttps://github.com/majorz/apache2-rs/blob/master/src/httpd.rs) would not follow. The
Rust language runtime will panic() if it encounters an enum not properly defined.
– the wrappers inhttps://github.com/majorz/apache2-rs/blob/master/src/ffi.rs do not
follow either and will not account for added fields. Adding fields happens regularly. The
"wrong" size will most likely be problematic in the Copy/Clone traits
To control that, all these definitions would best be done as part of the Apache
httpd project. That would require a serious build-up of Rust competence among
the core developers. It is doubtful, if the existing team is interested in
that. Of course, Rust people who want to make a long-term commitment in the
project would not be turned away. But so far, I do not see any.
Beyond the pure writing code stuff, the target platforms would need to be
managed. Apache runs on architectures which are not supported by Rust.
Also, feedback from linux distributions I got (those may not be representative)
is that they are hesitant to include more Rust components. I have heard of none
that has picked up mod_tls in their package distribution. That hesitation seems
mainly to stem from the fact that Rust regularly re-invents itself and requires
everything to update to the current state of languages and crates. Those are
mostly in 0.x.x versions and APIs do change regularly.
This means that updating a Firefox requires a Rust updated which requires an
update of crates which then might mean other Rust packages will no longer
compile and one has to update them too, if indeed such an update for the
Firefox Rust version is available. etc. etc. This conflicts with any LTS
distribution model.
tl;dr
The update/backward compatibility/dependency handling of Rust and the *nix
world where Apache contributes too are different in vital aspects. This makes
delivery of Rust based modules there difficult. If you do a module just for
your own/organization, this might be fine.
Recently, I have started to implement something similar, mostly to get some
familiarity with the process of using Rust's bindgen tools. The approach I
chose is somewhat different as I generate the FFI with bindgen on the fly
duri
