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

121–130 of 181 posts

Re: F# is gaining independence from .NET

#121

Post by pjmlp »

txdv wrote: post #111
pjmlp wrote: post #71

Earlier quoted context omitted.

Well neither Scala Native, nor Kotlin/Native are examples of world changing projects, so thankfully F# hasn't gone down that route. In fact, Kotlin/Native is a poster child example of how not to design a language breaking the memory semantics with the rest of the eco-system.

Can you elaborate more on "In fact, Kotlin/Native is a poster child example of how not to design a language breaking the memory semantics with the rest of the eco-system."?

Sure, when Kotlin/Native was introduced they had the clever idea to force a memory model incompatible with what any JVM written code would be expecting, so you need to explicitly write Kotlin/Native aware code.

https://itnext.io/why-the-kotlin-native-memory-model-cannot-...

Naturally this wasn't going to turn out well, and now they are redoing it with a proper GC.

https://blog.jetbrains.com/kotlin/2020/07/kotlin-native-memo...

Re: F# is gaining independence from .NET

#122

Post by nojito »

hawk_ wrote: post #78
nojito wrote: post #76

Earlier quoted context omitted.

> Fable is cool Fable is a game changer and is arguably a better Typescript in terms of jacking into the javascript ecosystem. Ruby had Rails, Python had Django + Pandas..... F# has Fable

how is fable better than ts, could you elaborate?

F# users generally avoid hierarchal type systems that plague TS/C# etc.

Don Syme has a great talk about this, but essentially things get out of hand very very quickly.

https://youtu.be/1AZA1zoP-II?t=2408

With Fable you are able to take the simplicity and conciseness of F# and jack into the entire JS ecosystem without falling into the type hierarchy nonsense.

Re: F# is gaining independence from .NET

#123

Post by buybackoff »

buybackoff wrote: post #96
Smaug123 wrote: post #85

Earlier quoted context omitted.

F# does a good job with tail-recursion, though - you can make the for/while loop safer this way. https://www.gresearch.co.uk/article/in-favour-of-recursive-f...

But it adds .tail prefix before every callvirt instruction and this breaks some JIT optimizations. E.g. generic type specialization 'if(typeof(T) == typeof(...))' breaks, I had to dig into compiler source code to find out that it doesn't add .tail before ctors, used a struct wrapper and called a method in the struct ctor to avoid .tail prefix, but it adds its own overhead. Also, most simple tail calls are rewritten b…

Slight correction: .tail prefix prevents inlining by JIT, it's mentioned in the second link in my sibling comment as "explicit tail prefix in callee". So even if that type specialization JIT optimization worked, the small performance-critical method containing it was not inlined. But the point of the specialization was to make the call for primitives faster than a method call, and fallback to a default implementation via callvirt. And there is no way to disable adding the .tail prefix to the calls that do not need it.

This also means that a lot of F# functions that are not inlined by F# source-code inlining itself effectively have NoInlining attribute. E.g. some helper method `if x then y.call() else z.call()`, if not inlined by F#, will never be inlined by JIT due to .tail prefixes before the methods calls.

Re: F# is gaining independence from .NET

#124

Post by dleslie »

paavohtl wrote: post #40
dleslie wrote: post #14

Earlier quoted context omitted.

It's possible to write functional C# code, as well.

Ehh, not really. It depends on how you define functional programming. C# supports first class functions, tuples, some form of pattern matching and LINQ extensions support basic FP collection operations like map (Select), filter (Where) and fold (Aggregate). But I think that's just scratching the surface compared to a "real" FP language: - F# has function composition operators - F# functions are curried and support au…

That stinks of microallocations from enormous stacks of closures, boxing and similar.

Re: F# is gaining independence from .NET

#125

Post by FpUser »

reverseblade2 wrote: post #110
FpUser wrote: post #75

>"You have to embrace functional programming as a paradigm." Why would I embrace/commit to any particular paradigms? I would use whatever I believe is best suitable for particular task. All those are just tools like a screwdriver. They're here to work for us, not the other way around.

Sure, but functional programming requires some discipline and restrictions for a greater good. It's certainly a choice though.

>"Sure, but functional programming requires some discipline and restrictions for a greater good"

I do not care about some generic "greater good". It does not exist. In my context "greater good" is delivering products while satisfying business and technical constraints of a given customer/s to a reasonable degree.

Re: F# is gaining independence from .NET

#126

Post by reverseblade2 »

jayonsoftware1 wrote: post #116

Is their a good F# book that will teach functional programing. Every F# book i see are trying to teach the syntax.

I am the author of the post and author of this https://www.udemy.com/course/learning-functional-programming...

Don't be deceived by low rating. It's low because people expected a course on syntax.

Also other continuations are as below:

https://www.udemy.com/course/functional-application-designin...

https://www.udemy.com/course/end-to-end-real-world-applicati...

And if you have any questions find me from @OnurGumusDev on twitter and I will gladly help

Re: F# is gaining independence from .NET

#127

Post by Jtsummers »

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.

C#'s development was motivated by their relationship with Sun, but J++ was MS's non-conforming Java implementation. They were sued for it, and basically couldn't develop it any further (with regard to maintaining Java compatibility, to the extent that they cared to at least).

Re: F# is gaining independence from .NET

#128

Post by mumblemumble »

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…

Concrete example: for my latest side project, I chose F# because it was the most compelling (to me) language with a decent option for cross-platform GUI that isn't Electron. (Avalonia.FuncUI, which has a nice Elm-y feel.) The reason it had a good cross-platform GUI library available in the first place is very much because it lives on .NET, and can build on of the rest of the .NET ecosystem.

Re: F# is gaining independence from .NET

#129

Post by hardwaregeek »

DanielBMarkham wrote: post #49

"...If you are sold with F# there is one important point to highlight. Do not treat F#, just another language with different syntax especially if you are familiar with Python, Ruby, JavaScript, C#, etc. You have to embrace functional programming as a paradigm...." I want to provide a little nuance around this, because I'd give the opposite advice. Because F# is based on OCAML and an extremely popular IDE/framework, i…

I had this happen with Rust. My Rust code as a beginner had a bunch of smells like unnecessary copies, overly verbose code, etc. But in the Maslow hierarchy of programming, working code is a prerequisite for idiomatic code. Better to write some bad, working code and slowly turn it into idiomatic, working code.

Re: F# is gaining independence from .NET

#130

Post by patrec »

toolslive wrote: post #52
adenozine wrote: post #50

Earlier quoted context omitted.

Yes! Ocaml is quite good. Concurrency is kinda poor, but it's coming along. I am glad that Elm has influenced so many ecosystems. I wouldn't touch it with a ten foot pole because of the author, but I think the ideas of the project are invaluable and long overdue.

concurrency is excellent in OCaml (Lwt, async, ....) it's just paralllelism that's a problem. multi core ocaml will eventually fix that.

You make it almost sound like having a fractured eco system with two different incompatible async frameworks is a good thing! :P
Post reply on HN