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

What is the case against F#? (2009)

stackoverflow.com

Post reply on HN
Print view View original

101–107 of 107 posts

Re: What is the case against F#? (2009)

#101

Post by dfgdghdf »

oaiey wrote: post #74
dfgdghdf wrote: post #12

Earlier quoted context omitted.

F# syntax is so much better than C# for functional programming - and arguably for object programming too. However, it is sufficiently different that you really need to jump in with both feet. Don't assume it will be easy because you know C#. However, once you start to grok the syntax, you begin to see how the language features elegantly tie together, and the language design decisions make perfect sense. Unfortunately…

This different is a big thing. People learn C#, Java, JavaScript, Basic, PHP or C/C++ early on their carrier. Hoping between these is hard but not because of syntax. Hoping from this OO gang to a modern functional syntax is brutal. I think key to proper functional adoption is wide range entry level adoption (and not only university).

Indeed. And sometimes these same people will claim, based on their experiences only with the OO gang, that PL choice doesn't matter! If this is you, set aside an afternoon and try a Lisp or something from the ML family, it might change your whole perspective!

Re: What is the case against F#? (2009)

#102

Post by cies »

gher-shyu3i wrote: post #94
cies wrote: post #22

Earlier quoted context omitted.

If it's not null-safe I will avoid it for new projects. Lambda's: great! But real null-safety, strong type safety, proper sum types, pattern matching/ type destructuring, are now my requirements. I'd say Kotlin is the language with the most adoption that ticks the boxes. And it is (not surprisingly) an OO lang.

Incidentally, pattern matching that Java is getting is superior and more fully fledged to the one that exists in Kotlin. You can also have null safety in Java by means of annotations. You can also check out C# since it fits your requirements. It has pattern matching, but sum types are still in the works.

I've grown a strong dislike for annotations. One here or there is not the problem, but they will be used (I'm looking at you Spring) to add magic to my programs. I want to know what goes on; annotation hide what goes on. Debugging problems with annotations is a real pain. I like that in Kotlin the community seems to fight overuse of annotations (also they fight overuse of Exceptions which I really like: Exceptions are not a way to do multiple return values, sumtypes are).

Re: What is the case against F#? (2009)

#103

Post by cies »

gher-shyu3i wrote: post #94
cies wrote: post #22

Earlier quoted context omitted.

If it's not null-safe I will avoid it for new projects. Lambda's: great! But real null-safety, strong type safety, proper sum types, pattern matching/ type destructuring, are now my requirements. I'd say Kotlin is the language with the most adoption that ticks the boxes. And it is (not surprisingly) an OO lang.

Incidentally, pattern matching that Java is getting is superior and more fully fledged to the one that exists in Kotlin. You can also have null safety in Java by means of annotations. You can also check out C# since it fits your requirements. It has pattern matching, but sum types are still in the works.

On sum types in C#:

https://www.reddit.com/r/csharp/comments/7b8mvn/have_sum_typ...

Re: What is the case against F#? (2009)

#104

Post by teddyh »

Seirdy wrote: post #100
teddyh wrote: post #85

Earlier quoted context omitted.

Nothing which was initially developed inside a large corporation has a reasonable chance of becoming truly independent. The only example I can think of is Unix and C, and that’s only because AT&T was (for complicated reasons) legally restricted from selling it as a product, and the project was taken over by various other actors in both business and academia. But C#, F#, Go, Swift, Dart, etc.? They are initially popul…

- Kotlin (Jetbrains) - Chez Scheme (Cisco) - Erlang (Ericsson) - Rust (Mozilla) - Java (Sun Microsystems, Oracle) The above examples show languages that outgrew the companies that developed them. Typescript might follow a similar path in the future.

I don’t know about Kotlin. Scheme was already a thing before Chez Scheme, and Scheme in general has quite a lot of implementations, so Chez Scheme is probably mostly safe, merely because of that. Erlang I don’t know much about. Rust was created by the semi-large Mozilla Foundation, but Mozilla had mostly benevolent goals and designs for the language, so that one is probably OK. Java was initially made popular since people trusted Sun Microsystems, but then Sun was 1. destroyed by market forces, and 2. bought by Oracle. And Oracle keeps an even tighter iron-fisted grip around Java than ever, according to what I hear. So I wouldn’t touch Java with a 10 foot pole either.

Re: What is the case against F#? (2009)

#105

Post by teddyh »

nojito wrote: post #96
teddyh wrote: post #92

Earlier quoted context omitted.

The only one of those that I have heard of is Javascript, and that was initially implemented by Netscape, but the language was then taken over by the industry at large as Netscape’s market share dwindled. Javascript is also unusual in that it had a specific and restrictive design goal, and a very short initial development phase before the language was mostly frozen. This meant that not a lot of Netscape culture could…

You are just wrong and speaking like it's still the 90s or 2000s. I just mentioned 3 very popular and effectively best in class technologies that started at a corporation and now have robust open communities supporting them.

Please name one thing I wrote which is wrong. I mean, I agreed with you about Javascript, and gave a lengthy explanation why, even though you gave no motivation. I have not heard of the other two, so obviously I can’t comment about them.

Re: What is the case against F#? (2009)

#106

Post by sweeneyrod »

narag wrote: post #91
sweeneyrod wrote: post #81

Earlier quoted context omitted.

What are some situations where you need parallelism? I am not convinced there are many. I have never heard anyone say they are using .NET instead of JavaScript or Python in order to get parallelism.

Web server programming is inherently multithreaded. I'm not sure if that's a convincing answer, but web performance is definitely a common rationale to use .NET or Java over Python or JS.

Inherently parallel, sure. How often does that parallelism need to be within a single process? Not that frequently in my experience. If your threads aren't sharing state they can just be processes instead. If they are sharing state that's going to cause trouble if/when you have to scale beyond one process.

Re: What is the case against F#? (2009)

#107

Post by narag »

sweeneyrod wrote: post #106
narag wrote: post #91

Earlier quoted context omitted.

Web server programming is inherently multithreaded. I'm not sure if that's a convincing answer, but web performance is definitely a common rationale to use .NET or Java over Python or JS.

Inherently parallel, sure. How often does that parallelism need to be within a single process? Not that frequently in my experience. If your threads aren't sharing state they can just be processes instead. If they are sharing state that's going to cause trouble if/when you have to scale beyond one process.

Programmers use frameworks that offer everything they need out of the box. They do need shared state for sessions. But they don't sit down and think if they're going to use threads or processes. They just choose a popular, feature-full framework.

Java and .NET frameworks use threads, rationale being threads perform better. I won't go into that discussion, even if I do have an opinion. Right now, I'm just pointing to what others say.

Post reply on HN