throw868788 (u/throw868788)

throw868788 commented on Official proposal for Type Unions in C# github.com/dotnet/csharpl... · Posted by u/Fervicus

wk_end · a year ago

Instead of C#, why not F#? You get proper ADTs among many other great features, but you still get all the utility of the .NET ecosystem.

throw868788 · a year ago

Indeed. The company I work for uses F# for large revenue workloads across many services; mostly coming from non .NET dev's. It handles large scale customer traffic quite well without a hiccup and with the C# interop we never find we are blocked (e.g enterprise/vendor libs). They found it easier to learn F# than C# - it has a lot more in common with JS/Go/etc in how code is structured and maintained from their POV. Good mentorship is critical for learning and deriving extra value from it especially if coming from old C#/Java/etc. The push for C# to minimal APIs, less classes, etc from our experience has slowly made it less necessary to have F# wrappers as well - the interop ugliness usually only resides in one file (e.g. ASP.NET Startup.fs or equilvalent in given C# framework). Given our proprietary nature however we don't broadcast a lot of our dev effort/development online - I assume many F# shops are/were similar.

We've created very large scale applications in it requiring significant throughput. One of its benefits is also its disadvantages - we typically are quite productive in it and so don't feel the need to hire as many people in the team. Before LLM's were a thing we found we were wasting less time with boilerplate in general than our C# code for example. YMMV.

throw868788 commented on Clojure's machine learning ecosystem codewithkira.com/2024-04-... · Posted by u/kmclean

Capricorn2481 · 2 years ago

I don't even care about the runtime, imagine if F# devs made anything that wasn't on top of Asp.net. The small community coupled with breaking changes from Asp.net leads to a lot of issues, and the interop story of F#/C# and Clojure/Java is night and day

I like Asp.net, but the thing I've run into several times in F# is there are breaking changes in libraries that the developers of F# can't keep up with.

- Giraffe doesn't support swagger docs, you have to use Asp.net directly, because the swagger generation isn't compatible with the way Giraffe does routing

- Microsoft Identity uses EF core by default. The EFcore.FSharp library doesn't support past .NET 6. You could use your own backend, but at this point, it's easier to just use C# interop

You could use C# for the routing of your app and F# for the business logic. But then there's the C#/F# interop story. Lots of little finicky type differences you have to convert. Whereas using Java from Clojure feels easy and natural to me.

And even if you use Asp.net directly and do interop correctly, you're basically using C# at that point. You're missing a lot of benefits of a functional language. It's not worth it in my opinion, even though F# is a wonderful language to me.

It's tough to learn the ecosystem in Clojure. But once you do, I've found the "small libraries" approach much better than the whole ecosystem tying itself to one web framework it can't even keep up with.

throw868788 · 2 years ago

Its funny because I've found the opposite; the fact that the smaller community (and lets face it - most FP langs have a much smaller community than needed to get the scale you are after) the more it needs to piggy back on the army of engineers in the mainstream language target and stick to only its value add as a technology. There were web frameworks in F# that were written from scratch, but fundamentally ASP.NET is quite good and fast enough at least from my evaluations and these frameworks are now out of favor.

I personally don't have much issues using ASP.NET directly from F# (don't bother with Giraffe or anything like that); its not too hard. The routing layer is only a few classes/functions anyway - it isn't the majority of your program. I guess maybe I'm in a different position to you - I find for the few bits of ASP.NET config it isn't worth switching to C#. A few rules you need to follow but I would say that is a lot less than the Clojure learning curve and you get static typing still - that is just my opinion however.

My experience is that both languages have their pros/cons and tbh both have their challenges w.r.t adoption. My personal view is most of these challenges are not technical. The issues we complain about with the language as developers are IMO minor (i.e. things are still possible or decent compared to some other languages) and probably aren't the major factor in the wide scale technology choice away from FP in general.

For better or worse developers are often "languages takers" not "language deciders" in most big shops and this is where most of the jobs are - its only in niche elements/problem spaces (i.e small shops, dedicated niche teams, etc) where niche technologies can be worth it. This means not a lot of jobs; but when there is a job it can be higher paying. Big employers drive the market for technologies though when it comes to large scale usage and they want commodity fungible developers (i.e. resources), and are happy using a mediocre tech that gets the job done to do it. Unless there is a "killer app" where the language must be used to unlock the value most managements will stay clear of better tech - predictable, boring, commodity tech that I can get anyone in for (contractor, offshore person, etc) wins for them every time especially for the MBA/product manager/etc types. In the current economic climate developers are trying to meet the jobs that are being advertised as well (higher interest rates, less startup's, etc etc).

throw868788 commented on Clojure's machine learning ecosystem codewithkira.com/2024-04-... · Posted by u/kmclean

nextos · 2 years ago

I would not say it is such a small niche. There are job openings here and there. It is much easier to find a Clojure job than a F# or a Haskell job in my experience. This may be of course different depending on your location.

The problem is that an entire ecosystem is more than just a new language. Clojure has some really interesting libraries, but the rest relies on Java. It is a good ecosystem nonetheless. Julia is having the same issue. It has grown a very respectable ecosystem, but it is hard to grow further to catch up with Python in some fronts without massive corporate funding.

It is interesting to note that, at some point circa 2010, it looked like Clojure could revive Lisp-Stat with Incanter. But, eventually, the project declined in popularity and died. Reaching mainstream relies on getting a critical mass of developers at the right time and for the right domain.

throw868788 · 2 years ago

I do think this depends on region, as I've seen F# and Scala jobs typically outnumber Clojure for example depending on whether it is a .NET or Java shop. Mileage does vary.

However to be honest anecdotally I do think even if they aren't going down in user terms, FP languages are losing percentage market share. From my personal experience FP is no longer new; the hype of FP in general has died down. The hype has moved onto other things over the years (e.g. AI, blockchain, bare metal technologies that enable the above, etc etc).

I'm not saying FP doesn't have a lot of value. I enjoy, particularly when the program calls for it, FP languages like F#, Scala, etc. They still offer a lot of value IMO for all the usual spouted reasons.

IMO I just think the hype has moved from technologies that do things better (i.e. more efficient, less error prone, makes my job easier, etc) to technologies that do shiny new things. There are a lot of reasons for this, many of them aren't in fact technical but economic and political (e.g. management). Things like less jobs globally in tech (meaning my skills need to have wider reach), demand for specialist roles that aren't as language focused, etc play a part. Mainstream languages taking FP features as well makes the return vs risk of using a FP language even worse of a tradeoff - there's less perceived return for changing stack than before.

throw868788 commented on Why F# evangelism isn't working (2015) ericsink.com/entries/fsha... · Posted by u/luu

ericsink · 3 years ago

(Author here)

Well this is a blast from the past.

Back when I wrote this, I kinda hoped F# would surprise me and gain more traction than I expected. But 8 years later, if anything, it seems like the dominance of C# in the .NET ecosystem has grown.

F# is still a great language, but the main fact hasn't changed: C# isn't bad enough for F# to thrive.

throw868788 · 3 years ago

Would be interesting to see actual stats in F# usage which I doubt are relatively available. Given the reaction to this post from what is an old article there's still probably an underground interest in the language and some use in general. People seem to have built strong views on it either way. Especially with some posters admitting they use it professionally with a closed source culture (finance, insurance, etc). Most metrics would not be accurate given interoperability with C# - e.g Google searching I would typically look up C# code and port it for example.

Maybe it doesn't need to thrive for everyone; maybe it just needs to continue being useful for the people who employ it and add value. That's probably OK. They could be just busy building stuff instead of blogging, especially if the community is mostly compromised of senior developers (10 years +).

throw868788 commented on Why F# evangelism isn't working (2015) ericsink.com/entries/fsha... · Posted by u/luu

banashark · 3 years ago

I find it interesting to compare F# with Kotlin.

F# had Jet as the one large success story of a full f# shop, but outside of that there weren't many large companies using a lot of F# (except microsoft internally, and they didn't blog about it _too_ much).

Kotlin on the other hand is seeing server-side adoption in quite a few large companies. Google is recommending it as the server-side JVM language for new services going forward. Airbnb and a handful of other large companies blog about having kotlin services in their architecture.

There's a few reasons I think Kotlin is succeeding where F# hasn't been able to:

* JVM + tooling is a proven and great ecosystem. First-class support for most of your cloud tooling and databases (AWS, Kafka, ElasticSearch, Cassandra, etc).

* It has fantastic editor tooling (given that an IDE company created and maintains it). F# for quite a while has had less-than-average tooling (it's gotten better now with newer versions of FSAC, Ionide, and Rider, but it was _rough_ for a while). It's hard to move to something new that's supposed to be safer when your language server has memory leaks or breaks every X hours. I remember stretches of time where I was just writing F# in vim without syntax highlighting because any editor I tried would constantly throw errors in the middle of me coding. That hasn't happened to me with Kotlin.

* It's close-enough looking to a scripting language with nice features that it's more approachable. Classes and functions look similar to other languages. It even has block parameters that are inviting for rubyists (although the implementation is different). It also has some syntactic sugar to make some things very ergonomic to work with.

* All of the above just works. No big fiddling necessary. The pain points in working with the Java ecosystem are written about and known (largest that come to my mind are coroutines interacting with java threading, exceptions in mixed coroutine/threading environments, and null/optional which Kotlin has some great features built-in to work around).

There's also things like arrow-kt and http4k for those desiring the more functional side of things.

The one thing that continues to baffle me is how little I see in people talking about kotlin in various communities (slack, discord, reddit, etc) compared to how many people are writing it (both for android and for server-side concerns).

The one upside I'll give is that fable has been much better IME than my experience with Kotlin/js. I also prefer F# from a purely language standpoint, but Kotlin is just better to work with.

throw868788 · 3 years ago

Seems like a common theme that people prefer the F# language, but try to explain reasons why it hasn't succeeded from a technical view. I think the reasons IMO aren't technical but what the author has stated - C# is probably worse (that's my opinion) but people who are working in it don't see the pain. Its marketing, the vibe, etc. Most of the tech issues people state wouldn't be there if adoption was bigger.

This is in contrast to Java which for a significant time wasn't showing any evolution which sparked many alt langs on that platform. Sometimes things succeed but silently, and sometimes things that should succeed just don't and maybe there isn't a real explanation. In fact I think the latter across most products is actually the most common outcome, not just in programming languages.

TL;DR I agree with the article, it suffers from an adoption chasm. Pain and herd safety are important especially when people are considering their career progression.

To your dot points:

* I think F# has .NET which is a "proven" and good enough ecosystem as well. You won't get stuck by picking F# even if it means using a C# library. Have to do the same in Scala/Kotlin and the like typically as well.

* Editor has caught up, my surprise is that you can write with Vim and kinda get away with it - only find that works in terser/scripting like languages anyway unlike C#. It has wrappers and libraries for doing things in a more F# FP manner if you wish although when I was doing F# I avoided them (i.e. I avoid things like ScalaX most of the time too).

* F# has a good scripting story; I've seen F# scripts used quite often by people even if coding in C# to check things and REPL program.

* These days F# just works too mostly. `dotnet new webapi/console/etc -lang F#` and you have a webapi for example.

* There are F# libraries around for similar things (Http, Collections, Async seq, etc). They are probably maintained to the level they realistically need to be, I would argue they still do their singular job quite well. At some point a library just does what it needs to do.

There's things I prefer in the .NET ecosystem as well - value types, inlining, etc. Having said that I seen quite a few people use it professionally to good success but they often don't brag about it and are usually quite senior and reserved about their language choice often citing other worries/risks to a project's success.

throw868788 commented on Guide to Java Virtual Threads blog.rockthejvm.com/ultim... · Posted by u/saikatsg

capableweb · 3 years ago

Authors of Loom seems to disagree with you.

> An alternative solution to that of fibers to concurrency's simplicity vs. performance issue is known as async/await, and has been adopted by C# and Node.js, and will likely be adopted by standard JavaScript. Continuations and fibers dominate async/await in the sense that async/await is easily implemented with continuations (in fact, it can be implemented with a weak form of delimited continuations known as stackless continuations, that don't capture an entire call-stack but only the local context of a single subroutine), but not vice-versa.

> While implementing async/await is easier than full-blown continuations and fibers, that solution falls far too short of addressing the problem. While async/await makes code simpler and gives it the appearance of normal, sequential code, like asynchronous code it still requires significant changes to existing code, explicit support in libraries, and does not interoperate well with synchronous code. In other words, it does not solve what's known as the "colored function" problem.

This is under the section called "Other Approaches" in https://cr.openjdk.org/~rpressler/loom/Loom-Proposal.html

That seems to indicate to me that async/await would be an alternative to virtual threads.

throw868788 · 3 years ago

There are differences between implicit/pre-emptive and co-operative multitasking though and there is probably tradeoffs for each. For Java however, much of the existing API exposes Threads, and locks. How do you introduce better scale of existing threading code without too much porting/changes to existing codebases wihtout significant rewrites? The "we are where we are" problem exists a lot more in Java than say .NET/Node/Go/etc which IMO tips the scales more to this kind of approach.

I think that both approaches solve a lot of the same problems, but there is some problems that fit one paradigm better than the other and I don't think they are entirely mutually exclusive either. I've heard it mentioned with Loom it solves the async "colour" probglem however I think people "overblow" the color problem of the Async API too much. If most things are async it isn't really that painful. I actually like when something is marked "async" and I have to be careful how to use it. How is it async? Can the code run in parallel and join later? Is there race condition potential? Deadlock? How is it actually async, what's it sync vs async behaviour? How do I propogate the need to halt the async operation across multiple layers? Who owns the whole workflow, can I make sure the async context is propagated to that layer so they can cancel it for example?

Probably an unpopular opinion but knowing a method has async behavior, at the type level, could be a feature not a bug. It forces you to handle it at the sync/async junction and think about these things.

throw868788 commented on 'Big Short' investor says white-collar jobs bubble is 'bursting' seekingalpha.com/article/... · Posted by u/type4

spaceman_2020 · 3 years ago

All these people theorizing the end of work have never actually worked in a large company, and don’t understand the motivations of people making hiring decisions.

The larger a company gets, the more careerists it attracts. For careerists, “number of people managed” is a key performance indicator (and a boardroom/resume bragging right).

The human motivations of decision makers - to advance their own careers by being the manager that manages more people - is completely misaligned with these future efficiency hypotheses

As long as that remains true, we will continue to see bloat and companies hiring way more people than they need.

throw868788 · 3 years ago

I see that in places I've worked. I've always resisted growing my team's headcount as I've seen it break efficiency first hand. However I'm well aware it makes our team less noticed, and less attractive when other companies ask what's my current reporting count as a metric of how senior you are.

throw868788 commented on .NET 6 is now in Ubuntu 22.04 devblogs.microsoft.com/do... · Posted by u/styx31

turtlebits · 3 years ago

I still feel Microsoft development experience is pretty poor and has been sometimes hostile in the past, and still don't have much confidence nowadays.

Maybe because it's not a popular language, but the F# experience for me has been bad - tried it two years ago with F# 5, and recently with F# 6. The documentation in both cases was immature/inconsistent to broken.

throw868788 · 3 years ago

I've used F# in a professional job and its fine - on very large scale apps for large corps. There's features in it that I feel make certain apps much easier to write that have no equivalent in C# or C# is just starting to get them. Its also easier to teach IMO than C# since code typically uses less concepts.

The usual features (e.g TP's) that are used to sell the language though I feel are oversold and tbh not the main reason F# users like the language - in fact I think TP's need an overhaul and are a distraction. Inlining code for math (which is just getting an equivalent like feature in the next C#), unions/records together, functions and type inference, leaning to compile time vs runtime dispatch in code style, etc I feel are where its strengths are at. More than features I've found for large scale projects its just easier to spot bad code in F#, less bugs have made it ot Production when .NET teams have tried it, and less of it makes it to code reviews.

I've found F# tooling at least for VS Code more stable than the C# equivalent. But that's not saying much - most languages plugins for VS Code don't feel that stable to me if not JS (e.g. the Java one used to crash on me all the time). In VS Studio, Rider, etc are options.

Documentation should be improved sure especially for people getting into it; but it is the smaller language and documentation goes out of date quickly. This obviously penalises the new starter without a mentor/senior dev to teach them in the job/elsewhere.

throw868788 commented on The Case for C# and .NET chrlschn.medium.com/the-c... · Posted by u/greenSunglass

pjmlp · 3 years ago

The point was the other way around, how to justify the adoption of F# in Microsoft shops, when Microsoft itself isn't sure where to go with it, doesn't invest in better VS tooling for it, and recently behaves as the C in CLR stands for C# instead of Common.

throw868788 · 3 years ago

I think this is a problem with many languages - e.g. Scala, Kotlin, etc. The easier justification really is: Does it fit your problem space? Will you save dev time overall, is it more maintainable using this tool? Do your staff prefer working with one tool over the other? Does it meet business objectives?

I don't think F# will ever be more than niche; that I can agree with you. Not because of any technical reason though; perception and marketing unfortunately does matter. Your points around "investment", etc are to me impressions/metrics around that.

In the end these things are just tools. I'm personally in a team that is doing a lot of generic math, and in our .NET based projects F# seems easier and quicker to get that performance. I know C# preview adds some improvements here but it seems more complicated than the F# approach.

throw868788 commented on The Case for C# and .NET chrlschn.medium.com/the-c... · Posted by u/greenSunglass

pjmlp · 3 years ago

You mean the traditional World Data Bank example that we got to see at each F# conference with little relevance for .NET shops?

What I care about are the code generation libraries that get served alongside NuGet packages with attributes, e.g. the ones used by MVVM, MAUI or Blazor.

throw868788 · 3 years ago

Just use a mixed solution then i.e. why not both? You're picking one thing that F# isn't great at - generated code tooling which IMO isn't in the spirit of many modern languages anyway. I don't get why some C# devs tend to be antagonistic to F#. Not suited to what you use? That's fine but that doesn't mean it isn't good for others. I've seen dev's coming from other languages to F# and thinking its brilliant that would of never approached C#. I agree that each language has its sweet spot. Looking at their feature sets I think:

- Domain modelling, algorithm, business logic, etc is easier with F# in general. C# is getting better than this, but F# is there and has been there for a long time.

- Integrating with build tooling and generation tends to be C# because these tools were designed for that target (i.e not the language itself). The value is in the tooling and the engineering in that - C# just happens to be the target.

Personally with the above I've found most of the logic tends to be in F# with some C# projects for where the packages needs that build tooling support (i.e. not the language or syntax, but for the tooling or other features of Roslyn). An example would be Grpc.Tools. Most of the time these projects can use generated code anyway so the writing of C# can be kept to a minimum - i.e. not one single C# file in the C# project. Besides I think the learning curve/barrier for a language isn't really syntax, or language features - its the libraries to use, the patterns, the ecosystem, package manager, CI/CD settings, etc. Using F# isn't a large cost once you've learnt all those things that are shared which is way more than isn't.