The issue isn't licensing cost, but developer productivity and being able to hire people.
Like I said, we've struggled big-time to fill our open dev positions. Also, the .Net community is just that much bigger, and the tools get more attention.
For example, a customer recently required us to fetch messages from Azure Service Bus to get an ID for a file in Azure Blob Storage. Sure the REST calls for the Azure API's could have been written fairly easily, but they used that pre-shared key authorization scheme which required signing certain HTTP headers[1]. None of our libraries easily supported integrating that, as they all generated those headers on the fly while making the HTTP call.
In .Net there was already official libraries for this and it took me a couple of hours to write the integration, including testing. Even without the authorization blocker, it'd taken way more time than that to implement the necessary REST calls and properly test them in either Delphi or Free Pascal.
In another example, we've adding JSON support for our "public" API, in addition to our XML. We're quite used to customers feeding us with crap data, so validating against schema on the way in is a must to keep support requests down. In .Net there was already a nice JSON Schema library waiting for us[2], so only took me a couple of minutes to integrate that. The only Delphi/FPC library I could find was years old and didn't support the JSON Schema version we required.
It had to adopt the .NET object model to do so. At which point you get a language that's mostly C# with Pascal-like syntax. So existing code is not necessarily portable, existing devs still have to relearn, and meanwhile you have reduced your hiring pool even further (as Oxygene is even more exotic than Delphi).
Right, this was our conclusion as well. C# is close enough to Delphi that relearning for us that are already here is fairly trivial, while really expanding the number of potential applicants.
Oxygene would maybe make it a bit easier to write C# for some of us[1], but it's incompatible with Delphi so we'd have to rewrite code anyway. Just doesn't make sense.
If you're starting from scratch with a small Delphi team and want to target iOS and such alongside Windows, then yeah I'd consider it.
[1]: not me, I wrote C# back in the 1.1 days and feel right at home
Like I said, we've struggled big-time to fill our open dev positions. Also, the .Net community is just that much bigger, and the tools get more attention.
For example, a customer recently required us to fetch messages from Azure Service Bus to get an ID for a file in Azure Blob Storage. Sure the REST calls for the Azure API's could have been written fairly easily, but they used that pre-shared key authorization scheme which required signing certain HTTP headers[1]. None of our libraries easily supported integrating that, as they all generated those headers on the fly while making the HTTP call.
In .Net there was already official libraries for this and it took me a couple of hours to write the integration, including testing. Even without the authorization blocker, it'd taken way more time than that to implement the necessary REST calls and properly test them in either Delphi or Free Pascal.
In another example, we've adding JSON support for our "public" API, in addition to our XML. We're quite used to customers feeding us with crap data, so validating against schema on the way in is a must to keep support requests down. In .Net there was already a nice JSON Schema library waiting for us[2], so only took me a couple of minutes to integrate that. The only Delphi/FPC library I could find was years old and didn't support the JSON Schema version we required.
[1]: https://learn.microsoft.com/en-us/rest/api/storageservices/a...
[2]: https://www.newtonsoft.com/jsonschema