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

Why F# evangelism isn't working (2015)

ericsink.com

Post reply on HN
Print view View original

281–290 of 333 posts

Re: Why F# evangelism isn't working (2015)

#281

Post by xmonkee »

jayd16 wrote: post #89
muglug wrote: post #32

Progamming language evangelism is basically a zero-sum game. Some languages don't really intrude on one another's territory — e.g. not that many people are rewriting Ruby programs in Rust — but some very directly compete. So if you want to convince someone to use F#, you have to convince them it's significantly better than some other closely-related language. And that's hard! I have a strong suspicion that the next d…

C# will stay because Microsoft will push it. Honestly what makes Go so special? I could see another language or even Java or C# get their AOT story together and retake what was lost to Go.

Garbage collected "modern" language that builds native binaries? There is very little that can compete with that. I don't really like Go, but if I ever need to write a binary I will reach for it, because I don't really want to do manual memory management (even the rust type). My needs are rarely that performance oriented.

Re: Why F# evangelism isn't working (2015)

#282

Post by jayd16 »

xmonkee wrote: post #281
jayd16 wrote: post #89

Earlier quoted context omitted.

C# will stay because Microsoft will push it. Honestly what makes Go so special? I could see another language or even Java or C# get their AOT story together and retake what was lost to Go.

Garbage collected "modern" language that builds native binaries? There is very little that can compete with that. I don't really like Go, but if I ever need to write a binary I will reach for it, because I don't really want to do manual memory management (even the rust type). My needs are rarely that performance oriented.

Like I said, Java and C# have single binary AOT builds coming down the pipe. Shops could end up gravitating away from Go for this reason.

Re: Why F# evangelism isn't working (2015)

#283

Post by recfab »

throwaway2037 wrote: post #154
KingMob wrote: post #149

Earlier quoted context omitted.

Agreed, I think people are sleeping on the relative disparities in tooling between langs, and it will only get worse. I feel this daily as a Clojure programmer. I've been playing with Copilot, and it's astonishing how much worse Copilot is at generating Clojure code, than say, Js. The difference is probably due to training volume, and if AI-assisted coding is worth it at all, the benefits will primarily accrue to the…

At the office, a teammate and I recently had to write some C# again using Visual Studio. (Normally, we write Python and Java using JetBrains' IntelliJ.) Even then, we could both notice the developer experience was slightly worse in Visual Studio, than IntelliJ. That said, there are lots of nice (new) language features in C# to make-up for the difference!

In case you haven't seen it already, JetBrains also makes a C# IDE called Rider [0].

Personally, I find the JetBrains IDEs overly complicated. More so than Visual Studio, but that may be familiarity. (Also, I use VSCode for .NET these days so full IDEs feel heavy to me anyway.)

[0]: https://www.jetbrains.com/rider/features/

Re: Why F# evangelism isn't working (2015)

#284

Post by CrimsonCape »

systems wrote: post #113
CrimsonCape wrote: post #91

Earlier quoted context omitted.

I empathize with your characterization of "a tree of object/classes" and I yearn for an example of how else to model a complex, domain-specific system not using the aforementioned tree.

relational model, like we always did and do everyday (in the db realm) i am not saying we should not use trees ever, i am mainly saying, when the model is a very deep tree (or several deep trees and trees everywhere), its becomes overly complex data models should be as flat as possible , and only nested when absolutely necessary

Yes, and my yearning was for examples in which the domain objects are complex systems or machines themselves.

To your point, if the domain is a payment system, I can keep separate db's of Customer Info, Customer Purchases, Transaction Instances, Customer payment methods, etc. This seems like a domain suitable for functional code.

If the domain is a two stage orbital rocket, in which we must have a stateful system that has internal feedback loops (fuel consumption, vehicle trim, time of flight, time before stage separation, engine sensor data), our best software design is an object graph which causes spaghetti code ( does the navigation system belong to the electrical system, or the radio system? Wait, does the radio system belong to the electrical system? Wait, does the entire electrical system belong to the solid fuel system, since the electrical system is dependent on the generators partially, but what about the battery system? What critical components stay on the battery system if the generators are shut down?). I guess my point is, real life is a spaghetti relationship.

Consider the recent ISpace probe crash. The article says "software bug" but in reality it's more of a 'design flaw' and I would bet it's exactly because of the topic of this thread. The sensors were reading correct data, but the design/validation of the intercommunication data between sensors was designed wrong.

https://www.nytimes.com/2023/05/26/science/moon-crash-japan-...

Re: Why F# evangelism isn't working (2015)

#285

Post by _gabe_ »

michielr wrote: post #144
pharmakom wrote: post #131

Earlier quoted context omitted.

I used to write lots of C#, but now I consider it a bad ecosystem. The problem is the amount of ceremony, silly OOP abstractions, dependency injection, etc. Just look at building a simple HTTP endpoint in C# compared to Node or even F#!

I agree this was a problem, but with the current Minimal API's, there is no boilerplate, looks a lot like Express to me! var builder = WebApplication.CreateBuilder(args); var app = builder.Build(); app.MapGet("/", () => "Hello World!"); app.Run();

>> The problem is the amount of ceremony, silly OOP abstractions, dependency injection, etc.

Your code snippet certainly has a lot of unnecessary ceremony. Why use a builder object at all? Why use a static class with a function to build the builder object?

  var builder = createBuilder(args);
  // etc...
Would be better. But

  var app = createWebApp(args);
  // etc...
Is even better. No ceremony at all!

Re: Why F# evangelism isn't working (2015)

#286

Post by Aeolos »

rgbgraph wrote: post #265
otto-edgar wrote: post #196

Earlier quoted context omitted.

What do you find insane about the C# `List` source code? I'm not a C# programmer, but the public API looks sound, and the entire thing is like 1K LOC including docstrings (I guess the inherited code would add to that).

List is an IList/IReadOnlyList; these interfaces do nothing that couldn't be done right inside the file itself. https://referencesource.microsoft.com/#mscorlib/system/colle... https://referencesource.microsoft.com/#mscorlib/system/colle... Instead we have to go diving through the IList, which implements ICollection, which implements IEnumerable, which implements IEnumerable ( again ). Just because each interface is c…

I stopped using C# & F# almost a decade ago, but there are some relevant pieces of information that answer your questions:

1. Optimization is primarily handled by the .Net JIT, not the C# compiler. That allows F#, C#, VB.Net and other runtime languages to share similar performance characteristics without duplicating effort.

2. Docstrings are used by the IDE to help the user. That avoids the need to read the source code itself for regular usage.

3. When comparing the .Net List implementation against any C++ std::vector implementation, the former looks quite tame in comparison...

Re: Why F# evangelism isn't working (2015)

#287

Post by progmetaldev »

ThinkBeat wrote: post #127
ericsink wrote: post #68

(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.

C# in its current state has IMHO acquired many features from F#. You can get close to writing purely functional code in C# now. I think with all the changes and extensions over time to add ever more features to C# so you can write whatever paradigm you want in it is a bad idea. I would much have preferred to keep C# OO and use F# when you want to go functional. Or just create G# which is the everything mashed togethe…

I don't dispute your claims, as they are subjective. I do know that I enjoy a lot of the functional aspects to C#, but I think it's something where you need to have a real discussion with your team and decide a coding style and feature implementation for your code. If your team can't all speak the same dialect, you're going to have issues. Having seniors able to work with juniors and discuss the functional aspects, as well as when to use things link LINQ, goes a long way towards a consistent and easily understood codebase. I know not every shop has this luxury, which is why I still agree with your statement.

Re: Why F# evangelism isn't working (2015)

#288

Post by progmetaldev »

pjmlp wrote: post #162
ericsink wrote: post #68

(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.

F# also tried to pivot into data science of lately, only to have Microsoft themselves jumping into Python and being the entity that finally managed to convince Guido and others to invest into improving CPython's performance, and possible JIT integration. Basically having the pivot efforts being sabotaged by the same company.

I am only scratching the very surface of data science, but coming from .NET 1.0 and just starting to learn Python, I'm still finding it far easier to use Python for these tasks. It's most likely just the library ecosystem, and I'm hoping that Microsoft continues to add officially supported libraries to .NET for these tasks. ML.NET feels very foreign to me compared to using other libraries in Python, even as a beginner in Python (although I have experience with various languages, but only minimal experience in functional languages, mostly F#).

Re: Why F# evangelism isn't working (2015)

#289

Post by progmetaldev »

WorldMaker wrote: post #274
pjmlp wrote: post #162

Earlier quoted context omitted.

F# also tried to pivot into data science of lately, only to have Microsoft themselves jumping into Python and being the entity that finally managed to convince Guido and others to invest into improving CPython's performance, and possible JIT integration. Basically having the pivot efforts being sabotaged by the same company.

Microsoft has always been a polyglot company. They also invested heavily in R and I believe even contributed some things to Julia. I don't think the pivot entirely failed, there's definitely a small niche for "data science, but it needs to run in .NET" and F# still to my understanding fills it well. It's a very small niche and I don't expect to hear a lot of data scientists directly training for it, but there's a lot…

I think if Microsoft would have continued to invest in projects such as IronRuby and IronPython, we'd be much further along in integrating different paradigms in a way that feels more natural, while also continuing to grow the DLR (for both features and performance).

Re: Why F# evangelism isn't working (2015)

#290

Post by devmunchies »

UncleMeat wrote: post #272
devmunchies wrote: post #129

Earlier quoted context omitted.

The worst part of OOP is that all the properties of an object can be a mishmash of values and are mutable. In any method, you never know if the object is in some undesirable state without checking properties within the method itself. Multiply that headache across all methods and all other classes and it becomes a mutable mess. It makes it weird that we pass around objects as types when they encapsulate so much state…

This isn't a property of OOP. This is a property of poor class design. You absolutely should be designing classes such that every possible sequencing of their public methods leaves them in a valid state and maintains their invariants. Structs have the issue you describe and they aren't really OOP. Yes, if the first thing you do when you write a class is make a setter method for each field then you will have problems.…

Poor class design IS a property of OOP.

All of these logical errors that are easy to commit are terrible because they are usually runtime bugs, not compile time.

As I think of it, I think a neat feature of OOP would be conditional methods that are only callable under specific circumstances. For example, the “Customer.SendPasswordResetEmail()” method couldn’t be called (or didn’t even exist) until I verify that the “Customer.IsEmailVerified” property is true.

Being able to add these type of annotations to methods for expected object state would help catch some logic bugs at compile time.

Post reply on HN