[vlc-devel] Rust work (discussion)

Lyndon Brown jnqnfe at gmail.com
Tue Sep 22 07:47:28 CEST 2020


On Sun, 2020-09-20 at 13:44 +0200, Alexandre Janniaux wrote:
> Hi,
> 
> I was going to write the same thing as Kartik Ohri but since
> he brought all the pivotal arguments here I'll just details
> some of the points.
> 
> > As I write this, I recognise that I'm very tired (long day), so I
> > hope
> > I'm not expressing myself too poorly here. I merely mean to raise
> > awareness of the existence of this project I started, not come
> > across
> > as arrogant or seeking praise or whatever. Sure, I could hold off
> > submitting it to reassess tomorrow, but I hope you guys will just
> > take
> > my intentions in good faith... (And I hope the team takes no
> > offence to
> > my not having engaged with them earlier about this previously
> > secret
> > project that I took it upon myself to start working on).
> 
> This seems relatively clear to me, I hope you won't take
> what I say as personal attack too. Some arguments that I
> bring here are explicitly designed to highlight some
> questions but might be a bit frustrating.

I've not take this, nor any of the other replies to this discussion as
personal attacks, don't worry. :)

> First, I don't think we want a full rust initiative. Despite
> my wish to have more rust, this is quite the same reason as
> we've not being rewriting VLC in C++. Many people here are
> excellent core developers, most of them are usually the only
> ones knowing some part of the software with enough depth to
> keep it clean and know what have been done on it. I don't
> think targetting a different developer base by switching to
> Rust will bring more value than what those developers were
> bringing to the project. Additionnally if you see it from the
> perspective of many people that actually did that in their
> companies (you have many testimony on video platforms), doing
> such enforced journey to Rust is likely to bring the worst
> experience possible for those developers, even those who were
> ready to switch, meaning that you would just reinforce
> resistance against using Rust. And the question can be asked,
> why Rust against all the recent language bringing such new
> features? Why not Swift for example, which is majoritarily
> pushed by a company having less incertain future than Rust?
> Well, I agree that Rust also has different support from
> different other companies than Mozilla but this is not a
> random question. If you take C and C++, there are a huge
> amount of support from different companies, most of them
> also being probably the more stable/rich of this world.

In terms of the set of developers and their existing knowledge, they
and their knowledge are of course invaluable. I certainly do not wish
for a move to Rust to be pushing people out because they've not learnt
Rust and for one reason or other are unable or unwilling to. I would
hope that the core team are perfectly skilled, willing and able enough
to get to grips with and embrace Rust if they've not already and agree
that Rust is very much a language worth learning and making use of for
VLC. Of course aside from the language difference, fundamentally the
work I've been undertaking thus far makes as little change as possible
to the design and functionality of the existing code, so it's not as
though existing understanding of how things work would suddenly be
obsolete.

My desire for a switch to Rust for VLC does not involve wanting to
target a different developer base, if by which you mean replacing or
attracting new developers. Nor is it based upon my personal respective
knowledge or skill in Rust vs. C. My desire for Rust stems primarily
from the significant benefits for security that I recognise a modern
language like Rust, and in particular Rust, has over C. VLC obviously
is a very large and complex codebase, with a lot of code handling all
sorts of complex input data, both from local files and network data
streams. It is a prime candidate for benefiting from Rust in terms of
security. VLC is my preferred video player, and I'd personally feel
much happier after such a move. Ideally I want my kernel and entire
userland switched over.

With C++, aside from obviously OO, which is great in some ways and
horrendous in others, it really doesn't offer very much at all over C
to make a switch to C++ worthwhile. I'm not at all surprised that VLC
has not been converted to C++. Rust by comparison is an enormous leap
forwards from C, as you're clearly already aware.

Why Rust in particular vs. say Swift or other modern languages? That's
a perfectly good question. My feelings personally... Although I've had
a little experience with both C# and Java (not that they're very
modern), I've never been partial to garbage collection based languages,
always preferring C/C++. I took a little interest when Go came out, but
not enough to get around to learn it, and then discovered that it was
yet another garbage collection based language, and well, meh, and
besides, there was Rust. (I have heard that they've since hacked in
support to do without that, but still, the interest is just not there
for me, Rust stole my attention). With Swift, it's not really caught my
attention and, well, it's produced and supported by Apple. I have mixed
feelings about Apple; I have great concerns of Apple's priorities with
Swift with respect to caring about platforms other than their own, and
I haven't gotten the impression of strong community support unlike
Rust. Swift of course replaces Objective-C, which is, well, meh, and
unsurprisingly not very popular afaik, so not a great start as
essentially an Apple-developer targetted Obj-C replacement. And then of
course there's the language differences... How does Switch even compare
to Rust and Rust's safety features. Honestly I'm so lacking in interest
in Swift right now I can't really be bothered to try to find out
(though it's also very late and I should go to bed, so that's a big
part of it). Rust has huge community support, and fantastic safety
features especially it's innovative borrow checker, as you know. It's a
system programming language rather than just another garbage collection
based userspace language, which I feel is a positive thing, and aimed
at C/C++ programmers. Upon discovering Rust, I felt that, *yes*,
finally, there's a new non-garbage-collection-based language, a system
one at that, one that could actually viably replace use of C/C++, and
it's *awesome*. I feel that the community have been strongly embracing
it; that the notable projects and companies that are showing interest
in exploring use of it speaks volumes. I feel it stands head and
shoulders above these alternatives. Is there really any strong argument
for something else? (Am I risking opening a bag of worms in asking
that? wait, I take it back, it's hypothetical, hypothetical...). :p

> With these arguments, having a little space to write rust in
> the project that won't interfere to much with the whole
> direction of the project seems a fair short term trade, and
> it can lead to better design policy. Maybe we can decide that
> new access/demux must be written in a safe language in the
> future for example.

Granted.

> Then, the second major point which has also been raised by
> Kartik Ohri, we have a lot of pending work. It's not just
> a patch or two. I probably have something like a hundred
> branch, Thomas and Steve probably more. My work account for
> something like two years of day-to-day work on VLC. Rewriting
> VLC in Rust seems like a huge toll on most contributors,
> while bringing low value on the majority of the codebase that
> won't need it. It's also a blocking quantum tunnelling effect
> that is generally prohibited in most engineering approach,
> because if we reach the full rust state and it doesn't fit
> well the project, we either trash everything in the project
> or in the work being done which can only be frustrating and
> is a much greater loss of time than having multiple projects
> in parallel. The current approach is specifically designed
> to be an incremental one, in which we can first experiment on
> a few modules, highlight gotcha, setup buildsystem and define
> a long term target that fit most developers. Basically it
> targets the module system instead of the core. A more
> incremental approach wrt. the core would probably involve
> a Rust part and a C part compiled together, but though it is
> magnitude much more complex than a full rust approach, it's
> also inclusive and allow to keep a lot of the history of the
> current project during the development. And don't misinterpret,
> keep in mind that my No.1 language in which I'd like to write
> everything is actually Rust. So while you see a transitory
> binding as redundant, I see it as actually allowing the
> transition to have any chance in the future to happen.
> Another approach could be to use a C -> Rust converter too,
> which is nowadays sufficiently evolved to idiomatize a lot
> of code that is «well-written» (according to the tool). What
> is left could then be converted by hand incrementally
> afterwards, but it would require first that everybody agrees
> to write Rust code only. I don't think you'll ever see this
> to be honest. People _not_ liking Rust is a thing, just like
> every other languages.

Yes I can appreciate that people are going to have a lot of unfinished
work, which is going to be a problem.

I think that the codebase can broadly benefit from Rust in numerous
ways, for instance in the differences of having built in array index
bounds checks; improvements relating to catching of overflows in
integer calculations; the simplicity of passing around slices which
bundle the length; enums that can hold values; the ability to return
tuples of data; (mod) namespace organisation; etc; etc, bolstering both
stability and security as well as improving productivity. So I feel
there are strong arguments in favour of doing more than stopping at
selective conversions in the short term.

Rust is specifically targetted at C/C++ programmers. I haven't gotten
any impression myself of it not being a good fit for VLC. I would not
expect such a situation to occur, though of course while I've gained a
lot of useful insight into various areas of the codebase, the codebase
is vast and there is still much where my knowledge is lacking. But
again, it's a language aimed at C/C++ guys, and combined with my
experience with it, I don't see it being deemed unsuitable.

Of course I appreciate that switching over to a new language is not
something to be done in a whim.

> Please note also that in it's current form, the plugin system
> requires symbols from VLC core to be exported to plugins.
> Rust having no stable ABI, and plugins being potentially
> written in different languages, there is a need for exporting
> a C API even from libvlccore, so you actually need the work
> being done here either way.

Afaik the plugins are largely C with a few instances of C++ and Obj-C.
The plan, as previously mentioned would be for all plugins to be Rust,
talking to existing external 3rd-party libraries (like the PulseAudio
system library) as currently done (via a binding) where applicable. If
there is some plugin where it is just not viable to convert the bulk of
the plugin to Rust, we'd have to explore solutions on a case by case
basis. Hopefully there are no such plugins (I don't have any in mind).
I would hope it turn out to be the case that we entirely avoid any need
for exporting the core as a C interface to plugins at all.

> And finally, more than just being difficult to integrate the
> work as a whole in VLC, rewriting the core in Rust looks to
> me like a _bad_ idea with regards to the targets of the
> project. Rust has no support for armv7 iOS/aarch64 appleTV,
> some other points of supports are very limited. Porting Rust
> to new platforms is a certain amount of work (we've done it)
> but is not actually the job of VLC at first, and we have
> quite limited resources. While I agree that Rust would bring
> a productivity boost for Rust developers in the project, it
> is actually much easier to rely on the C code being easily
> ported and progressively enable plugins than porting the
> whole compiler to the target and maintaining it.

I'm sure than the vast majority of VLC users are already covered by
existing Rust platform support. If a platform is not then of course the
two most obvious reasons are either it's too old and little used for
there to be the incentive, in which case it's fair to question whether
VLC should care either, or it's so new, and the community have not
gotten around to it or lack incentive because it's not popular. Rust
has a whole worldwide community behind it, incorporating both
individuals and big well funded organisations. I'd certainly not expect
VLC/VideoLan to be putting resources into adding support for one or
more platforms to Rust.

> That being said, the fact that you wrote a lot of the API
> in Rust can be hugely beneficial to the design of the current
> vlccore-rs API.
> 
> I hope to not appear harsh on my opinion, I'm actually quite
> impressed by the amount of work you must have done. I mostly
> feel that your approach is not incremental enough and should
> better match the development process -- including the other
> non-rust developers -- than what you suggest, but that's
> actually quite a good sign of the interest of Rust within the
> VLC community so I'm quite happy of what you did.

No not harsh at all, you're raising perfectly valid and understandable
points and I take no issue at all with the way you've done so. :)

I do appreciate the positives of the incremental approach and concerns
doing otherwise.

> Regards,
> --
> Alexandre Janniaux
> Videolabs
> 
> On Sun, Sep 20, 2020 at 04:25:13AM +0100, Lyndon Brown wrote:
> > Hi all,
> > 
> > There have been at least two blocks of work submitted recently (by
> > others) with an aim of starting to enable development of plugins in
> > Rust. I feel that I should speak up at this time to create open
> > awareness in those working on this of my own efforts in bringing
> > Rust
> > to VLC, or is that VLC to Rust...
> > 
> > (Thus far only JBK is aware, who I only just mentioned it to a few
> > weeks ago, and even he does not actually know the extent of it).
> > 
> > Specifically, a years-old project to achieve a complete conversion
> > of
> > the whole VLC codebase (to Rust).
> > 
> > My intention here is really not to trash/disparage/whatever this
> > other
> > effort - it would be great to get Rust into VLC asap - nor seek
> > praise
> > for the previously undisclosed effort I've put in myself; simply
> > put, I
> > feel it prudent at this point to raise awareness that there are in
> > fact
> > now two projects running in parallel, with entirely different
> > objectives as to bringing Rust to VLC, and suggest that perhaps,
> > before
> > much more effort is put into the the Rust<=>C compatibility layer /
> > interface project, it might be a good idea at this stage to give
> > fresh
> > thought to how sensible a use of resources that is. If we can
> > assume
> > that going full Rust is a reasonable long term goal of VLC, then
> > when
> > that occurs, the compatibility layer being worked on now is just
> > going
> > to be junked as redundant. Please understand that it makes no
> > difference to my own project if this other one continues (I don't
> > want
> > anyone to mistakenly think that I'm writing this out of feeling
> > like my
> > work is threatened or something), and I can appreciate the
> > disappointment felt if your hard work is dismissed; I'm only
> > writing
> > this because I worry that the significant effort of putting
> > together
> > this Rust<=>C layer for use in the short term (until full Rust) and
> > additionally the effort of maintaining it, is just going to turn
> > out to
> > not have been worth it. Especially given the possibility that given
> > the
> > existence of my project, achievement of a fully Rust VLC might
> > actually
> > not be quite as far off from reality as many might have guessed
> > (depending upon acceptance by the team, and how fast/slow my
> > project
> > progresses of course). If/when VLC goes full Rust, if we even then
> > bother having any Rust<=>C compatibility layer, it would naturally
> > be
> > one flipped on it's head from that being currently worked on (to
> > allow
> > C code to talk to the Rust library), so as I say, the one being
> > worked
> > on now would be junked. Is it honestly worth the effort to continue
> > it?
> > 
> > I might as well open up some information about my own project...
> > 
> > My work on this started back in late 2016, when, being a big fan of
> > VLC
> > and Rust; thinking VLC to be a great example of something that
> > could
> > benefit a lot from Rust; of Rust being rather concretely
> > establishing
> > itself as the replacement for C/C++; and wanting a project both to
> > learn Rust with and achieve a useful Rust conversion with, I
> > thought
> > I'd throw myself at taking a stab at a complete conversion (without
> > any
> > prior knowledge of the codebase), and see where that took me.
> > 
> > This was a private project, with the intention only of informing
> > the
> > team later on if I managed to achieve enough success and progress
> > with
> > it to feel ready to do so, hoping that they would welcome the
> > effort,
> > and eventually agree to take it on board to replace the C codebase.
> > 
> > I put a *lot* of effort into it here and there over the next couple
> > of
> > years (entirely unfunded), and made some decent progress, but a
> > huge
> > amount of work remains to be done.
> > 
> >  - After reorganising the directory structures and renaming the
> > files
> > (extensions), I got all of the public and private header contents
> > merged into suitable locations, and reorganised some bits and
> > pieces.
> >  - I manually applied the most basic syntax changes across the
> > entire
> > libvlccore and libvlc libraries, and converted the VLC binaries. (I
> > held off making the syntax change to the plugins to make rebasing
> > easier in the short term).
> >  - I got the entire block of fourcc data, chroma
> > fallback/descriptions
> > stuff, including preprocessor, all converted fully into its own
> > crate
> > (necessary).
> >  - I got a whole bunch of other trivial components of the core
> > fully
> > converted irrc, such as esformat stuff, though I can't recall how
> > much.
> >  - I got important chunks of the core initialisation stuff done,
> > such
> > as command line argument processing, along with logging and
> > including
> > help output I seem to recall.
> >  - I got the plugin interface and loading system built and working,
> > successfully loading and putting to use a converted logger plugin.
> >  - I got the clock converted.
> >  - I think I had the plugin cache handling done.
> >  - I converted a handful of easy plugins.
> >  - I hand crafted a complete pair of 'sys' and 'binding' crates for
> > talking to PulseAudio from Rust, which I made public and continue
> > to
> > maintain, and converted the PulseAudio Aout plugin to use it.
> >  - Maybe more that I'm forgetting.
> >  - I also spun off hundreds of commits of work for the C codebase,
> > most
> > of which I've not yet actually submitted, but I've rebased in the
> > past
> > few weeks to do so and have made a start with some of the small
> > items.
> > 
> > All while regularly rebasing on top of new work being pushed
> > everyday
> > to the official codebase (I wasn't creating a new Rust codebase
> > from
> > scratch, this was a translation).
> > 
> > I thus had it in a state where I could get VLC to load, correctly
> > process command line arguments, including those from plugins,
> > output
> > help when requested, locate and load plugins, get a logger plugin
> > loaded and connected up, and start logging output to it. Although
> > unimpressive in the grand picture, still something, and it took a
> > lot
> > of effort just to get that far.
> > 
> > Where I left things off:
> >  - I was struggling with certain aspects of the playlist code, and
> > was
> > pleased to learn that even the team did not actually really
> > understand
> > it properly, when it was replaced entirely last year, and I'm eager
> > to
> > get back to this project and get that converted now that we have
> > what
> > looks to be a sane and understandable playlist implementation. It
> > will
> > help tremendously. (and btw guys, there was one part of the new
> > solution, possibly the randomiser, I forget now, that I thought was
> > just beautiful in it's elegance when I took a look last year -
> > awesome!).
> >  - I'd done a bunch of work on the core IO pipeline, and was
> > getting
> > somewhat close I think to achieving basic flow of raw audio data
> > pumping through it. I'm eager to get back to it and achieve that.
> > 
> > I've unfortunately not had the luxury of having been able to work
> > on it
> > for more than a year now due to getting side tracked with other
> > stuff,
> > but considering the great effort already put in, I'm determined to
> > not
> > just let it go to waste if it can be avoided. I'm eager to get back
> > to
> > it when I can, (though at the same time I face significant pressure
> > to
> > get an income flowing in).
> > 
> > I'm sure that a question in the minds of some at this point might
> > be to
> > ask about making my effort thus far public and getting others on
> > board
> > to continue the work or collaborate on it with me. While this is
> > ultimately what will have to happen, since there's little chance
> > I'd
> > manage to get the entire suite of plugins done myself being
> > pragmatic,
> > and I'd welcome it then, I've remained reluctant to open it up
> > until
> > I've at least got the majority of the core done and maybe a little
> > portion of useful output working - I'd just kinda like the
> > satisfaction
> > of that at least being a personal achievement first before others
> > step
> > in to help cover the remaining plugins.
> > 
> > Another anticipated question might be how I envisioned the full
> > Rust
> > solution interacting with other languages:
> >  - As stated, the in-tree binaries, along with the entire libvlc
> > and
> > libvlccore would be entirely converted to Rust.
> >  - At the back end, all plugins would be entirely converted, but
> > would
> > continue to interface with existing 3rd-party C libraries (like
> > PulseAudio) where applicable and necessary, via thin 'sys' and/or
> > 'binding' crates, creating those as necessary, as I did for
> > PulseAudio,
> > though some could be switched to Rust based alternatives, and an
> > ideal
> > later extension to the project would be to get as many 3rd-party
> > libraries also converted as possible to aim for as much userspace
> > code
> > being Rust as possible. 3rd-party plugins would just have to get
> > onboard with Rust, since it would not be worthwhile I expect to
> > additionally try to provide a C API for them; with them either
> > fully
> > converting, or splitting their code up into a Rust plugin talking
> > to a
> > C library. I would not expect this to be a unreasonable.
> >  - On the front end, I have some awareness that there are other
> > users
> > of libvlc than the actual VLC binaries, but little knowledge of
> > them,
> > and am not in a good position to assess just how much of libvlc
> > and/or
> > core would need to be exposed to them to continue to support them
> > via a
> > C interface; how easily they might just learn to talk to Rust
> > instead;
> > or if it's even worth continuing to support them considering the
> > huge
> > benefits of Rust in contrast. Essentially this remains somewhat
> > unanswered, but I find the benefits of Rust compelling enough
> > reason to
> > push ahead regardless of what would need to be done.
> > 
> > As I write this, I recognise that I'm very tired (long day), so I
> > hope
> > I'm not expressing myself too poorly here. I merely mean to raise
> > awareness of the existence of this project I started, not come
> > across
> > as arrogant or seeking praise or whatever. Sure, I could hold off
> > submitting it to reassess tomorrow, but I hope you guys will just
> > take
> > my intentions in good faith... (And I hope the team takes no
> > offence to
> > my not having engaged with them earlier about this previously
> > secret
> > project that I took it upon myself to start working on).
> > 
> > Regards,
> > Lyndon
> > 
> > _______________________________________________
> > vlc-devel mailing list
> > To unsubscribe or modify your subscription options:
> > https://mailman.videolan.org/listinfo/vlc-devel
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel



More information about the vlc-devel mailing list