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

81–90 of 99 posts

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

#81

Post by akkad33 »

xscott wrote: post #78
steveklabnik wrote: post #77

Earlier quoted context omitted.

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

One thing I would say is if you're writing a normal Rust application or library and do not care about c interoperability, you could get by without being aware of anything other than the first 2 types. However in Fsharp you are forced to learn about all other ways of doing things, plus how C# does things, because it is almost impossible to do anything useful without interoperating with C# and dotnet

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

#82

Post by akkad33 »

to11mtm wrote: post #56
akkad33 wrote: post #45

Earlier quoted context omitted.

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…

> But why records and classes when records can also have methods. Records have built in equality logic, Classes don't. And, because of the interop story, they wanted to be able to define classes. > C# reified generics and rust like monomorphised generics (with inline keyword) and they used to have two different syntaxes until recently I almost prefer the old way, where SRTPs required the other syntax. On the other ha…

> Records have built in equality logic, Classes don't.

I'm aware of this but i feel this is confusing. Just putting () changes semantics a whole lot

> Also, just minor pedantic comment, both C# and F# will monomorphize for struct of T

I wasn't aware thanks

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

#83

Post by akkad33 »

deathanatos wrote: post #44
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)

> 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 t…

I guess vscode is convenient and I don't want to spend the rest of my life configuring vim

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

#84

Post by scrubs »

I recently left a c# shop in finance. My background c/c++. I was very interested to see if c# was less work: easier to write and build.

I was not impressed by what I saw - it was junk code. One of the major errors was writing apps as MS services which dragged in tons of MS OS junk.

I cannot totally blame c#; i think the staff there were not engineers but more guys doing stuff.

The code was complex; replete with async calls. Build artifacts were entire directories of dlls, exes, json eg 50+ files per task.

The code was littered with warnings. The company could not or would not do hardly anything outside Visual Studio.

There were entire repos of code without comments; no method contracts, obscene reliance on exceptions.

I'm prepared to think f# could be better but never underestimate how bad things can be with a good language if the devs are not engineering grade developers.

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

#85

Post by sasmithjr »

UncleOxidant wrote: post #4

Wishful thinking, me thinks. How good are the AI coding agents at coding F#?

For me, AI code generation for F# has been pretty good! There's one annoying thing Opus/Sonnet do (honestly don't remember what other models do): use old syntax for array indexing.

  values.[index] // Old way of indexing required a .
  values[index] // Supported for awhile now
That's the "biggest" issue I run in to, and it's not that big of a deal to me.

Yesterday, it did try to hallucinate a function that doesn't exist; compilation failed, so the agent changed the function to a fold and everything was hunkey-dorey.

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

#86

Post by CharlieDigital »

hirvi74 wrote: post #57
CharlieDigital wrote: post #15

Earlier quoted context omitted.

Indeed. I read a great write up by Sam Cox of Tracebit[0] on his selection of C# and his focus on productivity nails it on the head. One of the best ORMs, rich standard libraries and first party packages, and has been converging with TypeScript and JavaScript over the last decade[1] while having all of the advantages of runtime type safety. Folks that last looked at C# over a decade ago don't know what they are missi…

The language has also made great strides to increase readability and decrease verbosity. I have been loving a lot of the changes over the years.

Yes; very underrated in this regard with respect to how terse the language is now. Especially switch expressions and pattern matching. C# pattern matching is incredibly rich[0], terse, while being eminently readable.

[0] https://timdeschryver.dev/blog/pattern-matching-examples-in-...

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

#87

Post by xscott »

akkad33 wrote: post #80
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)…

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

Yeah, having the multiple "record" types in Rust doesn't bother me either. I just disagreed that the situation is clearly simpler than it is in F#.

If you think of using C# libraries from F# as comparable to using other people's crates in Rust, you're going to get exposed to other people's choices for data structures in both.

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

#88

Post by xscott »

akkad33 wrote: post #81
xscott wrote: post #78

Earlier quoted context omitted.

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

One thing I would say is if you're writing a normal Rust application or library and do not care about c interoperability, you could get by without being aware of anything other than the first 2 types. However in Fsharp you are forced to learn about all other ways of doing things, plus how C# does things, because it is almost impossible to do anything useful without interoperating with C# and dotnet

I think any new user would stumble on Path, OsString, and OsStr pretty quickly when working with files and directories. Rust tried really hard to avoid string related errors at runtime by not allowing strings to have invalid data. It's a defensible goal, and the cost is having multiple string types. And then they've got another doubling of types because of their ownership model.

It's not the choice I would make, but my opinion doesn't really matter. Real world strings (UTF-8, WTF-8, UCS-16, arbitrary bytes) don't follow the rules 100% of the time, so you're always going to end up dealing with that complexity at runtime in one place or another. I think you might as well have one simple string type and accept that. This is what Go chose (not that I'm a regular Go user either).

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

#89

Post by andrewflnr »

adastra22 wrote: post #69
ffin wrote: post #51

Earlier quoted context omitted.

not to get into this debate, but linux is far from mainstream

(he types from his android phone)

Not a desktop. :) ChromeOS is closer to counting, but while it's technically Linux, that's really just an implementation detail in the same way it would be for a mall kiosk. It's hard to do actually Linuxy things with it that desktop Linux enthusiasts envision.

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

#90

Post by adastra22 »

andrewflnr wrote: post #89
adastra22 wrote: post #69

Earlier quoted context omitted.

(he types from his android phone)

Not a desktop. :) ChromeOS is closer to counting, but while it's technically Linux, that's really just an implementation detail in the same way it would be for a mall kiosk. It's hard to do actually Linuxy things with it that desktop Linux enthusiasts envision.

The meaning and purpose of “desktop” has changed over the years. The “year of Linux on the desktop” was about Linux going mainstream and being used by average joes. Well the average joe doesn’t even use a desktop anymore on a daily basis—the smartphone or tablet has replaced that, and the majority of these devices run Linux.

Also I’m channeling my inner stallman here, but Linux is just the kernel.

Post reply on HN