Alex Kuleshov

I'm continuing to look for a fully remote, full-time backend role. Senior backend, Go and Elixir/Erlang/OTP. I build distributed systems: Kubernetes, observability, databases, and large-scale telecom platforms. My timezone is GMT+5, but a 3–4 hour time difference works great for me. DMs are open and RTs, as always, are hugely appreciated.

@awesomekling TASM/Turbo debugger will live forever in our hearts

you know you worked on MS-DOS programming if you remember stopping the debugger on an “ADD [BX+SI], AL” instruction hundreds of times 🤓

I have absolutely the same feelings/experience. If a use-case does not strictly require fine-grained resource control, no gc and so on, in most of cases I would go with golang. Especially if not only I am working on a project and need to communicate and with people and their code.

I wasn't expecting that Go vs Rust tweet to hit a nerve. Quick elaboration based on what I've actually seen. I build a distributed sandbox system that has both Go and Rust components. I have effectively unlimited access to the strongest models, so I've spent a stupid amount of time reviewing and cleaning up LLM-generated code in both languages. The difference in reviewability is stark. Go was designed for thousands of engineers at Google to collaborate without stepping on each other. It has very few concepts, so the code ends up looking similar no matter who (or what) wrote it. You see the same patterns everywhere. The err returns are verbose, but at least they're predictable. Channels are about as fancy as it gets. GC removes an entire class of mental overhead. Goroutines + mutexes just work for most concurrency needs. As a result, LLM-written Go usually reads like a novel. You can understand what’s going on quickly. Rust is the opposite. More power, more ways to do the same thing, more concepts you have to hold in your head. When an LLM writes it, you often can't tell if something is elegantly minimal or just over-engineered. Arc> vs Go's atomic.Pointer[RoutingTable] is a perfect example. One makes you pause; the other one is obvious. You also have to know the de facto Rust standard library that lives outside the standard library (tokio, serde, anyhow, parking_lot, etc.). Moreover, Rust's concurrency model is excellent, but there’s just more surface area to reason about. So my upshot is that 95% of the time, if something is in Rust today, it probably would be clearer, faster to review, and easier to maintain in Go. What I meant by the "rewrite it in Rust" meme should mostly be "rewrite it in Go." That said, Rust has its place (I’ll do a follow-up post on the 5%). But picking it because it’s trendy is the wrong move.

@ajohnston97629 You are reading my thoughts... I was just about writing a tweet in context of the most recent one "I love c++"- lets better hate git submodules together :)

@0xAX we actually do need to make Kbuntu the official Linux desktop and C/C++ package management system. And then demand everyone support it as such. Debian needs the love. Linux drivers need the love. And git modules isn't it.

Didn't expect such reaction on this tweet. Maybe it is worth to elaborate my opinion a bit. I've received lots of advice - use this or use that, what's wrong with X build system, Y is better... Can be. Cargo is not perfect. Maybe your X tool you are using to build you C++ code is way more better, I would not even start to argue with this. For me, the problem with C++ build systems not in a given concrete tool or it does not have good tools. The problem is that it has a zoo of them.

And yes, I love c++

@ajohnston97629 Whats the point? With DEs/WMs/UI on linux the same mess as with c++ build systems... who won from this... except some jokers in the style of the year of linux on the desktop

@0xAX the C++ packaging system is Ubuntu. Microsoft even built a whole subsystem for it. Now why don't you go tell all the Linux nerds they have to use only KDE Plasma, you seem to be having fun.

@tapeloop It could be destroyed by not starting cargo

@0xAX So we can destroy rust by starting a couple of alternative package managers

@Adev You are right. Under cargo I meant rather unification. Let it be make, cmake, bazel, whatever, but single tool instead of ten > Package managers terribly interacts with each othe exactly this... and having more and more of them does not make anything simpler

@0xAX Do a bit of integration of in large software ecosystem and you will quickly understand why Cargo (or any package manager) for C++ is a terrible idea. Package managers terribly interacts with each other, and C++ is used under many of them. 1/2

cmake is c++ in the world of build systems - powerful, portable, more complex than needed

Wanted to dive into formal verification already long time, maybe this one will be good - Tutorial: Introduction to Formal Verification with Lean (Part 1) - hashcloak.com/blog/tutorial-…

@OlexGameDev Also of course understandable. Although I cant agree it is the right/ideal way to go looking at how community spends significant efforts to integrate all of these new systems. Especially considering that we are talking about build systems.

@0xAX That is how all new systems begin. There is always a need for a custom solution that solves a particular set of issues. My solo C++ builds have different requirements from the corporate C++ builds.

@OlexGameDev But if seriously... ok, let's imagine there is 'cargo' which is used nearly for 100% C++ projects... would you really start to build you own? I suppose in most cases no, or I am wrong?

@0xAX Suppose there was only one build system. Why should I use a build system that everyone else uses?

@OlexGameDev You are free to use whatever you want :)

@PixelSupreme Yes, yes. Of course, understandable. Whatever good will be built next, there is still so pale of the code written before, that we will live with it anyway, but why not to dream a bit :)

@0xAX That ship has probably sailed. Too many projects do things in too many different, bespoke ways. Even if there would be something like an "official" package manager/build system it is bound to be a huge pita for many projects to adopt and thus not going to happen.

@OlexGameDev In some... if not in most cases it is not a concern, but in a case of build systems I would say yes

@0xAX Too many options is a concern? That is such an Eastern European take.

@tribbloid each of them can be good on its own, but this zoo of tools is the main problem

@0xAX meson/ninja, conan & zigbuild not good enough?

c++ needs cargo

@__becks_ Yes, it is single tool for any rust project

@0xAX Anything specific about cargo?

@straceX v.size() is unsigned, so v.size() - 1 wraps around and booooom

A classic C++ trap that still sneaks through code reviews. If v is empty, what happens when this code runs?

@dpedu do people even remember it now?

@0xAX do people even hate on autotools anymore?

@HSVSphere > useful features for example?

@0xAX No. It doesn't have many useful features, it is just badly designed and old. And no, C++ doesn't need cargo, that sucks worse