Can't Driven Development

    in the article I wrote how detrimental it is to the developer's social life, to know multiple languages.

That is an opinion and not fact. One based on your personal experience that is not universal in any way. Knowing multiple programming languages is quite normal and I would expect any good software developer to pick and up be able to program in (almost) any language. I guess https://en.wikipedia.org/wiki/Brainfuck might be an exception. JCL comes close to it.

We learned this in high school and it was super fun: https://en.wikipedia.org/wiki/Busy_beaver

Do I expect everyone to be an instant expert in any language? Or able to create the busiest beaver? No of course not! But I do expect any decent programmer to pick up any programming language and work in it.

Do we all have preferences? Heck yes! I absolutely dislike Python and would not take a job where I have to program in it if I wasn't forced to by circumstances. I've never done C# or Lua professionally but it was super easy to pick both up when I dabbled with them for game development in private (each respective game engine used these languages for scripting).

    Secondly, companies need to realize that they request multiple programming languages because the current programming languages can't parse stack traces

I read something like that in the article and it still makes no sense whatsoever when I read it here either. Parsing a stack trace in various languages is absolutely possible. But what's that got to do with anything?

FWIW, yes, I've actually looked at previous stack frames (e.g. `e.getCause()` in Java) for error handling. It always felt very very dirty but it was my only choice under the circumstances.

    they push everything to microservices

We have to distinguish the why there.

Some companies (meaning the people within those companies) because they read about how Netflix has x-many of them and it's the thing to do today. Stay away from those companies. They will also make you do other things just because someone read an article of forbes.com.

And then there's companies that are actually trying to solve similar problems as the ones that Netflix was trying to solve with microservices and it actually makes sense to model their internal application service landscape that way! We're in that space for example. We have one big legacy "macroservice" aka very monolithic core and then we have a bunch of newer microservices (some larger, some smaller) that actually solve problems. All of these microservices are written in exactly two languages: Java and Kotlin. Newer ones in Kotlin, older ones in Java (like the legacy monolith). The FE is written in exactly one language by now: Typescript (converted from quite a large javascript code base over multiple years).

    so they can parse their errors from DevOps services

What does that even mean? Makes no sense to me whatsoever. If you're talking about having a central log analytics service like Splunk, Datadog or Graylog et al. then that has nothing to do with microservices or multiple languages. At a previous place we had a bunch of monoliths make up the overall application and splunk so that you'd be able to actually reason about what the system overall was doing for any given overall user transaction / session and it was awesome to have. And if you have any sort of actual need to run software that has uptime requirements, then you are going to run at least two replicas of whatever service you created, monolith or not and you want a central log aggregation service.

I'm really sorry to say this, but it seems like your articles are really just ranting about things that you personally don't like for one reason or another but there's no actual real reasoning or universal truth to it.

to understand what I said, you have to solve the Error Handling Challenge, in your favorite programming language https://rm4n0s.github.io/posts/3-error-handling-challenge/

When you try to implement it, then everything on what I said will make sense to you.

Also, we don't need log systems when there is a programming language like Odin to parse stack traces with type checking (not just string like you gave me as an example from Java).

In microservices you are the error handlers. For example, if in the logs you see a stack trace, then you will go to the code and fix the error.

In Odin I don't need to go in that trouble, because ALL the stack traces can be handled. There will be no undefined behavior in software or unexpected input that caused an unexpected stack trace, so there is no reason to have logs.

I do not study in my free time, no.

I'm not saying I can instantly program at expert level in any language I've never heard of. But yes, I can read most programming languages even without ever having seen them. Take LUA. I had never used LUA and when I started out I was reading code examples and writing LUA code without first "learning" it at all. I just went and did it. Did I probably do some "stupid things" that an expert would do differently and/or fast? Of course. But I got stuff done and learned as I went along. Same when we introduced Kotlin for example. I was instantly productive but someone using Kotlin for a longer time (such as today's me) would "cringe" at how I was writing Kotlin as if it was Java.

Notable exceptions would be languages that have such a weird syntax as Brainfuck ;)

SQL is a great example. I have not been using SQL directly for quite a long time now. But about 20 years ago my bread and butter was SQL and I was writing stored procedures every single working day and I was not writing any Java at that point in time but was using two other languages other than SQL on a daily basis as well (Perl and Bash).

Odin can make stack traces as error types.

Your system with Java will break if someone else add an AuthenticationFilter, but my system in Odin will not even compile until I have handled all the stack trace paths that include AuthenticationFilter.

Do you see the differences between handling stack traces with union types rather than string?

You are making assumptions there, even though in this very conversation you have evidence to the contrary.

In professional capacity over the years I have used Perl, PHP, Bash, SQL (various dialects), Java, Groovy, Kotlin, Scala, Javascript and Typescript. I did not move from Java and OOP knowledge to other programming languages. I started with with languages that don't (have to) use OOP. I still work with Typescript (and until recently Javascript) while also working with Java and Kotlin. And in Java and Kotlin there is very little traditional OOP going on.

I guess the point there is to always keep learning and evolving. I learned Kotlin at work, while doing it. I learned Typescript at work, while doing it. I learned about various libraries at work, while using them. Until a few years ago, I had never used React and I have never used React except at work.