Rust for frontend? Umm not sure that’s the recommendation most would make.
stevensonmt
kokolegorille
John-Goff
WASM, last I checked, could not interface with the Dom, which Imo makes it a poor choice for web UI. You’d probably need to use something like qt instead. Which might make for an interesting learning journey but won’t be easy to make web frontends with. I’d instead recommend building something that actually needs to manage memory manually, maybe a game or reimplementing a library or cli tool.
1
AngeloChecked
I am overwhelmed with learning 2 languages.
I would like to focus on one language for a long time.
0
exjutsu
KOINIK
Dear Friend, let me answer you with two short links that show that knowing rust is already very connected to the Elixir !! (When Elixir's performance becomes Rust-y - Kabisa) (Writing Rust NIFs for Elixir With Rustler | Mainmatter)
1
tj0
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:
- 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.
- 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.
- 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.
- 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.)
- 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.
12
AngeloChecked
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’m happy you reopen this discussion with this so useful response ^^
2
tj0
Ah, glad you came back to look at it.
I just realized I forgot something rather important. I put data structures and database schemas at the top for backend systems, but I failed to mention SQL as a language. If you’re going to be working on any data systems, you’ll need to know at least up to joins, subqueries, and/or CTE’s.
I’d put SQL even before Elixir because it’s generally applicable. Anyway, good luck…
1
Rustixir
First Learn Erlang because after learned that, you see a new world and really opened third eyes 
even you learn Elixir but need Erlang because Have Great Doc for learn
everything from basic to advance after Erlang you learn Elixir and Phoniex its Amazing
after learned thoose you can come to Rust+Tokio World.
that is God of Concurrency with Best of Concurrency Model and ZERO abstraction and give
you High level of coding and complete Safe.
in Erlang/Elixir World you learn how solve if a process CRASH with supervisor.
but in RUST+TOKIO you never crash because write complete safe All thing from scratch
Why Rust+Tokio is better than (Erlang, Elixir, Akka, Golang)
Elixir => Dont have standard struct , wait you have but with treaky and when you want use amazing feature of erlang make problem for you, for example Mnesia is best i had ever seen for in-memory distributed but with elixir you have not good feel when using it because have not a correct schema of tables,
Erlang => Erlang is amazing but is slow BECAUSE in background tried make a always available system and avoid crashing system and meny many other things, BUT in RUST solved All this problem by compile time and make complete safe system, with great error handling i ever seen.
Akka => is Great but use a GC for whole system not like erlang/elixir GC per process , even use ZGC maximum 10ms pause time, have to much impact on cpu usage. have you must learned to much things and after all you saw all of that solved a bad background JVM.
Golang => is Awesome but not support Generic by default and again use GC for whole system
Rust + Tokio => Not Have GC, Safe from Scratch, Blazing fast like C++, with complete Safe system and ZERO abstraction and give you High-level code. Solved all things.
0