4 ms·

I was thinking the same thing. The errors are now returned without their context, and I've written enough F# to know that computational expressions aren't magi

I was thinking the same thing. The errors are now returned without their context, and I've written enough F# to know that computational expressions aren't magic. Forgetting an exclamation mark circumvents the entire expression. Perhaps that's changed in recent years, but it was really annoying to find your code silently breaking due to a missing symbol some ~5 years ago. As much as people love to hate on Go, it's the only language where I can read someone else's code line by line and not simultaneously have to read partly outdated language specs, no longer applicable SO answers or generally have to play internet detective to unravel magical incantations that sometimes fail at runtime. Yes Go is verbose, yes it lacks XYZ. Junior, mid, senior, Go newb, Go expert, the code (for the most part) looks the same. How that's a bad thing I don't get. Boring? Incredibly. Useful? Incredibly.

xupybd 4y ago
I like using the bind operator and avoiding computational expressions. Like Scott Wlaschin suggest. But I've also found that sometimes traditional error handling makes more sense. https://fsharpforfunandprofit.com/rop/ https://fsharpforfunandprofit.com/rop/
Arnavion 4y ago
How would you manage to forget a `!` when writing F#? IIRC the code wouldn't type-check without it, because you'd be trying to use an expr of the monad type as if it was of the inner type. It's been a few years since I wrote F# so I could be misremembering.
- fredrikholm 4y ago
  This was in the context of async, where bind meant awaiting (or not, can't recall). The outcome was unpredictable async behaviour. To make things worse, back then the async story wasn't all that great to begin with. That was on top of the already confusing "will this run in parallel"-bingo situation of .NET. This was before the .CORE-1/2/3/NET-without-the-dot period, no idea if it's any better now. Hiding complexity in a very expressive language (F# is beautiful), running on top of a complex VM that is constantly changing... in the context of working with tight deadlines and other peoples code, I don't mind if statements. Happy to hear that the compiler catches other (most?) cases. Perhaps I should give F# another round, it's mostly .NET that I can't find myself to relearn for the nth time.
  - Arnavion 4y ago
    >where bind meant awaiting (or not, can't recall) Yes, but that's my point. If you have an `Async<int>` and you forget to use `!`, you'll get a type error if you try to use it as an `int`. Even with an `Async<unit>` where you think you're executing some side effect but forget to use the `!` to execute that side affect, the `Async<unit>` value will be unused and you'll get an error about that.
    - fredrikholm 4y ago
      You're probably right; I don't remember the details. What I do remember was parallelism being dodgy, several team members looking at it until one added an exclamation mark and solved the problem. This was F#3 in a legacy project, some five years ago. I bet lot of things have changed since.
erik_seaberg 4y ago
“Code looks the same” means your experts will forever be forced to wade through the same awful boilerplate as your beginners. There’s no payoff for learning more, and no way to improve their work (apart from code generation, which I strongly endorse here).
- fredrikholm 4y ago
  And? I'm not trying to be facetious here. I genuinely don't understand the problem. > no way to improve their work What do you mean? If you mean abstractions, there's functions, methods, interfaces, types, packages, generics etc. What exactly is missing, and how much more productive would everyone be if it was present?

xupybd 4y ago

I like using the bind operator and avoiding computational expressions. Like Scott Wlaschin suggest. But I've also found that sometimes traditional error handling makes more sense. https://fsharpforfunandprofit.com/rop/ https://fsharpforfunandprofit.com/rop/

Arnavion 4y ago

How would you manage to forget a `!` when writing F#? IIRC the code wouldn't type-check without it, because you'd be trying to use an expr of the monad type as if it was of the inner type. It's been a few years since I wrote F# so I could be misremembering.

fredrikholm 4y ago
This was in the context of async, where bind meant awaiting (or not, can't recall). The outcome was unpredictable async behaviour. To make things worse, back then the async story wasn't all that great to begin with. That was on top of the already confusing "will this run in parallel"-bingo situation of .NET. This was before the .CORE-1/2/3/NET-without-the-dot period, no idea if it's any better now. Hiding complexity in a very expressive language (F# is beautiful), running on top of a complex VM that is constantly changing... in the context of working with tight deadlines and other peoples code, I don't mind if statements. Happy to hear that the compiler catches other (most?) cases. Perhaps I should give F# another round, it's mostly .NET that I can't find myself to relearn for the nth time.
- Arnavion 4y ago
  >where bind meant awaiting (or not, can't recall) Yes, but that's my point. If you have an `Async<int>` and you forget to use `!`, you'll get a type error if you try to use it as an `int`. Even with an `Async<unit>` where you think you're executing some side effect but forget to use the `!` to execute that side affect, the `Async<unit>` value will be unused and you'll get an error about that.
  - fredrikholm 4y ago
    You're probably right; I don't remember the details. What I do remember was parallelism being dodgy, several team members looking at it until one added an exclamation mark and solved the problem. This was F#3 in a legacy project, some five years ago. I bet lot of things have changed since.

erik_seaberg 4y ago

“Code looks the same” means your experts will forever be forced to wade through the same awful boilerplate as your beginners. There’s no payoff for learning more, and no way to improve their work (apart from code generation, which I strongly endorse here).

fredrikholm 4y ago
And? I'm not trying to be facetious here. I genuinely don't understand the problem. > no way to improve their work What do you mean? If you mean abstractions, there's functions, methods, interfaces, types, packages, generics etc. What exactly is missing, and how much more productive would everyone be if it was present?