#ACCU2018. Day 2. Threads and Locks ARE a Dead End, Period!

Author:  Follow: TwitterFacebook
Job Title:Sarcastic Architect
Hobbies:Thinking Aloud, Arguing with Managers, Annoying HRs,
Calling a Spade a Spade, Keeping Tongue in Cheek

As the Day 2 of ACCU2018 is over, here is my report about it.

Kotlin ~= Java with a Better Syntax

Hadi Hariri's 'Kotlin/Native – Embracing existing ecosystems'

Keynote of Day 2 was about Kotlin (titled “Kotlin/Native – Embracing existing ecosystems”), delivered by Hadi Hariri. While the talk as such was pretty good, I wasn’t convinced that Kotlin is worth the trouble. My takeouts from the talk:

  • Kotlin is a separate language, with a syntax which on the first glance looks like a weird hybrid of Java and Python
  • There are quite a few improvements which might make the code a bit less verbose than Java one here and there
    • OTOH, sometimes it comes at a cost of pretty convoluted rules, which are IMO rather difficult to grasp (and are very easy to abuse).
    • Also, there are MANY ways to write the same thing with differences being purely syntactical (which I expect to hit readability)
  • Other than that – the ideas behind Kotlin are pretty much the same as that of Java.
    • Arguably – Kotlin is “Java as it should have been written from the very beginning”
    • On the uglier side – I hate when people are saying “hey, you don’t need to think about memory management”; as practice shows, it inevitably leads to semantic memory leaks Eclipse- and HAB-style. While it is not exactly a flaw of the language, it is certainly a flaw of the culture, and when one of the people behind Kotlin says this kind of things – they’re likely to be ingrained into the dominating culture of Kotlin developers, and it is NOT a good sign.
  • And most importantly – as all the improvements of Kotlin are merely syntactic sugar – I have my doubts whether all these improvements are worth the cost of migration to a yet another almost-identical programming language. Sure, IF Google will do the heavy lifting of pushing Kotlin to the mainstream – it might become a contender, but other than that – don’t hold your breath over it. In other words, while there is nothing inherently bad about Kotlin – it is just IMO not “better enough than Java” to justify migration.

Team Management 101

Arjan van Leeuwen's 'How not to lead a team of software professionals'

The second talk I attended today, was “How not to lead a team of software professionals” by Arjan van Leeuwen; it was a pretty good talk, though for those of you who will decide to watch it (when it is available), I have to say that I disagree with the author on two significant points:

  • I do not think that a good manager can afford to be “isolated” (and feel lonely, communicating with the other managers rather than with the team, ouch!); while this is a classical management approach, for us (ppl who are both managers and team leads), there is an option to be a part of the team, and if you can achieve this – it becomes  soooo major improvement for the team, that it trumps pretty much all the other considerations.
  • From what I’ve seen, it tends to be very beneficial not to position your developers as subordinates, but rather to have some Greater Good(tm) (best product in the world, making millions of your customers happy, …), and to subordinate both yourself and everybody-else to this Greater Good(tm). This is known to help A Damn Lot(tm) (and BTW, I was able to trace this kind of findings at least back to 60s, so it is certainly nothing new).

Other than that – the talk IMO does map pretty good to realities of team management. As an added bonus – take a look at the diagram on the photo above – it shows how much time (4 hours per week) you will have for development after you took that lead/management position (and this is consistent with my own experience in this regard). This is to all those ppl who’re saying “hey, architects and team leads must code themselves” (FWIW, in my books, 4 hours out of 40 does not really qualify as “coding”).

Finally! There is a consensus that treads-with-locks MUST DIE!

And now I can discuss the juiciest of the today’s talks – two talks related to an observation that threads-with-locks (or more generally – shared-memory approaches) are inherently evil (at least at the app level). A year ago (after ACCU2017), I wrote that “we are past the point of no return” in this regard, and now we already can observe a landslide of talks (by very knowlegeable and respected people) quoting and re-quoting that “mutex should have been named a bottleneck”, that threads as such are not scalable, and so on, and so forth.

Hubert Matthews's 'Read and write considered harmful'

The first related talk was “Read and write considered harmful” by Hubert Matthews. Overall, it was brilliant talk (ABSOLUTE MUST WATCH as soon as it appears on the YouTube).1 Overall, it is very much consistent with my own talk coming on Saturday, going along the lines that whether you’re dealing with in-memory state or DB, you should go for Shared-Nothing architectures for one simple reason that nothing else scales (and in addition, Shared-Nothing Message-Passing architectures provide all kinds of goodies such as being testable, having post-mortem debugging, etc. etc.).

Hevlin Kenney's 'Procedural Programming: It’s Back? It Never Went Away'

A talk by Hevlin Kenney (titled “Procedural Programming: It’s Back? It Never Went Away”) was more of a brilliantly-delivered lecture about the history of procedural programming, and I didn’t expect any further trouble for multithreading, but – all of a sudden it culminated with the quote on the photo above: “Threads and locks – they’re kind of a dead end, right?”

Overall, I am extremely happy that we got a consensus that we should get back to single-threading (after all, I am writing about it since 2010); I am sure that it will allow writing MUCH more reliable (and significantly better performing) programs. For details – if you’re in Bristol now, you may want to visit my talk on Saturday…

1 and I have to admit that I felt like a student (ok, let’s make it a Ph.D. student) listening to a lecture by a professor: while everything he said was perfectly understandable and in line with my own experience, it was for the first time in many years that I felt that I’m listening to a person who knows more than me, in what I consider “my” field (FWIW, last time I got the same feeling when I spoke to Alexander Stepanov about 20 years ago).


Tired hare:Phew, it was a long day – and there is another one coming. I hope to continue my reports from ACCU2018 tomorrow. EDIT: unfortunately, nothing worth mentioning has happened on Day 3 of ACCU2018 (except for a talk by Jon Kalb, but it is hardly worth a separate post), and as for Day 4 – after speaking there, I had to leave early, so I wasn’t able see any other talks on Day 4 🙁 .

Join our mailing list:


  1. says

    Do you have any experience or opinions on Rust? I find there’s a lot of overlap when I read about the benefits of Rust and the things you speak to on this blog.

    • "No Bugs" Hare says

      Significant experience – no, opinions – yes ;-).

      IMO, Rust has several very nice ideas, but – it is still far from being ideal. In particular, (a) its safety rules are IMO causing way too many difficult-to-comprehend compile-time errors (and as I wrote, we can do better than that, by making all the safety rules inherently LOCAL for our functions – and Rust lacks this locality, so to understand what’s wrong, I may have to analyze a dozen of different places in the program, which causes LOTS of confusion and is double-plus-ungood in general 🙁 ), and (b) its memory handling has waaaay too many primitives to remember about (RC vs Arc, RefCells with associated risk of thread panics(!!), and so on, and so forth).

      Sure, it IS possible to have a SUBSET (=”our own dialect”) of Rust which is usable – but apparently, it is also possible to have a SUBSET (=”our own dialect”) of C++ which is safe and usable :-). And choosing between a usable SUBSET of Rust and usable SUBSET of C++, I tend to prefer C++ (C++ has a HUGE user base, it is MUCH easier to find ppl who know it, hardware such as GPUs is optimized for C++ standard, C++ has ENORMOUS power of compilers and optimizations behind, it can run EVERYWHERE – in-browser included, and so on and so forth).

      So, my take on C++ vs Rust goes as follows: looking purely at language level – NEITHER language is ideal, and BOTH can be made “good enough” in practice by defining as usable subset/dialect. However, other factors listed above tend to push towards C++ (borrowing whatever-necessary from Rust 😉 – though TBH, I didn’t really borrow from Rust when I wrote my own C++ safety rules in [https://accu.org/index.php/journals/2407]).

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.