6 ms·
I would want something like C++/Typescript/C#/Python, but only the good parts. - Multiparadigm, that means traditional OOP, but also first class functions (wel
by captainmuon 4y ago
I would want something like C++/Typescript/C#/Python, but only the good parts.
- Multiparadigm, that means traditional OOP, but also first class functions (well first class everything)
- Compiles to native code, runs relatively fast
- Designed from the ground up for async/await
- No undefined behavior
- Statically typed, but with the feeling that the compiler is helping and not punishing you. I get that feeling from Typescript, Python+MyPy, C++ on a good day, Kotlin.
I would also love to experiment with a few ideas of mine:
- Voluntary checked exceptions (You mark a block specifically and it is a syntax error if an exception could possibly leak that block).
- First class observables for easy GUI binding
- You can lift the action of a piece of code into a variable. Then you can reason about this action. For example, you would write imperative looking code to modify a document, and it would generate objects for the "command pattern" so you'd have undo functionality. Or you could lift a longer running action and have it running on a thread and cancellable. I imagine this to be closures on steroids.
- goodpoint 4y agoYou described Nim.
- captainmuon 4y agoNim is pretty cool, and I always look for a way to use it. Started a couple of side projects in Nim and it is a great balance of close to metal like C and expressive like Python, but with a proper type system. My main criticism is that it feels like a large language with all kinds of weird features and you can write very clever and dangerous code. A tiny bit Go-like restraint and it would be perfect.
- kaba0 4y agoWhy async/await? As go and soon java with loom shows it is quite a misfeature, if anything. Otherwise, I like your idea on checked exceptions, I think they are a very good feature, but somehow got a bad name and thus not experimented with as often. Your last point sounds quite macro-ish, so I guess the LISP-fanatics will come in in droves and tell you that they already have that in their language :D But relatedly, transactions sound similar in a way.
- karmakaze 4y agoHow is async/await a misfeature in Go? I can see the problem in js with 'function color' but everything in Go are goroutines not just some.
- kaba0 4y agoI meant to write that Go and Java’s Loom show us that other languages stuck with async have it worse than these two.
- captainmuon 4y agoI compare async/await with manual threading, or with callback hell, and in both cases it is a great improvement. I haven't tried Java with Loom and haven't done much in Go, so maybe that style is indeed better. Right now it feels spooky if my lightweight thread can suspend at any time, deep down in some function call. And what if you accidentially don't call a "loomified" IO function, but a plain blocking one? I like the explicitness of "cooperative" await but agree it can be a bit tedious. Maybe there is a better way of integrating "asyncness" in the type system? Yeah the last idea came when I added undo/redo to an app. I had to go mechanically through everything and make every change to my model go through a "Command" subclass. When I encounter something like this I think "why can't the compiler do this for me?". Probably solvable by LISP macros, or transactions as you said.
- kaba0 4y agoLoom also comes with something called structured concurrency and many other improvements to make taming lightweight threads easier. Nonetheless, Java is a very “pure” ecosystem in that basically 99.9% of the ecosystem is written in Java itself — so besides the tiny amount of FFI, every method you might call is ready to be magically unblocking.