5 ms·
I bet C# and F# are actually nice languages and I shortly considered adopting them together with Unity but at the end of the day I was still suspicious of Micro
by wrnr 4y ago
I bet C# and F# are actually nice languages and I shortly considered adopting them together with Unity but at the end of the day I was still suspicious of Microsoft, and support for other platforms then windows. The article honestly sounds a bit like a straw man argument. Maybe bloomberg could have made another tech choice but then again I don't know the details.
- cosmotic 4y agoMicrosoft has first-party support for .NET on linux and it's open source. Their commitment to non-windows and non-.NET platforms has only increased over time.
- bm3719 4y agoThey also have a history of randomly deciding to dump a technology (including full languages) too, leaving those invested in it holding the bag. I like F# too, but I'll stick with one of it's non-MS controlled alternatives.
- Barrin92 4y agoany software project or language can die, but I honestly struggle to think of a company that has a better history of long term support than Microsoft. You can fault Microsoft for quite a few things but their ability to maintain software and provide stable interfaces for devs is second to none.
- j0057 4y agoMS discontinues a UI library project and then hypes up a new one every few years. Today Blazor and Maui are hot, but there's a lot of abandonware that came before. You can see it in Windows too, where you can burrow deeper and deeper into progressively older settings dialogs, because they reshuffle the Control Panel every few years.
- philliphaydon 4y agoTo be fair. Creating a good cross UI framework is hard. Winforms wouldn’t cross over to OS X / linux. WPF was too heavily tied to Windows. Silver light was a compeditor to flash and both of those died. Now we are up to Maui and Avalion? Blazor is more silverlight replacement imo.
- kgeist 4y agoAlso, Winforms and WPF were designed before Microsoft embraced Linux and started making .NET truly cross-platform. Starting over with a new cross-platform UI framework sounds like a reasonable thing to do.
- int_19h 4y agoOTOH even stuff as old as Windows Forms (which literally shipped with .NET 1.0 - that's 2001!) still works and it actually has maintainers. You don't have to chase the shiny new stuff.
- tbrownaw 4y agoI hear some of IBM's stuff has a pretty long history to it.
- Salgat 4y agoNot with their core languages. For example, Windows still comes bundled with the old VB6 runtimes and Microsoft still supports the language even if they no longer add features to it. I'm not really sure of any major Microsoft languages that Microsoft has just dumped, unless you count their smaller more esoteric ones. Also keep in mind that .NET Core is not only open source, but comes with complete protection from any patents Microsoft might have. The only thing Microsoft can sue people over is the .NET Core trademark itself.
- tbrownaw 4y ago> still supports the language even if they no longer add features to it This is what I assumed the parent post was referring to. Mostly because it mirrors complaints I've heard (and maybe had) about the .net gui story. WinForms -> WPF -> whatever the windows store app framework was called -> I think MAUI now?
- Salgat 4y agoThat's hardly a fault with Microsoft though. WinForms is fundamentally flawed and far better alternatives now exist, it'd be foolish to continue investing in WinForms. You can still use WinForms and .NET Framework on Windows 11, just don't expect new features, which is okay.
- bm3719 4y agoJ# is one that comes to mind. Spent some time learning this only to have it dropped the next year.
- kgeist 4y agoWasn't J# designed to be a transitional language for Java devs migrating to .NET/C#? (Wikipedia calls it a transitional language, too) Sure it wouldn't last long.
- ihateolives 4y agoFor running, yes. For developing, no.
- celdon25 4y agoWhat part of the .NET SDK isn't supported on Linux?
- philliphaydon 4y agoI think they are referring to visual studio support which doesn’t exist on linux. But if you wanna use VSCode or Rider then the support is 100%
- celdon25 4y agoMaybe, but the discussion itself was about Microsoft's commitment to open-source. Open-sourcing VS Professional, traditionally (and still) an enterprise tool, would be a bridge too far. The commenter that started this debate called the article a straw man, which is ironic.
- eropple 4y agoTheir support for VSCode is pretty considerable and reached the point where I'm comfortable working on non-GUI applications in C# in it a while ago, and from a UI perspective prefer it to Visual Studio.
- tbrownaw 4y agoWhat? I do occasional dotnet development on Linux. Using the dotnet SDK which is from Microsoft, and VS Code which is also from Microsoft.
- metaltyphoon 4y agoHuh?
- verisimilidude 4y agoIf you’re a JavaScript dev, it’s worth noting that NPM is owned by Microsoft. The mistrust angle is real, but I think it’s moot when specifically talking .NET vs. JS.
- moonchrome 4y agoI've been working in .NET for the last year using intel Mac for the first 6 months exclusively and recently switching between Windows desktop and Mac (performance of desktop machine mostly, not willing to be early adopter with M1/2) I also use Rider exclusively and going to Visual Studio on Windows now and then I'm not missing much (visual studio did have some nice plugin for debugging compiler plugins, had to hack around than in Rider) I can't comment on Unity part. F# for me overpromises and underdelivers - it all sounds amazing in theory but it's been 3 times over the last decade where I've tried to use it (last time just a few months ago) and it never just works - I've spent diagnosing "why isn't this F# feature working as advertised" than solving my problem (from tooling like F# projects breaking autocomplete in VS solution - even for C# projects, to language features like type providers just being a nightmare to work with and integrate into CI/CD)
- throw868788 4y agoHonestly I've found F# pretty OK to use compared to some other languages, especially when not using Visual Studio on a non-Windows machine where F# IMO is the better choice. Given a cross-development experience in some of the more recent .NET teams I've been in (great that this is finally occurring btw) especially the Mac developers using VS Code prefer F#. After using it the feedback is that the experience on F#, especially since with F# Resharper is not necessary to function/develop, is preferable over C# (i.e. "its more of a scripting language"). My observation is that the ex JS/Ruby/etc devs learning curve's seem to favor F# over C# as it is more like these languages. There's just a lot less to learn, and the coding style (e.g. modules, function first, etc) is more synonymous with langs like JS than heavy OO languages. I've recently inherited a team that moved to .NET from JS, and getting them to try C# has been painful especially when using things like ASP.NET. There's a lot of knowledge I just took for granted - we don't realise how much knowledge is required to use standard Java/C# OO in a production like setting that many dev's stumbled on when they were junior but have long forgotten the learning curve they went through. They tend to be framework heavy/dependent and require much more experience. From patterns (what's a strategy, repository, etc etc), to dep injection frameworks, to which refactoring tools I need, etc, etc - where in F# in my recent experience the experience is more, but still not quite "just code and work it out as you go". The pit of success favors F# over C# in my experience with these teams especially if you keep it simple with the features used. My experience has been that F# appeals to coders who are using the .NET platform coming from languages like JS/Go/etc but also has static typing who usually at least in the jobs I've been in are often on a Mac. C# dev's typically come from Java/C# enterprise kind of shops. Not one is better than the other and I will work in whatever space has interesting problems to solve - I think the difference is more cultural than technical.