Standard career advice for the start of your career - go wide instead of deep. Early specialization might be good, but it also has a tendency to be career limiting.

One of my good friends spent 10 years writing filesystems and various drivers for controllers. He became an architect, but still was massively underpaid. In fact, no one could understand how what he did would translate into anything else when he was interviewing. He had to leave the company and field to get paid. Eventually, he got a job at a startup learning web development and he had to go thru the learning gamut himself. Luckily, it was super-easy, cause when you’re working on filesystems, you have do everything yourself. Now he was working with python and he just had to break his habit of writing really good low level code instead of using some library. In fact, learning the vocabulary and words that people use was probably the most difficult part for him. After two years of learning the basics, he is now working at FAANG on low-level database design I think. Something low-level at least.

Now I’m not saying that you should never specialize eventually, but for right now, my suspicion is that you don’t even know what you like/dislike yet. Whenever a junior engineer would join my teams, I would have them do a tour of activities with small projects. These activities would ensure that they understand a few things for backend systems:

• the importance of data structures. You can use whatever language you want, but if your data structures suck, the damn thing is going to fall over anyway.
• database schemas - the next level up from data structures. They wouldn’t be ready to design tables and put them into production, but understanding the nefariousness of benchmarking and getting their head around sql is the key requirement here. If they can explain the tradeoffs the current team made, even better.
• metrics, monitoring, and general observability - when they made a service can they prove it’s any good? The most important part is the tail latencies and performance on mobile or international customers. Maybe they’d even have to do some caching and understand how terribly difficult it is to do well.
• pair on some low-level debugging problem which comes up
• deployment - if there was some improvement to be made, this was always a good learning opportunity (blue / green, handling secrets, etc)
• security - I’d have them go through recent audits from the security team and fix things.
• qa - they have to show they can write an “appropriate” number of tests. No, I’m not a big fan of unit testing.

Other rotations could potentially include analytics, scheduling, sharding, databases, authentication, ui design, chaos testing, or any useful idea. They would need to be able to show that have some decision making ability and that comes from seeing different situations and the tradeoffs. For the ones that were interested in reliability, I would also give them time to learn elixir, which is also great for prototyping and system design.

But the basics come first because we live in a world where you need to be able to build stuff. All this work had a ton of impact at the companies I was involved with. Almost none of it has anything to do with systems programming.

So, in my experience, I can hardly recommend a systems programming language as an early choice. My language recommendations for new engineers is now:

1. python - you can use it in almost any field - data, web, scripting, etc. You already know Kotlin, I’m assuming it is roughly equivalent as a generalist language. Python is easy though, you can pick it up when you want.
2. elixir - for prototyping and system design, this is unbeatable. You can model an entire system in one application without having to have 25 webservices and kubernetes. If people truly understood the modeling power…I’m not going to start waxing about erlang/elixir. Once you get familiar with this ecosystem, the prototypes you come up with might be better than the production applications that teams spend 9 months futzing around trying to do fancy things because you can just do less and do it better. You might not be able to use it in your day-to-day job, but you have a long road ahead and there’s no better ecosystem to learn to to understand systems and just building random stuff. The core team is making it a more generally applicable language now, too.
3. css - I just learnt css two years ago (lisp was previously at this spot). I spent 20 years building different types of backend systems. Building a good UX is much harder than building a decent backend, but if you want to build stuff, this has to up there. I regret not learning it sooner because that was one of my biggest gaps.
4. a systems language - could be highly impactful for some subsystems. Early in my career, I wrote C, so I had this early. Rust was on my list of languages to learn, but now I’ve replaced that with Zig (I haven’t learnt Zig yet, but I’m donating to them. Really like the design philosophy.)
5. a lisp - I had a team that wrote clojure for a year or two and so I picked it up. A lisp in general should deepen your understanding of designing around data.

My philosophy is to maximize the ability to build things. This isn’t to say become a full-stack engineer, but to understand what is happening at all levels of the stack. Become a B or a C player at most of these things and then figure out where you want to be an A-player. And learning how to build things well is about doing a variety of projects. It really isn’t about the language itself, but understanding different architectural tradeoffs and making sure you have the right tools to execute.

Also, get yourself a mentor who can spend an hour with you every week or two. And make sure they aren’t an idiot.

Edit - I can’t believe I responded to something where the original post was from Oct '20. Ah, well, will check the date next time.

I just started learning elixir, but I code for about 7 years. My suggestion is to avoid this idea of “locking” yourself to only learning ine specific language. A language is just a tool. Some tools are better for some jobs than others.

My suggestion is to find what you want to accomplish first, then you think about what tool to use. Try to learn the main concepts of both and when you find a good project, then you can use the one that does the job better

two completely different language archetypes and use cases. if you’re doing web go with elixir, if you’re doing serious number crunching do with rust. but they are definitely not interchangeable. it’s like comparing c++ and ruby.