[Vendors] Will a move to Rust pose an impossible issue to you?

[LebedevRI]

Note

This issue concerns vendors only. If you do not work on a project that uses this library -- do not comment.

The list of "suspects" here is unfortunately unknown to me,
there isn't an established communication group that i'm aware of,
(I'm also not sure if anybody actually uses the library)
so hopefully those who are affected, are reading this.
(It would be good to establish that group, if anyone cares?)

Now that April 1'st is out of the way...

I think, it just needs to happen, at least in principle.
In practice however, it's of course a rather problematic,
invasive, change, that will come with it's own issues.

If anyone still uses this library, would that be a complete show-stopper for you?
If it wouldn't it would be interesting to know, too.

[kmilos]

Will switch to Rust accelerate keeping up w/ codecs somehow?

FWIW, it'll definitely reduce my involvement, as I have limited time and brain bandwidth to pick up Rust quickly.

As far as integrating w/ darktable or vkdt (known clients to me), I'll let others comment. @TurboGit @hanatos

(It would be good to establish that group, if anyone cares?)

Ping discuss.pixls.us and [email protected] as well? The question will get more visibility perhaps, but you'll also likely get a lot of unsolicited opinions to filter through...

P.S. There are similar ongoing efforts: https://github.com/dnglab/dnglab/tree/main/rawler and https://gitlab.freedesktop.org/libopenraw/libopenraw

[LebedevRI]

Will switch to Rust accelerate keeping up w/ codecs somehow?

Realistically speaking, unless efforts are joined, future isn't looking too bright.

FWIW, it'll definitely reduce my involvement, as I have limited time and brain bandwidth to pick up Rust quickly.

I don't know rust either, like, at all :)

As far as integrating w/ darktable or vkdt (known clients to me), I'll let others comment. @TurboGit @hanatos

I'm not as worried about darktable side of things,
the guidelines would still be applicable,
well, at least as a matter of intent, the reality may differ,

I'm more wondering about other consumers, ...

(It would be good to establish that group, if anyone cares?)

Ping discuss.pixls.us and [email protected] as well? The question will get more visibility perhaps, but you'll also likely get a lot of unsolicited opinions to filter through...

..., and i'd be surprised if they read pixls but not the Issues here.
@kmilos Please do [feel free to] X-Post this issue to the list,
i guess i'll X-Post to disscuss (link)

P.S. There are similar ongoing efforts: https://github.com/dnglab/dnglab/tree/main/rawler and https://gitlab.freedesktop.org/libopenraw/libopenraw

[hanatos]

commenting for vkdt as i've been out of the loop for darktable for quite a while. i use both rawspeed/c++ and rawler/rust as backends for raw loading modules, from a c context. speaking for myself only, i will use any programming language if i can get access to excellent functionality (i suppose except python, but likely even that).

what i like really a lot about rawler is the access to exif/metadata from the same library.

so essentially i'm saying i would never stop a developer choosing his favourite tool. i have a clear preference to work with simpler tools because i don't understand complicated programming languages. c++ has clearly crossed a boundary here for me sometime in the last decades. in that sense i'm more likely to work with rust than c++.

[LebedevRI]

so essentially i'm saying i would never stop a developer choosing his favourite tool.

That's my problem i guess, trying to be on the providing end of things, when there's some,
sometimes unspecified and uninferrable expectations, really doesn't provide much wiggle room.
(If this/things were solely up to me, the guidelines would be different.)

[hanatos]

maybe to bring up a few points to consider:

interfacing rust to c/c++ is easy. it's not necessarily pretty, but there are no performance concerns and the implementation effort to access rust data from c is minimal, here is the vkdt interface to rawler, as an example.

as an application developer i'm usually busy doing all sorts of things except keeping up with changing interfaces of libraries i use (you will understand if you tried to develop against say libavcodec over a period of time). this for instance meant that at some point earlier this year i updated the rawspeed commit used in my build system and as a consequence had to disable the github nightly package build with rawspeed config because the ci ubuntu was too old to provide up-to-date-enough llvm. i suppose it would have been possible to fix, or maybe by now even the new LTS ubuntu made it into the ci. just to give you an idea of the amount of time i can spend on this.. the build is still disabled.

i really appreciate the rust package system. it might pull in a lot of things and by default tends to produce huge binaries. but it often just works using old system rustc/cargo and will pull in everything it needs transparently.

there is a notion of rewrites not producing better code just like that. new code will have new bugs. i can see how going forward with a sane subset of c++ functionality might be a rational decision. this seems to be more a business rationale though, i find that an occasional rewrite increases code quality by removing unnecessary parts and by generally starting over with a deeper understanding of the problem space. but also i personally sympathise with everyone rewriting software to remove c++, so feel free to ignore me as a biased opinion (i'm currently changing ui toolkits so i don't have to use c++ here).

from what i recall from the darktable discussion about input libraries it was very much driven by pragmatic need. i can't tell whether anyone would write the rust/c wrapper code there, but the main arguments for adopting a library were more format support than anything else (say development practices/code quality/speed/language).

[TurboGit]

As far as integrating w/ darktable or vkdt (known clients to me), I'll let others comment. @TurboGit @hanatos

Since you asked me the only move that could motivate me more is toward using Ada.

C++ is a complete mess I agree, but Rust is just the new kid on the block and will be replaced by something better at some point (as we've seen those last years where predictors are selling us always better tools to reduce the cost of development - if I could count all the gains we should have made the cost of software should be negative today :).

Most language are just not designed, they've made to get some market share and to sell us all the needed toolset (editor, debugger, ...).

C is sadly wrong, low level, error prone but all devs know it... The choice is not technical, sad but true.

[LebedevRI]

@TurboGit i very much agree with you on all of these points.

I do NOT think that rust is The Answer,
i'm really not a RIIR person,
and i'm certainly not a rust missionary.
I have not written a single line of rust as of this point in time.

i do sincerely hope that it is just a stepping stone
towards something better, i just don't feel like
being stuck on an sinking ship,
because usually codebases do that because the cost
of migration is too high, so they just continue with
sunk cost fallacy of trying to patch all of the holes in sinking ship,
and i really don't want to do that.

As i've stated previously, i would still like to explore Halide,
but that would be, uh, rather problematic from distribution support point...

[pitbuster]

If this is still going on, I would be willing to help, I have used Rust at work for quite some time and also had C++ experience from my previous job :)

[aurelienpierre]

Go for Rust.

C/C++ are not dummy-proof enough to entrust open-source enthusiasts with them, and code portability is still a sad joke. They are great when you want to write fast bugs, race conditions and leak memory.

Rust has built-in memory safety and concurrency management, with little to none of the typical performance penalty associated with those. Plus an internal package manager that does not rely on bloody Linux distros.

I believe in protecting projects from their contributors. That's not C/C++. Granted, moving away from them only solves thread and memory safety, not software architecture or code quality (or lack thereof).