Yes but wouldn't be great. The problem is that these ultra low level assembly languages actually throw away a lot of information that is useful to parallelism. Recursive functions are great for HVM, but when compiled to assembly, that structure is lost.
Yes that is the goal, but I'm not familiar enough with it to judge the complexity of such project. I do know GHCJS demanded tons of resource and efforts, so I do anticipate it will not be a simple task. That's why I want to support simpler languages like Elm and a Python-like language first...
The ultimate goal is indeed to compile any code to GPUs, but we can't change the logic of your program. It is just a bunch of sequential loops, there isn't much we can do about it! But you can still use a Python-like syntax to create highly parallel programs, specially if you like recursion or things like map, reduce, and working with trees/JSON in general.
Yes that is the ultimate goal! Although that is obviously a far future. Currently we only have funding to provide a few toy languages, but hopefully the results will be good enough to draw attention so we can scale and broaden support to more and more languages!
Exactly! Sorry if that sounded to be the case. We're first focusing on making the runtime as fast as possible. Next step is to support some simple toy lang (like a Haskell-like and a Python-like) for people to start using. Only then we can start compiling existing languages, which is a colossal task (due to languages like JS having a bajillion features).
Exactly, we're working on a guide for language designers. And while HVM-Core (the repo I posted today) is the lowest IR, I believe most languages should actually compile to HVM-Lang (to be released), which is a higher-level AST that is more familiar and does a lot for you (so you don't need you to write your own conversions from your language to interaction combinators and back).
Good question! There are several implementations of the full λ-calculus on interaction nets; that isn't the problem. The problem is that these solutions always came up with a constant time slowdown, which made interaction nets even less practical. The thing is, HVM is getting so fast that we're almost at the point where we can just say damn it, eat that slowdown, and still be faster. So, optimization after optimization, we're kinda brute-forcing our way into supporting full lambdas in practice. And the best is that with some pre-processing steps (like EAL inference) we could compile Haskell to the fastest version when it is safe to do so - which is more often than you'd think!
Yes we're hiring GPU developers to optimize the current runtime (which still has a lot of room) and to extend support to more architectures. GPU developers aren't exactly cheap nowadays though lol. I blame OpenAI.
As someone who has been studying type theory and developing strongly typed programming languages, that is a very strange take to me. It isn't untyped, it has a type: the GeometricAlgebra type, which just happens to have a very rich structure. Complaining about that is like complaining that Int isn't split into two types because it has negative and positive values. That makes no sense at all.
Watched and read it all and find it amazing work. Text editing on mobile is embarassingly terrible and the proposals presented are very solid. Props to the author.
Shut up and accept what? A company being closed source / for profit? Are we rioting against capitalism or something? Should I get my pitchforks? Just to be sure, we'll include literally all major tech companies, or is only OpenAI the target?
We get it. OpenAI is a for profit company now. The "Open" in name doesn't reflect their vision anymore. Can we stop it already? Or is this some kind of rant against for profit / closed source in general?
I'm Brazilian and Pix is great. No reason to use anything else. Our government is terrible, but our central bank is actually quite competent. Credit to where it's due.
Well, then perhaps you need to reflect where your research failed, because it clearly did. Everyone is using Discord; from adult professionals to clueless kids who barely know how to connect to Wifi. So, if all these clueless kids are there, perhaps it is time for you to realize the interface perhaps is actually easy and you need to reconsider your conceptions of what makes a great UX.
Where have you read that HVM beats C or Rust? That is not something I've ever written and we're far from that, specially considering the budget that has been thrown into Rust, although we could (and hope to) get there one day. This is possible in theory, because interaction nets are as lightweight as Rust, but have the added benefit of built-in parallelism. Please see the whole FAQ, I think it addresses all your questions. Let me know if you have any further questions.
(Also, exponentially faster is used on the technical sense here! Optimal evaluators can reduce some programs with linear time complexity, while conventional runtimes are exponential.)
Well, it should be a viable alternative to GHC once we implement full lambdas, but without them, it should be seen as a separate language, just like Rust.
The complete subset of lambda terms that HVM can soundly evaluate hasn't been identified yet. It is known that HVM can, at least, soundly evaluate all terms typeable on Elementary Affine Logic (EAL), but, while that is a huge set, it isn't comprehensive, as HVM can evaluate many terms outside of EAL, including recursive terms such as the Y-Combinator.
I think this kind of sentence makes such a huge disservice for the HVM. Rust closures also doesn't support the full λ-calculus! HVM supports way more λ-terms than Rust does. That said, we're working on full λ-calculus support, so this shouldn't be a problem soon.
I feel like no less than 10 years if the singularity doesn't kick in before that. Hardware and energy isn't progressing as fast as we'd like, and that is the main bottleneck. As in, imagine a world where we actually had the same computing power required to train (not run) GPT-4 in 1s in a phone? That kind of world is way beyond AGI and the cure of cancer IMO. Which is great, because it gives us a very objective goal to achieve these things. Sadly, I don't think we're nowhere near that. What was even the total energy consumption of GPT-4 training? Very hard to imagine computers will get that much better anytime soon. IIRC we have some kind of data that the a smartphone today has the power of the best supercomputer... of 30 years ago, right? Don't remember the source, sadly.
I agree with most of your points, we should definitely rewrite and tone down the README. The FAQ was written a few months after, due to that kind of negative reception. To address your points, note that by "superseding" the Turing Machine, I do not mean they can compute uncomputable functions! The meaning is that, while both are equivalent in terms of *computability*, Interaction Nets have improved *computational* characteristics, such as strong confluence and concurrency. This is a very technical aspect that is addressed on the paper I linked. Regarding not buying the claim of no GC needed, this is interesting, since this is a well stablished result: HVM is entirely linear, so it can avoid global GCs for the same reason as Rust. The difference is that HVM is more inherently high level, since its support for lambda is way more first-class than Rust's closures, which are comparably slow and almost guarantee borrow-checker hell.
Inpla is a very interesting project that is more elegant than HVM in several regards (as it doesn't need to worry about functional programming!) and should be more known. I've added a link to it from the HVM's repo a few months ago.
I love WASM - who doesn't? Maintaining a WASM target was included on HOC's current fundraise, and is essential to our JIT plans. I don't know much about typed assembly, but I guess it would enable optimizations that aren't possible without types, as well as increased safety - although I wonder if that's relevant, if the source language is already typed?
In general though, I think we should move away from procedural instructions towards "interactional" instructions. HVM's AST can be seen as an assembly language with high-level instructions like LAM-APP (lambda application) and FUN-CTR (pattern-matching), and that's possible precisely because beta reduction is O(1) on interaction nets. A hardware with HVM's interactional instructions could make let us break out of the Von Neumann bottleneck and make processors much faster. Here is a table of HVM's core instructions:
.-----------------------------------------------------.
| Opcode | Effect | Cost |
|-----------|---------------------------------|-------|
| APP-LAM | applies a lambda | 2 |
| APP-SUP | applies a superposition | 4 |
| OP2-NUM | operates on a number | 2 |
| OP2-SUP | operates on a superposition | 4 |
| FUN-CTR | pattern-matches a constructor | 2 + M |
| FUN-SUP | pattern-matches a superposition | 2 + A |
| DUP-LAM | clones a lambda | 4 |
| DUP-NUM | clones a number | 2 |
| DUP-CTR | clones a constructor | 2 + A |
| DUP-SUP-0 | clones a superposition | 4 |
| DUP-SUP-1 | undoes a superposition | 2 |
| DUP-ERA | clones an erasure | 2 |
|-----------------------------------------------------|
I think BlueSpec is impressive and a good direction in the (arguably messy) hardware language domain. It is likely that we'll consider using it in our research and projects.