> Am 12.05.2022 um 15:41 schrieb Simon Studer <simon.stu...@netnea.com>:
>
> 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 <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
>
