4 ms·
.Net is also good as a platform for other languages. I recently started working with RemObjects, and you can compile languages like Java, Swift, Go and more (VB
by vintagedave 1y ago
.Net is also good as a platform for other languages. I recently started working with RemObjects, and you can compile languages like Java, Swift, Go and more (VB, Pascal) to .Net. Then, the whole framework and ecosystem is available. I'm liking it a lot.
They have customers who are startups and the 'got to have tools' folk like having lots of languages since they can onboard people who know anything-not-C# and benefit from the .Net library.
- sfn42 1y ago> they can onboard people who know anything-not-C# and benefit from the .Net library I don't get this mindset. I'd much rather have the new guy spend a few months getting used to a new language, than have an organization where everyone uses different languages. It's a nightmare a few years down the road when you have 20 different projects in 15 different languages and the people who built them are mostly gone. People are way too lenient with this stuff IMO. The goal of an organization should be to have one solution to each problem. For example we use .NET for backend and React for frontend. You don't need anything else. People love to talk about the right tool for the job, it's all BS. You can make pretty much any kind of website using react and pretty much any kind of backend using C#. The only reason to choose anything else is preference. And sure maybe you have some data science people who need python, thats fine. Just don't have one guy using Py, another using R and yet others using Matlab. That's just asking for trouble. Pick one, stick to it. If you're going to make a change then migrate everything. If it's not worth that then the new tool probably isn't such a big deal after all.
- netdevphoenix 1y ago> People love to talk about the right tool for the job, it's all BS This sounds very close minded to me. It is certainly true that there exist tasks if not subdomains where some ecosystems are better than others. Using a hammer for everything might work for you if all your problems are nails. But that doesn't mean that all problems out there are nails
- mhfu 1y agoIf your organization has one API written in Node, another in Java and third in Python without any reason, then yes, all the problems are nails. And sadly, I've seen this a lot.
- mycall 1y agoI've have limited success using codex to do code conversions for multiple projects into one standard team language. I suspect this will only improve and is how this "problem" gets solved soon'ish.
- sfn42 1y agoIf you can justify with good reasons why you absolutely need this other tool then that's fair game - hence the data science example where I allow for specialists to use specialized languages for specialized tasks. I'm talking about general software development and web dev in particular. There's a trend where you'll see one org has or web app using .net ad react, another using next.js, another using Java and Vue, one djnago and htmx, and so on. And there is literally no reason for any of these choices, they're all fairly basic web applications that could have all been made in literally any half decent web stack. So whether the devs who made these choices knew or not, they made them based on preference not any kind of reason or need, they're all nails and any hammer would have done the job just fine.
- skeeter2020 1y ago>> And there is literally no reason for any of these choices I'm a manager now but definitely held a variation on this "people are idiots" view when an IC and younger. Question: are all your coworkers idiots? No? then why would all the work done before you be the product of idiots? I found it really valuable to approach scenarios where the initial response is "how could this possibly happen?" as a cultural anthropology question. It turns out there were many rational decisions made, most that I would have gone along with that brought us to what we see today. My coworkers are actually really good, some of them who manifested what we see today are amazing. Many are crafting code, making thousands of microdecisions without perfect information or 100% clarity across a large organization, reacting to changing markets and directions, client needs, shifting priorities, executive decisions, technology changes... the list goes on. This is all my way of saying there might be many reasons for any of these choices, and you'll help your own cause - and happinness - if you step back from your zealotry and take an empathetic approach that's less binary.
- Razengan 1y agoDo you also make everyone wear the same clothes, drive the same vehicle, order the same food
- SideburnsOfDoom 1y ago> Do you also make everyone drive the same vehicle Good analogy. If, say, your organisation maintains a fleet of cars - it needs to keep them on the road, get them serviced, replace parts, refresh individual cars regularly etc. How many different makes and models do you support? A small org might decide that it only makes sense to support one. A larger org might have the resources for 3 or 4, so that there is 1 or 2 "general purpose" models, and then other ones suited to specialised tasks.
- Razengan 1y agoBut different tasks require cars, other tasks require trucks, vans, bicycles, motorcycles..
- sfn42 1y agoYeah, .NET is a truck and React is a bicycle. Nobody sad you can't use different tools for different tasks. I'm saying use one tool for one task. One type of truck. One type of bicycle. Maybe some companies need both a small and a large truck. That's all fine as long as you actually need it. Just don't let every dev choose their own because you're gonna have a hell of a time maintaining that fleet.
- SideburnsOfDoom 1y ago> Just don't let every dev choose their own because you're gonna have a hell of a time maintaining that fleet. Yes, this. > I'm saying use one tool for one task. I saw an article ages ago arguing that the number of supported languages should scale with the size of the organisation. Which makes sense to me. The threshold was larger than we might expect though, it was something large like "one fully supported language per 500 devs". In other words, small-medium orgs will have a better time supporting 1 language only.
- ourmandave 1y agoIt's bad enough when you've got constantly changing "best practices" from MS so the thing you wrote last year doesn't look anything structurally like what you're doing now. And all the 6-month-old on-line docs and tutorials aren't only useless, but time wasting.
- sfn42 1y agoSo you don't like .NET, that's fine. I'm not saying everyone needs to use .NET. I'm saying pick one thing and stick with it. That said I think you're exaggerating those complaints, the docs for C# are quite good imo and I've been working with ASP.NET web apps for half a decade so far and I'm not seeing any problems like you're describing. Maybe you're miffed about the Framework to Core/.NET switch? That was a bit of a doozy but the ecosystem is so much better for it I'd say it was worth it.
- SideburnsOfDoom 1y ago> the thing you wrote last year doesn't look anything structurally like what you're doing now... all the 6-month-old on-line docs and tutorials aren't only useless, but time wasting. This is indeed a complete exaggeration.
- ourmandave 1y agoSorry, I love .NET and have used it from it's rollout back in 2002. I'm just fondly remembering the ASP.NET MVC churn or more recently, Azure API whiplash.
- SideburnsOfDoom 1y agoOnline forums often have people asking "hey I found this tutorial for learning c# but it's way way back for .NET 7 will it even work in .NET 9?" The answer is always a variation of "yes, you'll be fine, but also look at a "what's new" summary for the new version.
- to11mtm 1y ago
- jelder 1y agoUsing the right language for the problem domain is a good thing, but what I can't stand is when people self-identify as the one language they are proficient in. Like, "I'm Staff JavaScript developer" no buddy, you aren't "Staff" anything if you only know one language.
- skeeter2020 1y ago>> we use .NET for backend and React for frontend. You don't need anything else ... >> sure maybe you have some data science people who need python, This is how it happens though; it's not "let's form a company with 10 developers; don't worry what tools they use!". It's starting with a single problem using common tools, then adding specialized problems where you could still use the same tools but they are not optimized, then adding an acquisition product that uses different tech, then growing to 100 or 1000 developers and may all use React or C# (doubtful) but don't use it the same way... >> If you're going to make a change then migrate everything Have you ever worked for a software company before? THis is not how it goes.
- sfn42 1y ago> This is how it happens though No it isn't. This is not how you end up with 7 different frontend JS frameworks in 7 different web applications. Using python/matlab/r for data science is completely fair. These languages are standard in this field, they have the most tools and built-in functionality for this purpose. I mean if you want to do ML and data science stuff in C# or whatever go right ahead. If you can make that work that's great. But I also think, as someone who aggressively promotes sticking to one language, that it's fair to use Python for data science. What I don't condone, as I said, is using multiple tools for the same task. So for example, having one team/dev using Python while another uses Matlab and yet another uses R etc. > Have you ever worked for a software company before? THis is not how it goes. Yeah, I know. That's the problem. People just introduce new tech like it's nothing. That's why I'm saying it needs to be a big decision. So if it's really worth it okay let's go for it. But for the vast majority of cases it just isn't.
- chadcmulligan 1y agoYou can also compile to wasm I believe