This has been brewing for quite a while.

I've witnessed many debates on programming languages - which is better, which is worse, how dumb you are for choosing one against the other.

And while I think that there is merit to these conversations - to some, at least -, there's one aspect that I feel gets lost almost every time.

It's the fact that you, someone who's standing on the outskirts, can't fully understand the value proposition.

Alright, definition time. If we Google for "define value proposition", we get this gem

value proposition
noun
(in marketing) an innovation, service, or feature intended to make a company or product attractive to customers.

Perhaps easier if we define the words separately, this time from Merriam-Webster:

value
noun
relative worth, utility, or importance

..and..

proposition
noun
something offered for consideration or acceptance : proposal

In simple terms, for our use-case, it's "if I use this, what can this thing do (for me)?"

I've had my fair share with programming languages - I've shipped code to production in Java, Python, Go, and Javascript / Typescript, have dabbled in shell scripting, Clojure, Kotlin, C#, and currently whacking together something in Rust.

You might say I have a problem when it comes to sticking to a single language. You might be right.

But the point is - each and every one of these languages have taught me important lessons about writing software. And most importantly, lessons I could take over to other languages.

The power of plain functions

Take Clojure, for example. It's a lisp-like language on the JVM (and CLR and browser, and also apparently transpiles to Dart?), wonderfully crafted with very strong ideas about the value of type systems. Or rather, the lack thereof.

See, Rich Hickey, its creator, decided that (apart from the primitive ones), 4 types are perfectly enough to write production-grade, maintainable, extensible, and performant software. An array list, a linked list, a map and a set. That's it.

But the whole language is designed around these 4 types. You can easily transform them into one another. You can iterate through them, check if they contain elements, filter them, transform them, and in the end, "it's just data".

And it works. People love Clojure (3rd most loved language in the StackOverflow's 2022 developer survey), and do build amazing applications - like Datomic (a database), or NuBank, a Brazilian bank, which has most (if not all) of its services written in Clojure.

I myself have only dabbled in Clojure. And I see the glimpse of its value proposition - I see that if I were to have a project, a real project, that I finish, I would fully understand its value.

But until then, I can't claim that The Clojure Way is Good (or bad, for that matter). What I can claim, is that I've taken a much more simplistic approach when writing code in other languages, because I saw how powerful that approach can be.

No need to over-complicate everything.

Checking everything at compile time is good

Then there's Rust. Rust pushes you towards types, and being explicit. Everything you do, you should use types. Create types. Implement traits. Fight the borrow checker, then yield because it's actually right.

It's a struggle. You suffer. But in the end, after months, it clicks. You no longer fight it. You create your nifty little types, you look ahead and see that you're about to embark on trying to implement a cyclic data structure, but you already have the scars to prove that that's not a good idea, in Rust at least.

So you rethink, redesign, reimplement. And the end is glorious.

I have enough experience with Rust to understand its value proposition.

And yet I don't, at least, not to its fullest. I don't have any services running in production (yet), so at this point I can't be sure that the promises that the borrow checker and Rust in general is giving me will come to fruition.

If the suffering up front is worth the calm after deployment. Only time will tell (and when it does, I'll write it up).

What I've taken with myself to other languages is that I now see whether some patterns I'm trying to implement would work. Whether there's a possibility of a race condition, or memory leak. I'm not good at finding them, but when I do, I'm happy (and a bit proud)

How to make a decision when you're looking to learn a  new language?

Let's say you're evaluating learning a new language, say, Rust. Or Go. Or Javascript, it doesn't really matter. The point is, you have hearsay about it - people telling you how awesome or how horrible it is. Be that talks, books, or just chatting with people on Discord.

Here's what I want you to think about.

You don't know what the language is like, because, well, you don't know the language.

Your friends / coworkers / authors / presenters may very well have the adequate experience to have an authoritative opinion about it. And maybe they're very happy to share their opinions with you.

But they are an outsider for you. They don't have your experience, or your knowledge, or your current circumstances, what they have is theirs. So their experience, while it may be valuable for you, may not be as applicable for you as it is for them.

It's the same reason why people say YMMV. Or idk tho. Because they are not you and you are not them and therefore what they went through and what they have learned may not apply completely for you.

So the only way to know whether a language is worth learning is to learn it. There is no other way.

Which, when you think about it, is not the best situation to be in. By the time you actually realize what the language can offer you, you already know the language, and therefore, have made the task of making a decision void.

If you want a quicker decision, then the only piece of advice I can give is to go back and look at the value proposition. Think about whether that's something that could complement your already existing skillset, or if it's something that can be applied to the problems you're working on. Or heck, maybe help you find a position which you'd enjoy more (and also earn more).

Look for a language that can teach you something. Be it functional programming, compile-time memory safety, REPL-driven-development, type-driven-development, or what have you.

You can (and probably should) look for people in the space you're trying to enter, and listen to what they say, and hope they're not bullshitting you.