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.
Best,
Simon
On 5/12/22 12:13, Stefan Eissing wrote:
Hi Simon,
Am 12.05.2022 um 11:28 schrieb Simon Studer <simon.stu...@netnea.com>:
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 found https://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 in
https://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 in https://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
during the build process. The project is located here:
https://github.com/studersi/apache-rs. I have not implemented any abstractions
yet that are more idiomatic to Rust and stuck to the FFI generated by bindgen
for now. I will likely add such abstractions later to get the most out of
Rust's safety guarantees.
Is anyone else looking into this or maybe even the owner of one of the other
projects? Any other thoughts or comments are welcome as well :-)
Rust is an excellent language. The weakness I see is that no one commits to any
long-term stability. If you use Rust, you must account for language and crate
changes which will force you to upgrade at any time. If a crate fixes a CVE, it
means you have to re-build your Rust component using the recent versions of
everything.
I hope this explains a bit the reasons behind writing mod_tls in C and linking
Rust from a (sadly static) library.
Kind Regards,
Stefan
Best,
Simon
On 8/21/20 01:00, Wendell Hatcher wrote:
Golang!! πππ
Wendell
On Aug 20, 2020, at 6:58 PM, Nick Kew <n...@apache.org> wrote:
ο»ΏOn Thu, 20 Aug 2020 21:59:50 +0200
Simon Studer <simon.stu...@netnea.com> wrote:
Hi everyone,
Recently, I was wondering which programming language should be used
for new Apache httpd modules.
Whatever suits the module's developer and task.
The C API has a stability promise: if you use it, your
module will continue to work with (at least) future 2.4.x
releases. That give you C or any language with C linkage.
If you deviate from the API, you're on your own.
Alternatives that (broadly speaking) wrap the C API are also
possible: see for example mod_perl and mod_lua.
--
Nick Kew
