5 ms·

Is it my imagination, or has there been an upswing of interest in F# on HN recently?

2mol 5y ago
Yeah, I blame it on version 5 (and dotnet) and the overall tooling improvements. It has really become an excellent and easy to pick up language, with not too many warts and a very good ecosystem.
- mdm12 5y ago
  And version 6 is about to drop! https://devblogs.microsoft.com/dotnet/whats-new-in-fsharp-6/ https://devblogs.microsoft.com/dotnet/whats-new-in-fsharp-6/
- zz865 5y ago
  I hate myself, 5 years ago I gave up dotnet to move to Java because it was more popular now I'm drowning in Spring beans and wish I never switched.
  - svachalek 5y ago
    Ha, I'd be very interested in seeing a sociology study on Java. There's nothing about the language itself says you need to seize on half a dozen design patterns and beat them into the ground, but that's what every Java project I've ever seen looks like.
    - mumblemumble 5y ago
      I'm also a fairly recent migrant from .NET to Java. My sense is that the root cause of a lot of it is missing features in the Java language itself. There are a lot of cases where in C# I'd have used an extension method, or been able to lean more heavily on generic programming or Expression<T>, but, since Java has no good equivalents of these things, instead I have to break out a design pattern to accomplish the same task. And, once you've cracked that seal, it's sort of an, "In for a penny, in for a pound," type situation. Next thing I know, I'm neck deep in it, and I don't even know how I got there.
      - dunefox 5y ago
        "Design patterns are bug reports against your programming language." - Peter Norvig, https://norvig.com/design-patterns/ https://norvig.com/design-patterns/
        mumblemumble 5y ago
        While I did just criticize Java for lacking some features, I genuinely don't agree with that Norvig quote. It's true that, in a single dispatch language, I sometimes need to use the visitor pattern. And the visitor pattern is a little bit annoying to implement, it's true. But the implication of that Norvig quote is that every single language should implement multiple dispatch, and I simply cannot agree with that. And I suspect that a lot of people who like to invoke that sentiment would not prove to have the courage of their convictions when presented with a situation where Haskell needs a design pattern (sorry, "idiom") in order to work around the fact that it doesn't have dynamic dispatch at all, multiple or otherwise. In general, it's OK for languages to be small and focused, or even to be large and multiparadigm but still draw the line at adding some features. That's not my criticism of Java. My criticism of Java is more along the lines of, Java's a kitchen sink language, and there's nothing wrong (aside from perhaps aesthetics) with being a kitchen sink language, but there are other kitchen sink languages that did a better job of cramming more random crap in more cleanly.
drekipus 5y ago
Tooling and marketing budget improvements I'd imagine
- sbelskie 5y ago
  Tooling for sure. I would be shocked in the marketing budget increased just based on how many recent .NET changes recently exclude F# (e.g. source generators).
zamalek 5y ago
I have yet to learn it myself, but I get the idea that there is a huge amount of people who "shut up and get shit done" with it. Posts on HN tend to bring these people to the surface. The interest has always been consistent, it's just not vocal.
agumonkey 5y ago
it's always been bubbling over here
UglyToad 5y ago
Partly the question which caused me to brush off my trends site [0] and add support for'#' and '+' tokens in the search. Looks like somewhat of an increase but a very spiky baseline. https://hn-trends.eliot-jones.com/Home/Trend?id=f%23&allwords=true https://hn-trends.eliot-jones.com/Home/Trend?id=f%23&allword...
pininja 5y ago
There was a wave of popularity in 2017 as well. I used to work on it full time back then, and enjoyed it a lot. The SQLProvider [0] and other type providers like it are super impressive! [0] https://fsprojects.github.io/SQLProvider/ https://fsprojects.github.io/SQLProvider/
- xupybd 5y ago
  I've done a few little projects with the SQL provider. I worry about maintainability. You can't compile if the schema changes without you knowing about it. I haven't run into any real problems as a result but it does make me nervous.
  - mumblemumble 5y ago
    > You can't compile if the schema changes without you knowing about it. There are those who would argue that making an incompatibility between the database schema and the code that interacts with it a compile-time error instead of a run-time error is a huge win for software quality. I suppose there are situations where you simply can't have access to a database that mimics the structure of the production database during development. In which case, the SQL provider is definitely not the right tool for the job. But it might be worth looking into ways to change how you do things in order to make it the right tool for the job. A SQL database with an unpredictable schema makes me much more nervous.
  - pharmakom 5y ago
    You can save a snapshot of the schema into your repo.
  - piaste 5y ago
    > You can't compile if the schema changes without you knowing about it That's why you don't normally compile against the production database. You version control the database schema and use it to create a local database to compile against. This way you can also test potential future migrations using branches. Compiling against the production database should be done separately, as a kind of free integration test (usually in CI).
Zababa 5y ago
Maybe a combination of churn from Scala, growing popularity of .NET in general with .NET Core, lack of high-level stuff in Go, static typing coming to dynamic languages (especially JS), functional features getting everywhere. Lots of stuff is pointing at it in a way.

2mol 5y ago

Yeah, I blame it on version 5 (and dotnet) and the overall tooling improvements. It has really become an excellent and easy to pick up language, with not too many warts and a very good ecosystem.

mdm12 5y ago
And version 6 is about to drop! https://devblogs.microsoft.com/dotnet/whats-new-in-fsharp-6/ https://devblogs.microsoft.com/dotnet/whats-new-in-fsharp-6/
zz865 5y ago
I hate myself, 5 years ago I gave up dotnet to move to Java because it was more popular now I'm drowning in Spring beans and wish I never switched.
- svachalek 5y ago
  Ha, I'd be very interested in seeing a sociology study on Java. There's nothing about the language itself says you need to seize on half a dozen design patterns and beat them into the ground, but that's what every Java project I've ever seen looks like.
  - mumblemumble 5y ago
    I'm also a fairly recent migrant from .NET to Java. My sense is that the root cause of a lot of it is missing features in the Java language itself. There are a lot of cases where in C# I'd have used an extension method, or been able to lean more heavily on generic programming or Expression<T>, but, since Java has no good equivalents of these things, instead I have to break out a design pattern to accomplish the same task. And, once you've cracked that seal, it's sort of an, "In for a penny, in for a pound," type situation. Next thing I know, I'm neck deep in it, and I don't even know how I got there.
    - dunefox 5y ago
      "Design patterns are bug reports against your programming language." - Peter Norvig, https://norvig.com/design-patterns/ https://norvig.com/design-patterns/
      - mumblemumble 5y ago
        While I did just criticize Java for lacking some features, I genuinely don't agree with that Norvig quote. It's true that, in a single dispatch language, I sometimes need to use the visitor pattern. And the visitor pattern is a little bit annoying to implement, it's true. But the implication of that Norvig quote is that every single language should implement multiple dispatch, and I simply cannot agree with that. And I suspect that a lot of people who like to invoke that sentiment would not prove to have the courage of their convictions when presented with a situation where Haskell needs a design pattern (sorry, "idiom") in order to work around the fact that it doesn't have dynamic dispatch at all, multiple or otherwise. In general, it's OK for languages to be small and focused, or even to be large and multiparadigm but still draw the line at adding some features. That's not my criticism of Java. My criticism of Java is more along the lines of, Java's a kitchen sink language, and there's nothing wrong (aside from perhaps aesthetics) with being a kitchen sink language, but there are other kitchen sink languages that did a better job of cramming more random crap in more cleanly.

drekipus 5y ago

Tooling and marketing budget improvements I'd imagine

sbelskie 5y ago
Tooling for sure. I would be shocked in the marketing budget increased just based on how many recent .NET changes recently exclude F# (e.g. source generators).

zamalek 5y ago

I have yet to learn it myself, but I get the idea that there is a huge amount of people who "shut up and get shit done" with it. Posts on HN tend to bring these people to the surface. The interest has always been consistent, it's just not vocal.

agumonkey 5y ago

it's always been bubbling over here

UglyToad 5y ago

Partly the question which caused me to brush off my trends site [0] and add support for'#' and '+' tokens in the search. Looks like somewhat of an increase but a very spiky baseline. https://hn-trends.eliot-jones.com/Home/Trend?id=f%23&allwords=true https://hn-trends.eliot-jones.com/Home/Trend?id=f%23&allword...

pininja 5y ago

There was a wave of popularity in 2017 as well. I used to work on it full time back then, and enjoyed it a lot. The SQLProvider [0] and other type providers like it are super impressive! [0] https://fsprojects.github.io/SQLProvider/ https://fsprojects.github.io/SQLProvider/

xupybd 5y ago
I've done a few little projects with the SQL provider. I worry about maintainability. You can't compile if the schema changes without you knowing about it. I haven't run into any real problems as a result but it does make me nervous.
- mumblemumble 5y ago
  > You can't compile if the schema changes without you knowing about it. There are those who would argue that making an incompatibility between the database schema and the code that interacts with it a compile-time error instead of a run-time error is a huge win for software quality. I suppose there are situations where you simply can't have access to a database that mimics the structure of the production database during development. In which case, the SQL provider is definitely not the right tool for the job. But it might be worth looking into ways to change how you do things in order to make it the right tool for the job. A SQL database with an unpredictable schema makes me much more nervous.
- pharmakom 5y ago
  You can save a snapshot of the schema into your repo.
- piaste 5y ago
  > You can't compile if the schema changes without you knowing about it That's why you don't normally compile against the production database. You version control the database schema and use it to create a local database to compile against. This way you can also test potential future migrations using branches. Compiling against the production database should be done separately, as a kind of free integration test (usually in CI).

Zababa 5y ago

Maybe a combination of churn from Scala, growing popularity of .NET in general with .NET Core, lack of high-level stuff in Go, static typing coming to dynamic languages (especially JS), functional features getting everywhere. Lots of stuff is pointing at it in a way.