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

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.

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!

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

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

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.

I agree that pretty much any 15 year old code base is going to get rough, but I think these languages have some clear footguns that aren't doing them favors either. I work on a codebase that isn't more than a few years old, and there's complexity issues from simple things like the language lacking good semantics for transforming data immutably, and that complexity spirals

I can attest that writing messy processes in languages that do address these concerns is absolutely possible, I've done so myself, but the mess is contained to a particular area and it's not as hard to follow which pieces of a system feed into another. Things as simple as making immutability the default and mutation explicit like Rust, and requiring modules be organized into a hierarchy like F# are huge wins. As much as I've gotten annoyed with F#'s project files hierarchy requirement because it requires some extra work/considerations for codependent types and codegen, it's amazing how much easier it is to jump into a new codebase where you can clearly see to understand behavior you start with the bottom of the file list, and to understand core logic/patterns you go to the top of the file list

I don't deny the value of the active record pattern where it works, but in almost every case I've used SQL over the past 5 years, I don't want a complex abstraction layer. I just want something to make it easy and safe to talk to the database for the 90% of straight forward queries we write.

With something like that, I feel as though I'd rather write my own active record system than use the configuration based systems we see with EF

I'm prone to winding up with too many open tabs when I use lots of atomic notes with links, and now I'm having to juggle a set of tabs while looking through this information.