31–40 of 48 posts
Step 2: write a blog post about how your decision has improved application performance, stability, and development time. State as much opinion as fact as you can. Then submit that to HN.
Step 3: enjoy your new found status as a tech leader.
- stable APIs of essential libraries and frameworks
- a grown up culture that accepts that something isn't dead just because it doesn't get an update 8 times a day
- tooling that will still work and be supported after 5 years (not a new package manager or build tool every year)
- communities and individuals around it that are focused on getting things done instead of status and drama
1. Your first choice should be the language you or your team knows best.
2. Every language is built to solve certain problems and are, at the end of the day, opinionated. This may not be true for the most popular generalist programming languages; but stuff like Purescript for example, is great if you already have a Haskell codebase, with Haskell developers and you need a frontend. Easy to onboard/get productive in vs learning React/hiring React devs.
Choosing the right tool for the job is imperative. I will not use Rust for my web UIs, I will not use Javascript for writing code on embedded devices. Research and decide accordingly based on how it fits your existing pattern of thought/time constraints/end-goals.
3. Avoid language zealots and maximalists. People who'll try their best to convince you to write and do everything in a single language. A lot of Rust people will attempt to write everything in the entire project in Rust, even stuff like web UIs. This creates unnecessary friction, and you end up fighting the language rather than being productive.
4. Have fun, learning a language expands your thought process, it exposes you to different ideas, ideas that you may bring into other languages. For example, after learning/working with Haskell I wrote my own small utilities for higher-kinded types in Typescript.
5. Languages are a tool, choose a tool that's right for the job depending on how long you have and how adept you are with your existing tools.
=-=-=
edit: anecdote
I was building a deeply nested tree representation of 3D models with thousands of meshes, materials, etc. I wanted to write the parser in Rust and do some fun parallelization, but I am simply not good enough with Rust atm to do so; therefore I've built a correct implementation of it in Typescript, something I know very well, and now I'll begin porting it to Rust while at the same time learning the language.
This does two things for me; my team can test my implementation and build on top of it since the API won't change, and I can take much less time re-writing it in rust while also learning about the language.
Just a little something I do when learning any new language; rewrite something I know very well in it. Be it Raytracing in a Weekend or one of my older projects.
All else being equal, what I've come to value more over time is long term stability of languages and their ecosystems: - stable APIs of essential libraries and frameworks - a grown up culture that accepts that something isn't dead just because it doesn't get an update 8 times a day - tooling that will still work and be supported after 5 years (not a new package manager or build tool every year) - communities and indi…
Simple — Rust for everything except Typescript for browser/mobile and Python for scripting.
Even, then I use Rust via WASM.
All else being equal, what I've come to value more over time is long term stability of languages and their ecosystems: - stable APIs of essential libraries and frameworks - a grown up culture that accepts that something isn't dead just because it doesn't get an update 8 times a day - tooling that will still work and be supported after 5 years (not a new package manager or build tool every year) - communities and indi…
Work:
I prefer tech that is well known within the team that will maintain it. Keep the bus factor low.
Personal side projects:
It depends on my goal. Is the goal to learn a specific tech, or create a product? If my goal is a product, I choose tech that I know well. I want to focus on the product, and not spend time in google/chatgpt figuring out how to do X in Y. The product itself has so many unknowns, that I don't want to add more due to my choice of tech, otherwise I risk losing my motivation and the project ends up in limbo.
If I had to choose a single language for everything, it would be Java (or Kotlin if necessary). The eco system is solid and my productivity is easily 4x compared to other languages.
Most developers can learn to produce code in any language in days. But mastering a language and eco system takes years.
But then you also have to include what type of application it is. Real time or soft real time, etc.
Low level stuff, my go-to these days is Odin. Just super pleasant to use. Also super easy C-FFI, so it can interact with most code out there with a small amount of effort.
Web stuff, random scripts, utilities, etc... Ruby. For pretty much the same reason: it's pleasant and easy to use. Obviously easier than Odin because no need to manage memory and much higher level. It's FFI also allows you to interact with most languages (including Odin, in just a few lines of code).
Also, I should mention, I use stuff like JS, Java, C/C++ as needed. Sometimes there's a library you need, a platform where one of those is needed to glue it together, JS for web front end, etc...
1. Figure out the best programming language (it's Scala) 2. Use that for all the applications I build