4:20 It would be interesting, to target one of the obviously most open, motivated and enthusiastic groups, that might be interested to join the F# community. One, that has not been addressed until: What about complete fresh programmers, people who love to adopt a declarative style and do get used to functional first, domain driven and railway oriented programming, BEFORE they train their brains towards imperative and OO designs? Wouldn't it be awesome, to improve the current status, which is the result of investing almost nothing towards complete programming newbies? Is it really justified, compared to the huge investment done to attract C# developers? Would it make sense to attract people with an open mind and less practice, compared to people who are stuck in their mindset and still having less experience as someone might assume? 50% of all programmers have less than 5 years of experience. Maybe raise the next generation now.
Why do you need strongly typed inline strings? Shouldn't any language have all the base type inference built in to the language to convert base types to strings?
In .NET every type can be converted to a string. So you get that for free with C#, F# etc. And indeed, luckily F# is strongly typed, but that still allows you to convert any object to a string. However, this has nothing to do with type inference, which is there to allow automatic generalisation and type discovery, while remaining strongly typed.
F# appeals to me. I'll try it for my next web server. But the claim that "F# is good for everything" is actually counter-productive because it damages your credibility. It's not hard to think of cases where F# would be a poor fit like kernel drivers and windows shell extensions. Because the garbage collector can interrupt at any time, it's a poor fit for sending pulse-width-modulated signals to servos in robotics, and it's a poor fit for high-speed financial trading applications that have 10-ms deadlines. It would even be a tough fit where C# does well like Unity games. Unity programmers aim write code that never triggers the garbage collector. That's harder to do with F#'s immutable collections where every change to the collection creates garbage.
F# has been used with Unity, I know several guys that build games that way. And more recently, with ValueOption added to the language and task support, you can create code that has almost zero pressure in the GC. High performance computing has gotten easier and yes, there are some caveats, but I’ve build and maintained a day trading system that uses quite a bit of F# as the immutability is more a win than a loss in financial systems. Since it’s by default a managed language (but check Fable, which runs F# in the browser without JIT), it’s a poor fit for driver or kernel dev. That’ll always be C or asm. In the end, depending on the task at hand, you’d choose the best fit. Some tasks fab or Java, others Rust, Clojure, Python or F#. These are all general purpose languages, but each has their strengths and weaknesses.
Btw, about GC: F# tends to have many small very short lived objects. The F# optimiser and JIT often optimise function objects and closures away. If you look at GC pressure, what you’re left with is almost exclusively Gen 0 objects, which is much harder to do in C#. And if you’d only use value types, everything just lives on the stack. You may try it out. Plus with the new support for Span, in and out refs etc, this only got better.
![[SFM] Risky Recital](http://i.ytimg.com/vi/RzNkY1_Nk3o/mqdefault.jpg)
4:20 It would be interesting, to target one of the obviously most open, motivated and enthusiastic groups, that might be interested to join the F# community.
One, that has not been addressed until:
What about complete fresh programmers, people who love to adopt a declarative style and do get used to functional first, domain driven and railway oriented programming, BEFORE they train their brains towards imperative and OO designs?
Wouldn't it be awesome, to improve the current status, which is the result of investing almost nothing towards complete programming newbies?
Is it really justified, compared to the huge investment done to attract C# developers?
Would it make sense to attract people with an open mind and less practice, compared to people who are stuck in their mindset and still having less experience as someone might assume?
50% of all programmers have less than 5 years of experience.
Maybe raise the next generation now.
11:30 Yeah, we sill learn this OOP bullshit in university. Takes up a lot more time than it should.
Amazing talk! Thanks Don!
Why do you need strongly typed inline strings? Shouldn't any language have all the base type inference built in to the language to convert base types to strings?
In .NET every type can be converted to a string. So you get that for free with C#, F# etc. And indeed, luckily F# is strongly typed, but that still allows you to convert any object to a string. However, this has nothing to do with type inference, which is there to allow automatic generalisation and type discovery, while remaining strongly typed.
F#: Can I copy your homework from Marketing?
Rust: Yes, but change it a little bit.
F# appeals to me. I'll try it for my next web server. But the claim that "F# is good for everything" is actually counter-productive because it damages your credibility. It's not hard to think of cases where F# would be a poor fit like kernel drivers and windows shell extensions. Because the garbage collector can interrupt at any time, it's a poor fit for sending pulse-width-modulated signals to servos in robotics, and it's a poor fit for high-speed financial trading applications that have 10-ms deadlines. It would even be a tough fit where C# does well like Unity games. Unity programmers aim write code that never triggers the garbage collector. That's harder to do with F#'s immutable collections where every change to the collection creates garbage.
Come on, that's really splitting hairs over trivialities. It's completely clear in what spirit this was said.
F# has been used with Unity, I know several guys that build games that way. And more recently, with ValueOption added to the language and task support, you can create code that has almost zero pressure in the GC. High performance computing has gotten easier and yes, there are some caveats, but I’ve build and maintained a day trading system that uses quite a bit of F# as the immutability is more a win than a loss in financial systems. Since it’s by default a managed language (but check Fable, which runs F# in the browser without JIT), it’s a poor fit for driver or kernel dev. That’ll always be C or asm.
In the end, depending on the task at hand, you’d choose the best fit. Some tasks fab or Java, others Rust, Clojure, Python or F#. These are all general purpose languages, but each has their strengths and weaknesses.
Btw, about GC: F# tends to have many small very short lived objects. The F# optimiser and JIT often optimise function objects and closures away. If you look at GC pressure, what you’re left with is almost exclusively Gen 0 objects, which is much harder to do in C#. And if you’d only use value types, everything just lives on the stack. You may try it out. Plus with the new support for Span, in and out refs etc, this only got better.
USA. 🇺🇸