Not the person you replied to but I leave unused variables as future TODOs. It's a warning in F#. I also often use them for inspecting data in the debugger
Waiting for async to finish and await are two different things. Async functions essentially have a different calling convention than standard functions. They're either converting your code into continuation passing style, state machines (C#, Rust), or using some sort of stack save+restore usually.
I agree we shouldn't need to `await` everything though. Effects with inference and implicit perform/await is possible
I've been working on a C++ backend for F# and while I'm very familiar with F# and it's AST I barely know C++. The amount of time I save being able to ask things, check my understanding, get design patterns, and paste issues I'm having for a fix is insane
I ran into an issue where I was getting a segfault and everything looked right in the debuggr, including expected values near the segfault. Turns out I wasn't using placement new somewhere I needed, and the data for the object was getting copied but not the vtables. I have no idea how long it would have taken me to figure that out on my own because the segfault was coming from so far away
I haven't had the opportunity to use LLMs much for coding since I'm not working right now, but I can second how much of a boost just getting specific answers to my questions instead of reading tons of whatever online searches return is.
Rubber duck that talks back is a nice way to put it
I'm wrestling with this right now. I only use LLMs for design and exploration because I am not employed and can't pay for a subscription right now, and they make the design phase feel like less of a fever dream because checking my ideas doesn't involve hours of scanning search results online and trying to see how my ideas fit with what exists or trying to evaluate if my ideas even make sense, so I feel more encouraged to get started on working, but I often wonder if the prompts are being sycophants
In one case recently I explained a garbage collector design I had been toying with a while ago, but couldn't find research related to my idea or really evaluate if my idea would work. After enough arguing with the prompt it finally "understood", started praising my "novelty", and when I later asked for research related to it I was given a paper that already implemented most of my idea
It was a funny moment of seeing how it was clearly trained on too many online forum comments (simply mentioning reference counting got it on this whole awkward line of false folklore about memory management) before switching to sycophancy, to finally showing me a paper
A lot of code ends up being easy to factor out into small pieces for tests. I can't speak for Haskell but coming from another ML with eager evaluation step debugging works as you would expect
I like to think about it as a VM that all the major browsers agreed to implement, designed by a broad group of stake holders with lessons from past plugin and VM systems
For that it's pretty cool. I still wish we had DOM access though
They're modeling reactivity, not classes. It's a well established pattern in functional programming
The one time setup mixed with repeated render calls is odd, but it's a design decision they made. It reduces boiler plate, though I don't necessarily agree with it because it is a leaky abstraction