On 13.03.2015 10:05, Bert Huijben wrote: > >> -----Original Message----- >> From: Branko Čibej [mailto:br...@wandisco.com] >> Sent: vrijdag 13 maart 2015 08:53 >> To: dev@subversion.apache.org >> Subject: Re: AW: Convenient array & hash iterators & accessors >> >> 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. > I wouldn't have a problem with requiring a small bytecode interpreter/stack > machine inside libsvn_*, but a full JVM is certainly not something that can > be embedded in every application. That changes the entire process > requirements. > > I don't think multiple JVMs can run in the same process (especially different > versions), and attaching to an existing VM introduces different problems. In > AnkhSVN I run Subversion inside a process that potentially has multiple .Net > runtimes loaded, and until Visual Studio is redesigned into a 64 bit process > somewhere in the far future I certainly can't just load a JVM in the process. > > TortoiseSVN has similar (if not stricter) limitations, but it is already > multi process to avoid having to integrate everything into every process. > (Not sure how much of Subversion they still load in every process that uses > explorer infrastructure) > > I don't see a problem using something internally, and still providing a 100% > C compatible api... > > A good subset of C++ to introduce more type safety would be a good option... > But I can't think of a good way to define the subset and really limit us to > such a subset... > And using more and more C++ will shrink the pool of developers that would be > able to join. > > By developing our own macro world in C we would have the same problem > though...
The problem (or "problem") with C++ is that it's *extremely* hard to code things correctly in an exception-safe manner. Otherwise I'd be all for using it, these days (especially with C++11) you have a language that's in some ways horrible to use, but when used correctly can provide huge benefits. But it takes years of single-minded language-lawyerish hacking to get to the "used correctly" phase. In the past I'd thought about embedding Python into our sources, but Python still (after 20 years ...) depends on a global interpreter lock which pretty much kills any chance of lockless thread-safe code. These days, I suppose we'd be looking at something like Go, which can be linked with C/C++ and also natively export functions that can be called from C/C++. -- Brane
