emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Internationalize Emacs's messages (swahili)


From: Andy Moreton
Subject: Re: Internationalize Emacs's messages (swahili)
Date: Wed, 30 Dec 2020 14:00:22 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (windows-nt)

On Tue 29 Dec 2020, Richard Stallman wrote:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > Rust is able to generate C dynamic library, so we can link with it.
>
> I am interested in understanding what that means.  Could you describe
> in 10-20 lines what it means?  What is the input, what is the output,
> and what software does the conversion?

The suggestion above is to build a shared library (.so, .dll, etc), but
written in Rust instead of C. That requires a Rust toochain to compile
the code.

>   > You can take a look at librsvg[1] (from project GNOME). A SVG renderer
>   > powered by Rust(and it's also used by Emacs currently)
>
> That is not something I can feasibly do -- it would take an hour if
> not several hours for me to learn the basic points.  So I hope
> you will describe what I need to know in a brief summary.

Rust is a language that fits the same space as C does: a systems
language with minimal runtime support needed (so ok for embedded
targets). It has good interop with C, so Rust code and C code can call
each other directly without any complicated FFI or marshalling.

For the example SVG library, that allowed the authors to rewrite parts
of the C code in Rust for better type safety (to reduce the number of
security critical bugs) without changing the library ABI.

> But I think it would be a nuisance to make this a separate library.
> It should be packaged with the support for getopt, and written in C so
> we (the GNU Project) can easily maintain it.
>
> From what I hear, Rust has a fundamental practical flaw: it is not
> intended to be stable.  The developers want to keep changing it.
> That's fine, in principle, but until they decided to make it stable,
> we should write important code in some other language.

The language core is stable now, and current work is mostly on
stabilising libraries. Rust is a promising language, and while not yet
completely stable the pace of change is slowing as it matures. Many
projects are using Rust in production code.

Adding another toolchain to the dependencies for a project is a large
change. In addition, the Rust toolchains do not (yet) support many of
the targets that are supported by C toolchains.

    AndyM




reply via email to

[Prev in Thread] Current Thread [Next in Thread]