HN user

Weebs

115 karma

Fullstack developer in some form since the RS2 and PHP+JS days, now a little type and graphics obsessed.

Posts0
Comments76
View on HN
No posts found.

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 keep asking LLMs if I can define an interface implementation as an expression or without creating a new type in C#

Every single one I ask always happily says yes, and starts claiming C# has local classes (a feature of Java)

A VM with good FFI and structs is pretty unique and all of the tooling around .NET is excellent

F# is a sleeping giant of capability in the FP/ML space, being able to use a lot of the existing tooling

People rightfully point out how it's sort of second class in comparison to C# at times, but its still A tier tooling that few languages have

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

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

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

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.

I have nothing to say other than thank you! I might not use OCaml often myself, but I appreciate the effort to improve the ML ecosystem in any way :) I was a bit disappointed with the ReScript fork abandoning the compatibility with OCaml so this project was welcome news

And we should all try to do something weird.

YES

It's a big world out there and there's so many cool techniques we know are helpful but aren't widespread and really should be, and so much more to be discovered still!

You got me thinking and I think part of what it comes down to for typed FP languages is that you can either generally

1) Go for a simple design, but having poor interop with existing ecosystems because the language lacks equivalent features. I see Elm in this camp, and it's hard to live in because the FP community has fewer people than other communities to build up another ecosystem

2) Go for a more fully featured design, integrating with some ecosystem (like F#, Scala), but you end up with multiple overlapping concepts and inconsistency in the native language's ecosystem

It seems like dynamic FP languages are the only ones to get away with a simple core and wide ecosystem by avoiding the need for features that are important for writing modular code in typed MLs. OCaml is probably closest to the sweet spot as a language+ecosystem, but the language tools are a bit weak coming from other platforms

Yeah I'm not saying immutability solves the problem, I am saying that having good support for immutability is helpful for building those synchronization and rollback systems. If I thought immutability was all you needed I wouldn't be bringing up the effects system & pointing out how current languages still fall short in my own experience.

For those wondering why they've created yet another language, keep this in mind: Fortnite content is running code on possibly 100 remote clients simultaneously, and code often has state that needs to be synchronized across clients, which can often require rolling back the system to a specific previous state (which is a context FP languages tend to shine, because of the first class support for working with immutable data giving you easy snapshots of a system and resetting state)

It's a difficult problem to put it lightly, so as someone that dislikes new languages for only one tool, I consider this one of the cases where the benefits can outweigh the negatives

Interestingly this language has a concept of effect types that as far as I know has been only present in mostly research projects & a few general purpose languages like PureScript. Leaning on that to eliminate certain classes of bug from taking up your mental resources seems promising. Even in an ML I found myself wanting stricter guarantees about execution available while writing a PvP shooter for only a few clients, imagine 100! You can create DSLs to help with these things, but at that point I think it's asking to much for a beginner to learn both a new language and well enough to understand how DSLs can let you describe things with different semantics than you've already learned

I noticed they seem to have no mention of tagged enums/algebraic data types, which is unusual for a typed functional language, but there is an Optional type at least. I wonder if it has to do with the differences of their conditionals, which sound like they have far reaching implications, but I'm still not totally clear on how conditionals work in Verse

This has been hitting me hard lately in my late 20s. I'm realizing all of the cool "new" concepts I'm learning have been around since the 60s

It's made me rethink the supposed "skill reset" that happens in software which leads to software developers leaving for other roles more often than other engineering disciplines.

f.lux 4 years ago

I know this is anecdotal but tools like f.lux made a huge different for me. I grew up with difficulties falling asleep and blue light filters like f.lux made an immediate impact on my ability to fall asleep on time. I was no longer in my teens at the time so that may be a factor