Live data from Hacker News

Update to the .NET language strategy

devblogs.microsoft.com

141–150 of 151 posts

Re: Update to the .NET language strategy

#141
post #41

> F# explores new language possibilities and the community provides a rich experience across platforms. There are several interesting observations to be had here. For one, F# already explored (past tense) new language features and has long been essentially feature complete. It gets little features here and there, which are generally quality of life type of things (like anonymous records, for example). Another interpr…

I think F# is going to do well because it is driven by the community making it an open field despite being .NET. F# developers seem to have a higher than usual lower-bound.

Elmish.WPF, FParsec, so much there and still things to do...like better development tooling with VS Studio Pro.

If it were a sure thing it wouldn't be a challenge or quite as interesting.

Re: Update to the .NET language strategy

#142

Earlier quoted context omitted.

Extension methods are "I want a function whose first parameter is this type defined outside, but the programming language shoehornes me so much into classes and objects that I have to do all this extra ~bullshit~ boilerplate to have a function whose first parameter is this type defined outside". Imagine having to create a monad, including the `pure` and `bind` operations every time you want to increment a variable. T…

Weird definition since it misses the point. Extension methods are: I want to add a new method(not function) to object which I dont have control of (in the code sense) So I can call "externalObj.MyNewMethod()", so extend its behaviour

Yep, a weird definition.

"I want to add a new not-a-method (because it can't access private stuff, unlike real methods) so that I can do "externalObj.MyNewMethod()" because doing "myNewOperation(externalObj)" is somehow forbidden."

Re: Update to the .NET language strategy

#143

Earlier quoted context omitted.

Weird definition since it misses the point. Extension methods are: I want to add a new method(not function) to object which I dont have control of (in the code sense) So I can call "externalObj.MyNewMethod()", so extend its behaviour

Yep, a weird definition. "I want to add a new not-a-method (because it can't access private stuff, unlike real methods) so that I can do "externalObj.MyNewMethod()" because doing "myNewOperation(externalObj)" is somehow forbidden."

Of course it cannot access internals because youd break "sane oop"

Re: Update to the .NET language strategy

#144
post #84

Earlier quoted context omitted.

I'm not sure about that given the amount of jobs I have had and found in Elixir, which also has a more vibrant ecosystem. I have strong confidence that I could get another Elixir job. I would be surprised if I could even locate an F# job.

a quick search on indeed.com reveals 78 elixir jobs ( https://www.indeed.com/q-Erlang-Elixir-jobs.html ) and 426 f# jobs ( https://www.indeed.com/jobs?q=F%23 ) I’m sure some false positives, but I doubt enough that brings the F# count lower than that for Elixir. ymmv

[deleted]

Re: Update to the .NET language strategy

#146
post #137
post #95

Earlier quoted context omitted.

What spirit? Kotlin only matters due to Google's shenanigans on Android with Android Java, and pushing Kotlin as its replacement. It is J++ vs C# all over again. They could just as well buy JetBrains.

The spirit of starting over instead of cramming more into an old language, but making the new thing highly compatible with the old thing via transpilers or runtime sharing (Swift with Objective-C, Kotlin with Java).

Wrong analogy, Kotlin with Java is an Android thing, on the JVM there is no Kotlin whatsoever, only another guest language among so many others.

Maybe if JetBrains ever releases their own KVM, which by the looks of Kotlin/Native, is hardly something for the JVM ecosystem to worry about.

Re: Update to the .NET language strategy

#147
post #96
post #14

Earlier quoted context omitted.

First class. I would wager that most new .NET projects are primarily targetting Linux for deployment.

Not really, plenty of VS tooling doesn't exist on VS4Mac nor VSCode. GUI frameworks don't consider Linux a deployment target, not even MAUI with its Xamarin heritage. Due to its Windows original focus, lots of libraries still rely on Win32, COM and other Windows specific issues. This also inhibits most big name CMSs, which still rely on .NET Framework, e.g. Sitecore, SharePoint, Dynamics,.... Targeting Linux containe…

Not quite true, people can choose to use other tools that do work well cross platform e.g. Rider. VS and VSC agent the only ponies in town.

I don't even use VS on subdued installs anymore, it's no longer the better option.

Re: Update to the .NET language strategy

#148
post #39

Earlier quoted context omitted.

At work our C# codebase never touches Windows (all developers except me use MacOS, I am testing Linux). Production is Linux. We all use Rider, which pretty good (but extremely crashy when debugging). Probably in the region of 500Kloc.

curious: what led the company to choose the CLR/C# over the JVM/Java?

I wasn't around when the decision was made. However, we moved from Ruby to .Net. I'm not sure if Java was ever even a consideration.

Re: Update to the .NET language strategy

#149
post #7

TLDR: C# is our real language. F# is a thing that gets supported to the extent that unpaid volunteers do the work. VB is in back-compat legacy support mode.

When the average enterprise starts using F# regularly, maybe it will get the same TLC as C#. Lots of complaints about F# being the red headed stepchild but people seem to miss the fact that C# absolutely dominates on the list of languages the average Windows/Microsoft shop is using.

Re: Update to the .NET language strategy

#150
post #80

Earlier quoted context omitted.

Where does TypeScript fit into this? It's a wildly successful language from Microsoft that's also interpreted but doesn't use the CLR. Disclaimer: I work at Microsoft, but not in the Developer Division.

Start a petition for T#. Merge C# and TypeScript. I want my C# pattern matching in TypeScript and TypeScript's fluidity in C#. Simplified initialization in C# without new(). Unless otherwise specified, use a default generic Dictionary and infer the types for map initialization like: var x = { ["a"] = 1 }; Instead of: var x = new Dictionary {...}; Then automatic type mapping and conversion utilities to objects: record…

Let’s get started then! I’m digging this T# idea
Post reply on HN