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
This is a direction I've been pushing in partly because I'm using a significantly slower type inference algorithm in my language. I'm hoping with that and focusing on separate compilation I'll be able to keep the fancy inference without sacrificing the UX too much
Afaik that is true of traditional HM, but fortunately there was a big advancement in inferring subtypes w/ Dolan's Algebraic Subtyping a few years ago! It's not nearly as fast as HM (O(n^3) worst case) but generally fast enough in real code
There's definitely tradeoffs to some things, and I think in particular Rust's static guarantees can cause additional friction, but in general I've found ML derived languages to be extremely practical because it's a good local maximum on the graph in terms of complexity vs runtime safety (where languages like Java add too much friction without enough benefit compared to something like Python)
I've found in software development the 80/20 rule is extremely true, but when you need something from that last 20%, it can really mess up your architecture trying to work around it. To me this is why others love LISP so much, and I appreciate F#/OCaml for getting me as close to that potential as possible while keeping static analysis reasonable. Clever use of type systems is great for RAD and making sure critical components make certain classes of bugs a compile time error, and it can turn into undecipherable magic, but the additional information and guarantees advanced type systems provide allow me to focus on my immediate problem instead of the interplay with a larger system.
Good to hear they're providing a good dev experience. My only gripe at the time was more of a worry on whether the split was going to be worthwhile because the ML ecosystem is already so small, but I'm glad to hear the project has been effective for you.