Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

F# is gaining independence from .NET

onurgumus.github.io

Post reply on HN
Print view View original

141–150 of 181 posts

Re: F# is gaining independence from .NET

#141

Post by TurkTurkleton »

ecshafer wrote: post #113
samus wrote: post #100

Earlier quoted context omitted.

This is a bit inappropriate since for a long time now Java was busy catching up to C#. When Project Valhalla merges, Java's type system will become very close to what C# is now: reified generics and first-class value types. Algebraic data types will also come to town. But only after Project Loom merges, Java will be firmly ahead again with a fresh take on all matters async.

But C# was literally Microsoft's Java implementation that they forked after they were sued by Sun, was it not? So it is quite appropriate.

Microsoft's Java implementation that got them sued was J++. As part of the settlement, they weren't allowed to add any new features to it, and it quietly faded into obscurity, along with its CLR counterpart J#, the latter having finally left even extended support in 2017.

C# was developed independently of J++ and J# (though J# was based on J++ to provide a transition path for J++ developers), and although Anders Hejlsberg (original lead architect of C#) did also work on J++, he also worked on Turbo Pascal and Delphi before coming to Microsoft, and I'd suspect that those influenced C# more (more conceptually than syntactically, of course).

Re: F# is gaining independence from .NET

#142

Post by Smaug123 »

moron4hire wrote: post #98
tentacles wrote: post #43

Earlier quoted context omitted.

You do it in the .fsproj. I wish Microsoft would add a warning to explain that, instead of just saying the modules can't be found. Really confused me for a good few hours.

My general feeling is that, if you can generate a warning that tells you the right thing to do, then the compiler should just do the right thing.

That works right up until it doesn't. For example, if you have two interacting places where the compiler has guessed what to do, maybe the compiler resolves the interaction in the wrong way. It's the same problem that arises if you don't commit after merging into a Git repository (which, by the way, is possible but takes explicit opt-in): it keeps on working fine up until two previous merges conflict with each other.

I much prefer Rust's approach, which is to fail out but also make it extremely easy to apply the fix the compiler has guessed.

Re: F# is gaining independence from .NET

#144

Post by reverseblade2 »

kingdomcome50 wrote: post #139
reverseblade2 wrote: post #138

Earlier quoted context omitted.

OP here, it's a great question indeed! Now let's forget about elm/elmish but we are to write a stateful application. It doesn't have to be a web app, just any application needs to hold some state. And that state should be modifiable (Not to mention we will have side-effects as well.) in order to do something useful but we also want to stay on the Functional programming realm to get benefit from things like immutabili…

I understand what you are saying. I'm not sure how your points are at odds with the OOP counterpart I describe though. The essence of your response seems to be "because we want to use a pure FP paradigm" to which _I_ would add "despite a clear downside to which F# has the capacity to avoid". If the framework only expects every `Model` to contain 2 methods (`view`, `update`) and never any more (which is the case), I s…

let (model', cmd') = state.update msg

In order to write that you have to pin a reference to the state. But state is something that has to flow. Sure you can pin it to a ref, make it mutable and change the state but then nothing prevents you to change the state arbitrarily e.g. from a command. I believe yes the answer is because we want to stay on the FP realm. FP imposes some restrictions to keep our sanity. So not having a reference to the state and making it immutable is one of those restrictions.

Re: F# is gaining independence from .NET

#145

Post by hctaw »

Cybiote wrote: post #115
adenozine wrote: post #30

If F# ever got something akin to Scala Native, or Kotlin Native, I think it'd do really well. In my limited understanding of the F# ecosystem, I don't believe there are a lot of voices calling towards a multiplatform future beyond the NET world. Fable is cool, but native is a must-have for a lot of people, myself included. The docs are bad but not inexcusably so, it's a nice project within MS, I get it. The underlyin…

I think the best way to think about such things is in terms of niches and ecosystem. The niche of functional and native is small and already well served by Haskell, Ocaml and even Rust to an extent. The .net, python and JVM contain some of the largest ecosystems. Even if small relative to C#, the niche size and health of a functional language on .NET is much larger than if it were another native langauge. Speed, docu…

Pure anecdote, but I've never seen a project become less native.

Meanwhile state of the art JITs (for .NET, JVM, Swift, and other traditionally managed runtimes) are increasingly blurring what it means for a language to be native and what the benefits for "native" even are.

So I don't think it's useful to think in terms of niches, because niches are constantly disappearing within our ecosystems. We're reaching a point where the implementation of a language is mostly a solved problem (throw it on top of some JIT for a bigger language) and the only meaningful innovation is in the semantics and syntax of a language for expressing intent and providing soundness.

If we're skating to where the puck is going here, I wouldn't say it makes sense to ignore native compilation for functional languages because that's a well served niche, but because AOT compilation itself is becoming niche.

Re: F# is gaining independence from .NET

#147

Post by orra »

xupybd wrote: post #20
orra wrote: post #9

Earlier quoted context omitted.

Cough : https://docs.microsoft.com/en-us/dotnet/fsharp/tools/fsharp-... Should be a bit easier!

Thank you! Gah lots to learn.

:-).

F# tooling (e.g IDE support) is infuriatingly not as good as C#. Yet at the same time, the tooling is pretty decent, especially for a functional language.

Re: F# is gaining independence from .NET

#148

Post by kingdomcome50 »

reverseblade2 wrote: post #144
kingdomcome50 wrote: post #139

Earlier quoted context omitted.

I understand what you are saying. I'm not sure how your points are at odds with the OOP counterpart I describe though. The essence of your response seems to be "because we want to use a pure FP paradigm" to which _I_ would add "despite a clear downside to which F# has the capacity to avoid". If the framework only expects every `Model` to contain 2 methods (`view`, `update`) and never any more (which is the case), I s…

let (model', cmd') = state.update msg In order to write that you have to pin a reference to the state. But state is something that has to flow. Sure you can pin it to a ref, make it mutable and change the state but then nothing prevents you to change the state arbitrarily e.g. from a command. I believe yes the answer is because we want to stay on the FP realm. FP imposes some restrictions to keep our sanity. So not h…

> In order to write that you have to pin a reference to the state

Forgive my ignorance, but why is that the case? Isn't `state` being passed into the loop?

Mutability is orthogonal to the question of where one defines a unit of behavior. Maybe an immutable object is not possible to achieve in F#, but one could certainly imagine the concept of an immutable type with methods. My question is more about the modes of organization: Large unions vs discrete modules and how they affect how one's ability to change a program over time.

If you say that the architecture was chosen out of a purest sense of FP, then fair enough. I can understand why someone would go that route. Just had to know.

Re: F# is gaining independence from .NET

#149

Post by phillipcarter »

danyx wrote: post #34

I also like F# a lot and have used it professionally for 3 years now. I wrote down my own take on learning F# in a post "What I wish I knew when I learned F#" http://danielbachler.de/2020/12/23/what-i-wish-i-knew-when-l... . Maybe this is a helpful additional perspective for some.

This is an excellent blog post! Thanks for writing it.

Re: F# is gaining independence from .NET

#150

Post by Gene_Parmesan »

naringas wrote: post #65
cies wrote: post #44

Earlier quoted context omitted.

Isn't F# pretty much OCaml.NET? So if you want native, you may also go with OCaml (or ReasonML if you prefer curly-delimited code blocks). For frontend dev't I really like Elm lately. (the article makes many refs to Elmish, the Elm-on-F# project).

similarly to how C# is very much java.net ??

I actually find C# to be more like "the successor to C++ that I actually want" rather than "Microsoft Java" at this point. If you approach C# as if you're just programming Java you are going to be missing out on some nice features, such as structs, unsafe blocks (including pointers), and modern additions like pattern matching. On top of that, I find that I prefer certain things about C#'s implementation compared to Java - reified generics over type erasure, for instance. Apparently Project Valhalla will change some of this implementation stuff. But for a while now I've found C# to be ahead of Java.

The syntax is also way nicer. Having to type out "implements/extends" instead of ":", for example. These goes a long way to denoise a very noisy language.

Post reply on HN