pdfernhout at kurtz-fernhout.com
Wed Nov 29 15:38:55 UTC 2017
On 28.11.2017 04:25, Eyal Rozenberg wrote:
> On 11/28/17 5:15 AM, Paul Fernhout wrote:
>> Thunderbird needs to be rewritten essentially from scratch, with a
>> core ideally in a more type-safe language than C/C++ while leveraging
>> existing libraries and tools (such as using Firefox Quantum as a
>> client via web protocols and not via embedding).
> Umm, C and C++ are completely different languages,
True, but both are typically used in codebases of that sort; for
Here is a good recent debate by many developers on the pros and cons of
both C and C++:
"Why ESR Hates C++, Respects Java, and Thinks Go (But Not Rust) Will
Replace C "
> and it's weird that
> you discuss them together as being non-type-safe. AFAICR C++ is quite
> type-safe unless you specifically circumvent type checks.
Since either C or C++ support writing outside the bounds of arrays,
freeing memory twice, and casting between structures of different sizes,
there are whole host of security bugs likely in C and C++ applications
Smalltalk. I called that "type safety" but perhaps "memory safety" would
have been a better choice. Further, manual memory management is
typically a source of about one third of C and C++ bugs -- and manual
memory management also takes up lots of developer time that otherwise
could be focused on other areas. It's true that tools can help find
those unsafe memory situations or can even provide conservative garbage
collection, but in practice those tools and libraries are often not used
for whatever reasons and also have their own weaknesses.
> I'm not commenting to start an argument on language merit, though,
As with the Slashdot discussion linked above, both C and C++ have their
defenders. For latency-critical or long-running applications there is
certainly a case to be made for manual memory management and
pre-allocation of all data. For time critical applications, a case can
be made for writing close to the metal. If you have to do those things,
C makes sense -- and at some point for a complex application you can
argue C++ provides some good abstractions or useful libraries worth the
extra complexity of the C++ language over C.
But none of those cases apply for Thunderbird as a desktop application
-- or, perhaps in the future, a communications server for messages
between people generally tolerating high latency compared to real-time
Those cases (performance, latency) might apply in some areas of a web
browser. But in 2017, the whole idea of embedding a complex web browser
written in a low-level language directly in your application in such a
way that you need to compile and maintain the web browser code yourself
is just ... (looking for a polite word) ... ill-advised. And even
Mozilla is trying to get away from C and C++ with Rust.
One alternative is to have an application be a local web server that
talks to a web browser. Such a server can be wrapped in Electron or
something similar if you really want to bundle a web browser with your
application. That different relationship to the web browser is the
architectural shift which makes most of the existing Thunderbird
codebase obsolete (whatever it is written in). And that shift
essentially the reason I am writing this email in Roundcube via a web
browser on a cheap Chromebook on my couch and not Thunderbird on a big
desktop in my office.
> but rather to ask - is this your opinion or has there been a decision
> move away from C++ as a core language for a future TB?
Just my personal opinion.
But you can find others saying the same. Here is a comment from 2007(!),
for example from Benjamin Smedberg:
"I have a fairly high tolerance for coding pain, and I have found the
mailnews codebase very difficult to navigate and hack effectively. There
are multiple causes for this, that I am going to list in no particular
order. ... 1) Poor Model-View-Controller separation. ... 2) Pervasive
And agreement by Jean-Marc Desperrier: "I think the problem mostly is a
huge amount of very bad C++, very verbose and inefficient. I always felt
reading the mailnews codebase that at the start of the project it
received all the worse coders so that they would not disturb the
browser code. [After providing an example of such poorly written code] I
could submit a patch for the above, but what would be the point when
what is really needed is a full rewrite ? And in that rewrite, we could
as well think about reducing the amount of C++ code in favor of js, but
the basic problem is not C++, it's bad code, and it could just as well
be bad js code than bad C++ code."
Ok, that was ten years ago, but has that much changed? Maybe it has as
regards just Thunderbird?
And even if it has, then consider this next point on the consequences of
having an embedded web browser written in C and C++.
Here is one big reason why it is so hard to engage developers with the
existing C and C++ codebase for Thunderbird:
"The source code requires 3.6GB of free space or more and additionally
5GB or more for default build. ... Building can take a significant
amount of time, depending on your system, OS, and chosen build options.
Linux builds on a fast box may take under 15 minutes, but Windows builds
on a slow box may take several hours. ... [After making changes] Then
just re-run the mach command above. This will only recompile files that
changed, but it's still a long haul."
And nowadays I feel waiting ten seconds or more to test changes to a
large TypeScript application is painful...
Having to deal with this accidental complexity and testing delays from a
legacy of embedding low-level complex code of a web browser in
Thunderbird is all a distraction from Thunderbird developers working on
better ways to help people communicate. It's all massive technical debt.
That's the big challenge of Thunderbird going forward -- how to deal
with that technical debt for each part (whether by minor maintenance,
progressive refactoring, and/or rewriting) -- especially considering the
need to now *unembed* a legacy Firefox web browser component from the
Thunderbird codebase. And the use of a low-level-oriented language like
C or C++ with poor guarantees for memory safety where it is no longer
needed (if it ever was) in Thunderbird is another part of that technical
debt in my opinion.
--Paul Fernhout (pdfernhout.net)
"The biggest challenge of the 21st century is the irony of technologies
of abundance in the hands of those still thinking in terms of scarcity."
More information about the tb-planning