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
When I used to program Java I absolutely loved hot code swap and was always amazed how little people even knew it was possible.
If you have a massive codebase no matter how fast your compiler is, re-compiling is going to be slow. But hot code swap is even better in that you can keep any state around without having to set it up all over again.
In Java I could change a method implementation with the program running and as long as I didn't touch my class state it would just work. Re-compilation was slow, but hot code swap was _fast_ and I maybe did a recompile 3-5 times per day total.
Bear in mind that the underlying protocol used to request hot swap on Java is a lot more expressive than the standard HotSpot implementation is. If you use the Jetbrains Runtime (a fork of OpenJDK) or the GraalVM "Espresso" VM (a.k.a. Java on Truffle) then you can do way more hotswapping than you'd be able to normally.
Espresso goes further and doesn't only allow hot swapping but lets you write plugins that react to hot swaps of code:
That is pretty neat, I haven't done serious Java development in ~10 years but I do vaguely remember hot swapping would eventually cause out of memory errors. I was using standard OpenJDK 6 and 7 at the time.
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
I'm confused at how you get left out of the loop. Do they just not include you in group chats?
I have a group chat right now with my sister who is also iPhone and my mom who is Android, we all have zero issues in group chat.
Only thing that changed is the group chat goes from being iMessage blue bubbles to just all green chats due to the one Android user.
Everything else is the same. Well when my sister like reacts to our messages because she doesn't quite realize that it's not a group iMessage but just a group SMS then iMessage sends `<sister> liked "<message she liked>"` texts to the rest of us but shows the like reaction to her.
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.
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
Me too. I think the ReScript people were well within their rights to fork off - they realized that what they wanted was a better JS and compatibility with OCaml held them back, but it also split an already small community and made it hard for me to convince even myself to pick OCaml for hobby projects. I'm glad melange is picking up and becoming viable, and once the situation with multicore and web frameworks built on multicore stabilizes I'd love to make a full-stack OCaml web app.
I'm also pleased to see this, as somebody who likes functional programming and ML dialects. I don't need braces just because C has them.
BuckleScript, when it was called that, was incredibly compelling for me. This was in part thanks to being blazing fast, unlike TypeScript. So I am pleased to see a spiritual successor.
I have only worked with ReScript for about a year before switching to ClojureScript (which was a better fit for my project), but I really enjoyed the experience and genuinely wish it would become a more popular alternative to TypeScript for devs who are coming from JS and are looking to dive into FP and static typing.
The developer team did a great job with highly optimized and readable JS compilation, great integration and interop with React, JSX support, raw JS and even TypeScript (see GenType) and now it also supports async/await. The website is also really well made and provides good documentation and a nice forum to get help when needed.
However, Melange seems to head in a good direction too and I guess it would be amazing for people who are already familiar with OCaml and want to integrate with libraries and codebases there. So I think both projects are valuable in their own right for different use-cases.
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.
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
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
Just because functional languages have immutable data locally doesn't make them any more suitable for handling data across "100 remote clients simultaneously". You need a bunch of stuff on top to make it work. Even reacting to state changes on a remote client is a problem in itself, you you can't wave it away with "but immutability".
> but I'm still not totally clear on how conditionals work in Verse
To be honest, there's nothing clear about Verse at all. It promises to be everything for everybody, but is extremely light on details.
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.
This was also a big one for me. The best workaround I've come up with so far is to set up a global hotkey to toggle microphone mute in KDE, and then set my Discord (etc.) to have very sensitive "voice activation" settings. Essentially I've replaced push to talk with "push to toggle mute". Not the same thing, but I got used to it pretty quick.
Having read some of the threads on the freedesktop wayland gitlab repo about push to talk, I'm not confident push to talk or any other system for applications to register a global hotkey is something they'll deliver any time soon (if ever).
