On 13.03.2015 08:43, Markus Schaber wrote:
>
> Hi,
>
>
>
> I just wanted to throw „Rust“ into the discussion.
>
>
>
> Rust seems to have a very expressive type model, which allows to
> handle most of the memory management automatically and compile-time-safe.
>
>
>
> It also allows to go very “low level” / “lean” (they even wrote
> bootloaders and POC Kernels with it).
>
>
>
> It is compiled to native code, and has rather good C interfacing
> capabilities.
>
>
>
>
>
> On the other hand, I tend to oppose C++. While it feels “natural” to
> “upgrade” from C to C++, the mere complexity of that language makes it
> very difficult, at least if a project does not restrict itself to a
> very well thought, strictly defined subset.
>
>
>
> Grüße,
>
> Markus
>
>
>
> *Von:*Erik Huelsmann [mailto:ehuels_at_gmail.com]
> *Gesendet:* Freitag, 6. März 2015 22:37
> *An:* Julian Foad
> *Cc:* Branko Čibej; dev_at_subversion.apache.org
> *Betreff:* Re: Convenient array & hash iterators & accessors
>
>
>
>
>
> > It would make sense to design type-safe, light-weight container and
> > iterator template wrappers around the APR structures if we
> decided to
> > write code in C++. Since we're not, "explicit is better than
> > implicit".
>
> I understand the point. I note that "explicit" is not a binary
> quality: there are degrees of it.
>
> I suppose I want to be writing in a higher level language. Maybe I
> should just go ahead and really do so.
>
>
>
> Exactly. There's been talk about doing so for much too long without
> action (other than attempts - including my own) to find a way to
> "upgrade" C to something less verbose and more expressive.
>
>
>
> I've been long thinking that there are specific areas which are
> more-or-less stand-alone, might be a good place to start this
> strategy. One place like that might qualify is the piece of code that
> deduces the eligeable revisions in merge tracking. That's the code I'm
> thinking you're now working in?
>
>
>
> What kind of language were you thinking about? One of the languages
> that came to mind is 'lua' which seems to have a pretty strong focus
> on being integratable with C code. For lua there are also tools to
> embed the compiled bytecode in a C library so the entire higherlevel
> language can be fully encapsulated inside our libraries.
>
Why not Groovy (soon to be incubating at the ASF). That way we keep
things in the family, and we're likely to eventually move everything to
a JVM-based implementation instead of this silly native-compiled, last
century stuff.
-- Brane
Received on 2015-03-13 08:55:30 CET