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

71–80 of 99 posts

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

#71

Post by cosmos64 »

djtango wrote: post #53
banashark wrote: post #32

Earlier quoted context omitted.

I understand where you're coming from, but I'd challenge your dismissal of that note by noting how seemingly powerful a large ecosystem of available packages is when onboarding people to an ecosystem. I don't think Scala, Kotlin, or Clojure would have had as much adoption if they hadn't had access to the JVM ecosystem of libraries available. While it's not the only benefit, I think one could just point at the usage o…

After reading Paul Biggar's experiences with OCaml when building darklang, and the importance of ecosystem when building distributed systems in the cloud, I don't think I'd ever build a business on a non-hosted functional language. There are some hefty businesses built on top of OCaml so it definitely can be done, but it sounds too expensive to get a small business up and running if the code itself isn't the product.…

Depends on the use case.

Erlang, Elixir, and Gleam are hosted on their own platform, and lots of use cases can be covered that way.

Also, Flix is a thing, and some Scheme/CommonLisp/StandardML implementations compile to C.

Ecosystem there. Purescript, Gleam and others compile to JS.

Oh, and WebAssembly becomes valuable as compilation target as well.

Also: Kotlin is almost a functional first language like F#

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

#72

Post by smoothdeveloper »

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??

You can read this suggestion, and upvote, comment, contribute: https://github.com/fsharp/fslang-suggestions/issues/1434

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

#73

Post by cosmos64 »

ofrzeta wrote: post #64

I would be very reluctant to use it because of the fear that at some point Microsoft just kills it. You have to wonder why they are keeping it alive so long as they are probably getting not much value out of it (some people here say they are using it as a testbed for functional features in C# but I don't believe this - I guess the C# team has enough resources to do their explorations on their own). I guess if Don Sym…

I can tell you, that the community keeps it alive for all these years already.

F# used to be the project #1 across all the thousands of repositories of Microsoft in terms of community contributions to the ecosystem, compared to the contributions by paid employees.

Next, F# has already been a very refined language 10 years ago, so it doesn't get a lot of things added to begin with. Slow and steady evolution, with lots of care is the topic of this game.

Also: A lot of the paid work went into the tooling, which has finally reached a point, where I consider it industry ready.

By the way: Don isn't paid to work on F# anymore for quite some time.

The world still moves on.

From my personal perspective, would it change little, when Microsoft would F# let go.

And did you know, that they finance the development of Haskell since decades?

Simon worked literally on the same floor as Don for years.

They won't let it go. Paying 2, 3 devs is peanuts for them. They don't even notice it.

I am just scared, what will happen if F# truly competes with C# for market share.

The internal competition amongst projects at Microsoft can become quite nasty at times.

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

#74

Post by cosmos64 »

wewewedxfgdf wrote: post #52

Functional programming people have been hoping for their favorite functional language to go mainstream for a long time but it never happens.

Javascript, Typescript, Rust, and Kotlin are fundamentally functional programming languages.

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

#75

Post by cosmos64 »

SoftTalker wrote: post #9

C# was Microsoft’s response to Java, was F# their response to Scala and Clojure?

.NET was initially planned as a multi language VM.

The first plan was to bring over Haskell, and Don (the creator of F#) implemented support for generics in dotnet.

The reason, why C# has an edge over Java, when it comes to generics. ;)

Then he noticed that Haskell wouldn't run on that runtime back then, and they chose OCaml instead.

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

#76

Post by steveklabnik »

xscott wrote: post #60
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…

> There are way too many variants of the same thing: records, classes, struct records, tuples, struct tuples etc, [...] > At the end I went with Rust because it has one way of doing such stuff. I haven't looked at C# in 20 years, but Rust certainly has a LOT of ways to do similar things too: struct Foo { x: f64, y: f64 } // Struct struct Foo(f64, f64) // Tuple Struct let f = (1.0, 2.0) // Tuple enum U { Foo(f64, f64)…

It’s not so much that you’ve made any mistakes or omissions as much as all of these things do different, similar things, but don’t do the exact same thing.

For example, an array and a tuple are both aggregate types, but arrays store multiple value of a single type, and tuples store multiple values of the same type.

Some of these do boil down to “named or anonymous” but that’s also two different things.

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

#77

Post by steveklabnik »

xscott wrote: post #61
xscott wrote: post #60

Earlier quoted context omitted.

> There are way too many variants of the same thing: records, classes, struct records, tuples, struct tuples etc, [...] > At the end I went with Rust because it has one way of doing such stuff. I haven't looked at C# in 20 years, but Rust certainly has a LOT of ways to do similar things too: struct Foo { x: f64, y: f64 } // Struct struct Foo(f64, f64) // Tuple Struct let f = (1.0, 2.0) // Tuple enum U { Foo(f64, f64)…

Heh, I just remembered that Rust has like 6 or 7 ways to do strings too.

Rust has one string type in the language, and three more in the standard library. This boils down to the intersection of “owned vs borrowed” and “Rust native strings vs C native strings,” and you only need the C variants when doing FFI.

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

#78

Post by xscott »

steveklabnik wrote: post #77
xscott wrote: post #61

Earlier quoted context omitted.

Heh, I just remembered that Rust has like 6 or 7 ways to do strings too.

Rust has one string type in the language, and three more in the standard library. This boils down to the intersection of “owned vs borrowed” and “Rust native strings vs C native strings,” and you only need the C variants when doing FFI.

I'm (basically) aware of the details (String, &str, OsString, OsStr, CString, CStr, "star" c_char, and probably some others ("star" const i8, &[u8], ???), and you and I have had this conversation a while back when I had a stronger interest in Rust. I'm not sure if you're correcting me, but you're basically confirming what I said.

As for only needing them when you need them, how could it be otherwise? :-)

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

#79

Post by xscott »

steveklabnik wrote: post #76
xscott wrote: post #60

Earlier quoted context omitted.

> There are way too many variants of the same thing: records, classes, struct records, tuples, struct tuples etc, [...] > At the end I went with Rust because it has one way of doing such stuff. I haven't looked at C# in 20 years, but Rust certainly has a LOT of ways to do similar things too: struct Foo { x: f64, y: f64 } // Struct struct Foo(f64, f64) // Tuple Struct let f = (1.0, 2.0) // Tuple enum U { Foo(f64, f64)…

It’s not so much that you’ve made any mistakes or omissions as much as all of these things do different, similar things, but don’t do the exact same thing. For example, an array and a tuple are both aggregate types, but arrays store multiple value of a single type, and tuples store multiple values of the same type. Some of these do boil down to “named or anonymous” but that’s also two different things.

More power to you for defending or explaining Rust, but the context of the conversation is comparing multiple "record" types in C# as "bad" to the "one way" in Rust. It's hard to argue that Rust has a simpler story than C#.

There are a lot of almost orthogonal features one might choose for a record type:

Accessor: rec.x, rec.0, rec[0], match

Constant vs Mutable

Reference vs Value

Nominal vs Structural/Anonymous typing

Subtyping for inheritance

Subtyping for sum/union types

And more depending on the language (ownership in Rust)

> tuples store multiple values of the same type.

I'm sure this was a typo. :-)

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

#80

Post by akkad33 »

xscott wrote: post #60
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…

> There are way too many variants of the same thing: records, classes, struct records, tuples, struct tuples etc, [...] > At the end I went with Rust because it has one way of doing such stuff. I haven't looked at C# in 20 years, but Rust certainly has a LOT of ways to do similar things too: struct Foo { x: f64, y: f64 } // Struct struct Foo(f64, f64) // Tuple Struct let f = (1.0, 2.0) // Tuple enum U { Foo(f64, f64)…

> struct Foo { x: f64, y: f64 } // Struct struct Foo(f64, f64) // Tuple Struct let f = (1.0, 2.0) // Tuple enum U { Foo(f64, f64) } // Enum Tuple enum V { Foo { x: f64, y: f64 } } // Enum Struct [ 1.0, 2.0 ] // Size-2 Array &[ 1.0, 2.0 ] // Slice vec![1.0, 2.0] // Vec

I don't know, I'm not too bothered by this. If you take struct tuple and struct, Yes synctacticqlly they are different but functionally they are quite similar. You have values lying in memory. There's no reason to prefer one to the other except convenience. Program behaviour will not change. This is not the the case for fsharp classes and records and structs. Same way Fsharp has two types of lists. It also has an array type and all these are different but they look the same. In rust case they all have different names but behaviour wise they are same: data stored in contiguous memory with some differences in what you can do with them. I do like fsharp as a language but it can't go full on its promises because of dotnet. One glaring one is nulls. The language itself claims to be null safe. Except if you use dotnet types like strings. Then the compiler doesn't warn you. Honestly Kotlin does this better with non nullable types and null chaining

Post reply on HN