Recently there are a lot of conversations about whether you can or can't be a good .NET engineer, or Java engineer, or whatever other engineer. The word "good" means different things to different people. We can always look at this question from many different perspectives and the answer can be yes and no.

What is .NET or any other platform for building software, like Java, Erlang, PHP, etc., whatever? It is the approach we take to achieve our goal. When there are not many players on the market of building software - there are not many choices and you will choose one or another based on what approach is easier for you to use, what would be more prospective in the future, what other potential types of problems you want to solve with the instrument you've chosen. We can summarize all these efforts we spend using one or another approach as an opportunity cost. Also, it can vary from one language ecosystem to another as well as from one person to another. One person can be more productive using C# and F# for solving the problem versus using Java + Scala for solving the same problem. At the same time if there are some changes in the language ecosystem that affect everyone's level of productivity can move you toward the decision to switch to another language ecosystem, because it offers more ways to solve the problems you face every day. With the time going there are a lot of languages that built entire ecosystems that help people solve their problems. Now, when there is a choice of what to use as a primary language that will help us to solve MOST of the problems you have - what are we considering? We want to choose the one we are most productive in and that would reduce the time and effort we spend for solving our problems. By choosing one we pay the price of what we might have lost if we had chosen another ecosystem.

Now, if we look at the average day of the median Engineer, we again have various possible outcomes. Some of them are really productive in using the languages and tools existing within the ecosystem. But at some point, some of them will find that there's something missing, there's no ideal framework in the ecosystem, that will allow them to solve the problem. The possible solution is to either spend their own effort and build the framework using the "native" language the person is most productive in, and ideally contribute the tool back to the ecosystem, which will help other people be productive when faced some similar problem and mitigate the risk of people switching to other ecosystems, which will happen when they reach the critical value of the opportunity cost they'd realize they'd have to spend to solve the problem staying within the "current" ecosystem of choice. So, it's pretty natural and intuitive, that the person will explore the competitive technologies and ecosystems, comparing the amount of useful tools that they can use to resolve their business tasks with acceptable opportunity cost from their side. At the point when the efforts that a person would have to spend to switching to another language and learning other frameworks (which is basically time), will be equal to the amount of efforts necessary to implement the solution from scratch (and possibly contributing it back, but probably not, because time=money) - the decision to continue staying within the current ecosystem will be within the user's indifference curve. Which means, it's up to a person to decide. But there is no such a thing as indifference in real life. There is always a thing that is better compared to another thing judging by productivity/opportunity cost, with other input parameters being equal. Standing in front of this choice we will see how much of other good and useful tools the ecosystem offers? What might we benefit from in the future from using them for other possible problems? What if same situation happens again, when we find ourselves in shortage of tools to use to be productive, whereas other ecosystems have it? What is the probability of it?

Another important aspect for the language ecosystem in general is the possibility for users from other language ecosystems to use the tool or framework. Coming back to the case when there is a small amount of players and competition on the market of language ecosystems where consumers are users. Each of the ecosystems will build the frameworks within itself. But at some point, it's really obvious that there is a limited number of problems what will at some point intersect, and if those ecosystems continue behaving same standard way - they'd both have to build the approach to solve the same problem. One of them will later realize, that there are a lot of people who use other languages, but have exactly same problems, so why don't we allow them to use our implementation? Yeah, we know that the implementation is initially in the language that is different from the one they prefer to use, but what if we provide a simple way to use our framework from their language? They'll have more options. They are not forced to switch to our ecosystem to benefit from using our tools, but they will not have to implement the solution from scratch if they lack it in their preferred ecosystem. This is cool. People will love Y, because they don't lock users in their ecosystem, instead, they want to focus on creating the solutions to some problems or prospective problems, that wide audience will be interested in having solved, and providing the way for people to use it. Not only for people within Y ecosystem, but within many others.

Then, when people catch themselves in the situation that, damn, we write the language X but we are always using Y's frameworks. Maybe we should look more into Y as our primary choice ecosystem? Then we won't spend time writing the Y's "framework binding" code in X and we will just use it from Y directly? Well, yes. This might be a reason for switching if a person finds themselves productive in Y taking into account efforts they have with using Y's tools in X.

Also, remember, even though people in different ecosystems face same or similar problems sometimes, it might be easier for one ecosystem to implement and commit the solution and provide it for users than it might be for another ecosystem. So, the cost of implementing a similar framework might very different for different ecosystems.

So, there are ecosystems like X and ecosystems like Y. The ideal world is to find the language you're most productive with, and have the possibility to use the tools and frameworks of other ecosystems around. But that means that you can also you not just a singe language. but languages, various language for various problems, whatever that makes you most productive. But this rarely possible and we always have some sort of choice, which can be based on different factors for different people.