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

Why F# could be the next mainstream programming language (2024)

blog.snork.dev

Post reply on HN
Print view View original

41–50 of 99 posts

Re: Why F# could be the next mainstream programming language (2024)

#41

Post by AdieuToLogic »

mbac32768 wrote: post #19

I do not understand how they could develop a language inspired by OCaml but not bring over labeled function arguments. A real L when it comes to ergonomics. And they just have no plans to ever fix this??

> I do not understand how they could develop a language inspired by OCaml but not bring over labeled function arguments. A real L when it comes to ergonomics.

Is this what you desire?

  Named Arguments[0]

  Arguments for methods can be specified by position in a 
  comma-separated argument list, or they can be passed to a 
  method explicitly by providing the name, followed by an 
  equal sign and the value to be passed in. If specified by 
  providing the name, they can appear in a different order 
  from that used in the declaration.
0 - https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...

Re: Why F# could be the next mainstream programming language (2024)

#42

Post by ackfoobar »

electroly wrote: post #33
banashark wrote: post #20

Earlier quoted context omitted.

Comparisons to typescript/node (which I have more ai hours in, but equal experience) Pros: * type system is less flexible which simplifies things for the ai * mostly functional code * the language hasn’t evolved as much as others because it’s had a strong foundation of features for a while, leading to the corpus containing fairly common themes Cons: * smaller corpus * no reliable hot reloading, which causes annoying…

> then forgetting to stop it and hitting errors from starting it again This one is easy to fix. Give it a script that both kills the old process and starts the new one. Then it can't forget. This is what I do; categorically solved the problem.

> Give it a script

Ideally the build tool does that for you, e.g. `./gradlew run -t`.

Re: Why F# could be the next mainstream programming language (2024)

#44

Post by deathanatos »

akkad33 wrote: post #11
taberiand wrote: post #6

Earlier quoted context omitted.

Nonsense, .NET is one of the best ecosystems available. Your sentiment is one I tend to hear mostly from people who think it's still .NET Framework and Windows only

Not only. I don't want to use Microsoft technologies unless forced to or no better alternatives (GitHub/ vscode)

> I don't want to use Microsoft technologies unless forced to or no better alternatives

Agreed there.

> (GitHub

Github is probably in the "forced to" category, since the employer, not employee, decides, I assume.

> / vscode)

… but really? Vim. I've yet to see someone using VSCode on a VC meeting stream that isn't seemingly floundering. What does VSCode get me, aside from a proprietary editor from a company I do not trust? Telemetry and AI slop built in?

Or, you know, ed is the standard editor. /s

Re: Why F# could be the next mainstream programming language (2024)

#45

Post by akkad33 »

banashark wrote: post #36
akkad33 wrote: post #28

F# is a chimera of a language. The functional parts of the language are nicely designed: no nulls, discriminated unions (ADTs), you write simple functions in simple modules and there is nothing that is too clever to understand: it's very pragmatic. Then there is a whole lot of stuff like inheritance, classes, interfaces, nulls mainly there for dotnet interoperability that gets very ugly very fast. There are way too m…

Well there are the 3 you mentioned (records, classes, and tuples) which should be easy enough to differentiate from each other. The struct versions aren't necessary to use in most cases, and are an optimization. The thoughtful, but not breakneck speed of changes within the language is one thing I appreciate a lot. Things do get added (there are proposals and discussions that are fairly regular in the GitHub repo for…

Yeah those examples I gave are not the best. But why records and classes when records can also have methods. What I was getting at was the language looks good until you dive deeper and get into all those rough edges of dotnet interoperability. An example I can think of is functions/methods. I think F# style is to write curried functions (no brackets for function inputs), except class methods are written mostly non curried. Computation expressions are non curried also even though that is an F# only features. Then there are two ways of writing generics: C# reified generics and rust like monomorphised generics (with inline keyword) and they used to have two different syntaxes until recently

Re: Why F# could be the next mainstream programming language (2024)

#48

Post by buffet_overflow »

Beermotor wrote: post #31

I became more proficient in one language than any other. Therefore this language is the best language ever and will take over the universe.

That language isn’t the same language I became more proficient in, so are you sure it’s not terrible, useless, and will lose handily to the one I use for my specific purposes?

Re: Why F# could be the next mainstream programming language (2024)

#49

Post by banashark »

akkad33 wrote: post #45
banashark wrote: post #36

Earlier quoted context omitted.

Well there are the 3 you mentioned (records, classes, and tuples) which should be easy enough to differentiate from each other. The struct versions aren't necessary to use in most cases, and are an optimization. The thoughtful, but not breakneck speed of changes within the language is one thing I appreciate a lot. Things do get added (there are proposals and discussions that are fairly regular in the GitHub repo for…

Yeah those examples I gave are not the best. But why records and classes when records can also have methods. What I was getting at was the language looks good until you dive deeper and get into all those rough edges of dotnet interoperability. An example I can think of is functions/methods. I think F# style is to write curried functions (no brackets for function inputs), except class methods are written mostly non cu…

Yeah typically if you're exposing F# code out to C# as a library, you'd want to keep the external API utilizing features that have better interoperability (classes), whereas code that's written in F# and only expected to be called by F# can use things like currying and such.

In practice, this ends up being mostly simple to deal with.

In the other direction, consuming C# libraries historically hasn't had too much trouble other than they don't really design them with any functional-leaning in mind. The real problem that's growing recently is the dotnet teams move towards C#-centric features. Things like source-generators, roslyn, etc that are "C# features" and not "dotnet features". These types of things could create a big enough rift to break practical usage of F# as a dotnet interoping language if it goes unchecked.

Re: Why F# could be the next mainstream programming language (2024)

#50

Post by deathanatos »

moron4hire wrote: post #21
akkad33 wrote: post #11

Earlier quoted context omitted.

Not only. I don't want to use Microsoft technologies unless forced to or no better alternatives (GitHub/ vscode)

If you feel forced to use vscode due to "lack of better alternative" but then stop at using .NET, then you're really missing out on tools that lack better alternatives. .NET has spoiled me so badly with C#, NuGet, and the debugger that I just don't have the patience for any other languages with their half-assed build systems, janky package managers, and after-thought debuggers. MSBuild and the dotnet CLI tool may not…

This is a fair criticism, but I think it's more accurate to say that "Venv is built-in", more than "isn't a thing"; it sounds like something is managing it for you, if they can co-exist somehow.

Python is (slowly) getting there; `uv` gets pretty close: `uv run -m $module_name` will install required dependencies & run.

(But even then, we use it at work, and there are a few complications around macOS, native libraries, and private repositories.)

Post reply on HN