Russel Winder speaks about C++ conferences, C++17, Go, D and Rust
Last week our team participated in the ACCU conference in Bristol, which was extremely interesting. Thanks everyone who visited our booth, hope you’ve learned a couple of useful tips from us or maybe even won a license ;)
In this interview we speak with ACCU 2016 Chair – Russel Winder. Russel is an independent consultant, analyst, author, trainer and an expert on Java, C++, Groovy, Scala, Python, D, Go, Gradle, SCons, and not only:
I started out life as a theoretical high energy particle physicist – think doing the theory behind all the stuff being researched on at CERN’s LHC. However I became more interested in the programming, development of programs, and build of programs than the physics so taught myself Algol68, Pascal, and C, and got a job as a UNIX systems programmer.
My interest in programming, development, environments and build drew me back into academia where I spent 17 years teaching and researching concurrent and parallel programming languages and human–computer interaction. For various reasons I left academia and got involved in a number of startups. None of these really succeeded, so I failed to become a billionaire. Nor even at all rich. As well as the startups, I have been an independent consultant, analyst, author, expert witness and trainer. I retain my interest in concurrency and parallelism. And build.
Over the last 12 years I have been involved with the Groovy community, created Gant, that led other to create Gradle, worked with GroovyFX, and since it’s inception in 2008 GPars. I also work with SCons, and now GStreamer. I present regularly at conferences, for example DevoxxUK, JAXLondon, Greach, Gr8Conf, Groovy and Graisl eXchange, PyCon UK, and, of course, ACCU.
GitHub: russel
Site: russel.org.uk
Anastasia: Hello Russel, thanks for chatting with us! Let’s start with ACCU 2016. How do you feel about it? What has changed compared to previous sessions?
Russel: In a sense, this year’s ACCU conference is unchanged compared to previous ones: it is four days of one keynote and five tracks with (uniquely as far as I know) 90 minute sessions, with some of the sessions being sequences of 15 minute sessions. There is a day of full day workshops prior to the conference itself. Also, there is the one hour of lightning talks on each of the first three days of the conference.
Of course this year is unique in that it is the only ACCU conference in 2016!
Anastasia: What makes ACCU conference unique in your opinion, in comparison with other C++ conferences like CppCon, C++Now, Meeting C++ and so on?
Russel: I think the 90 minute sessions are the key to why ACCU feels and is different. Some sessions are full of short 15 minute presentations (or whatever), most of the 90 minute sessions are 90 minutes of presentation and discussion, discussion, or mini-workshops; there are many types of things going on in the hour and a half.
As for the C and C++ angle: CppCon C++Now, and Meeting C++ are conferences dedicated to C++, ACCU conferences, whilst having a strong C and C++ core (appropriate given the C and C++ history of the ACCU organization and conference) are really focused on excellence and professionalism in software development. Also CppCon and C++Now are in the USA and Meeting C++ in Berlin, whilst ACCU is in UK.
Anastasia: What projects are you working on as a developer? What programming languages do you use?
Russel: I have got a number of projects “on the go” just now.
Me TV is a DVB viewer with EPG support using GTK+ and GStreamer. The code (a mix of C and C++) needed a serious revamp, and I decided actually a full rewrite was required. I thought about using Rust but the library support for DVB is not really there yet. I then though about using D, but when I started the rewrite there were issues that stopped it being feasible. After having done a lot of work things have changed, and D would be a really good language to have written this. Indeed I may restart using D. For now though the rewrite is using C++14. Using CLion as IDE.
The work on Me TV highlighted that the GStreamer support for DVB needed to reworking. I am almost certainly going to do a rewrite of the dvbsrc plugin using libdvbv5.
I am working on a Java 8 version of GPars. This is a Groovy and Java implemented concurrency and parallelism library for Groovy and Java applications. The current version is a Java 7 library and a significant evolution is needed in the light of the Streams subsystem that is new in Java 8. IntelliJ IDEA comes in very, very handy for working on this.
I am also involved with the SCons build framework. This is a Python implemented replacement for Make with very similar configuration capabilities to CMake and the GNU Autotools. SCons is currently a Python 2 application and I have been working to make it both a Python 2 and Python 3 system. I use PyCharm a lot for this.
I also have various “pet projects” that mean I use D, Frege, Ceylon, Kotlin, Scala, Clojure, Go, Rust, Ruby, Chapel, X10, Erlang, C#, F#, Haskell, Julia, OCaml, and others as well as Python, C++, C, Groovy, and Java.
Anastasia: Wow! A huge set! And what do you think about the recently introduced and upcoming C++ standards? What language features/changes do you personally look forward to?
Russel: The single most important feature that is missing from C++ just now, as far as I am concerned, is modules. It is 2016 and the whole #include mechanism is just so 1960s. Rust and D, and to perhaps a lesser extent Go, are shining examples of what is very wrong with C++. I had been hoping it would be in C++17, but apparently not.
The other thing that needs serious work is the error messages that result from problems in template code. None of my C++ code has templates but, obviously, I use types from the library that are full of templates. I make a small error and I end up with hundreds, sometimes thousands of lines of output informing me of a whole load of compiler template processing messages that mean nothing to me. I suspect concepts could help, given that it requires compilers to significantly rework their template processing. I fear concepts will just make it all worse. Sadly though concepts will not be in C++17 either.
I wonder if there is anything interesting in C++17? Well we may get ranges and some useful amendments to the standard library to support concurrency and parallelism, but modules, and to a lesser extent concepts, are what C++ desperately needs to compete with Rust, D, and Go. With #include, C++ risks becoming a niche language as people switch to Rust, D and Go.
Anastasia: And talking about Rust, D and Go… C++ has been here for years, but Go and Rust are evolving quickly as are many other modern programming languages. How do you see the future of modern C++ in this global environment?
Russel: If C++ doesn’t introduce modules and better error messages, Rust, D and Go will become the native code languages of choice. Clearly many organizations and their systems have a huge commitment to C++, and are likely to stay with C++ just evolving as it does. However many of these are just moving up to C++11 – though I think they should go with C++14 straight away.
D is an interesting language here as it can be using within a C and/or C++ system: D has easy interworking with C and C++. This makes it very easy to migrate a C and/or C++ codebase to D incrementally rather than requiring a “big bang” rewrite as would be the case moving to Rust or Go. The relatively newly established D Foundation is providing a good impetus and focus to all those using and developing D. It will be interesting to see if there is a move from C++ to D because of this new focus.
Rust is interesting as it is effectively a functional style language that focuses on ownership of memory, the single biggest problem in C and C++ codes – who is responsible for managing memory. The classic SIGSEGV and other memory/pointer problems in C and C++ at run time do not really exist in Rust as the compiler does not allow code generation of source with ownership problems.
Anastasia: BTW, there is a Go plugin for CLion from the JetBrains team; Rust plugin is in progress (hopefully will work for CLion soon); and some 3rd party D plugin as well.
Could you please share your experience with CLion? What features you enjoy most, and which ones do you use most often? Are there any features you’re missing?
Russel: Even though I have been a hard core Emacs user for 30+ years, I am enjoying using CLion – with the Emacs bindings obviously. As long as you are working with a project (and not just a collection of effectively unrelated files), CLion adds a lot over and above Emacs, even with a highly specialized set up. The fact that CLion is continually compiling the code behind the scenes and marking up the edit window with errors and problem, means that code development is faster than using an editor that does not do this (Anastasia: to be more correct CLion doesn’t compile the code in the background, but rather runs its own parser to provide on-the-fly code analysis). Also the pop-ups for standard library and project code API on demand as typing is excellent. Perhaps though the single thing that separates CLion form using Emacs is the refactoring and names, i.e the global edit of things across all bits of the project.
The biggest downside of CLion (and you know I am going to say this :-) ) is the requirement to use CMake. I want to use SCons. Eclipse with CDT and SConsolidator has been great, but CLion beats Eclipse+CDT. So I end up having to have a SCons and CMake build for all my projects. I wish this were not the case.
Anastasia: Thank you for the answers. Our team is looking forward to ACCU 2017!
Subscribe to CLion Blog updates
