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:ehu...@gmail.com] > *Gesendet:* Freitag, 6. März 2015 22:37 > *An:* Julian Foad > *Cc:* Branko Čibej; dev@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
