6 ms·

Hi! Author here. Really curious what you all think. It's a pretty crazy idea but maybe there's something to it! Hacker News is always a special place for ideas

Hi! Author here. Really curious what you all think. It's a pretty crazy idea but maybe there's something to it! Hacker News is always a special place for ideas like this — you never know what you're gonna get ;) — so I'm looking forward to discussing this with y'all!

mc4ndr3 5y ago
Why not write Rust directly, and target WASM for client side environments? I support efforts to tune existing tech stacks. But there is such a more direct path to performance, reliability, etc etc by dropping (alt)JS entirely now that anything can compile to WASM.
- janpaul123 5y ago
  I agree; that is what we built the Zaplib framework for. But the reality is that there are tons and tons of existing JS/TS codebases out there, and it'd be nice to have an incremental speedup path for them too.
- michael_j_ward 5y ago
  In the article https://zaplib.com/docs/blog_ts++.html#best-of-both-worlds https://zaplib.com/docs/blog_ts++.html#best-of-both-worlds
- deleted 5y ago
  [deleted]
mattgreenrocks 5y ago
The TypeScript++ example looks like the type of code that JITs typically like. Python has Numba, where users affix a @jit annotation to functions to request that. It works pretty well in my experience. However, at this point, I'm mostly of the opinion that langs need some notion of mechanical sympathy if they want to be used for high-performance. JS engines probably have tens of millions of dollars of dev effort poured into them by now, yet they get soundly beaten by WASM, which is much younger. The conceptual foundation matters a lot. That said, there's probably a nice space for an ergonomic, reasonably fast PL that sits between Rust and JS.
- isaacimagine 5y ago
  > JS engines probably have tens of millions of dollars of dev effort poured into them by now And JS engine JIT codegen modules are put to good use compiling wasm.
- janpaul123 5y ago
  Good points. I agree that choosing the abstractions wisely is key here.
- discreteevent 5y ago
  That was the main motivation behind the inventors of dart. They got frustrated with all the hacks they had to put into V8 just because JavaScript was so mechanically unsympathetic. You can hardly blame then because they originally came from a background of developing smalltalk and self VMs.
  - emteycz 5y ago
    Isn't JS much more Smalltalk-ish than Dart? I don't have much experience with Dart, but it always seemed like a very OOP language to me (and not in the "message passing" meaning).
  - mattgreenrocks 5y ago
    This is super interesting to me as a VM geek. I'd written off Dart as "Google's Swift" for the most part, but this makes a lot more sense. Thanks for the comment.
- notriddle 5y ago
  > That said, there's probably a nice space for an ergonomic, reasonably fast PL that sits between Rust and JS. Other than not running natively in web browsers, isn't that language called Ocaml?
  - scns 5y ago
    Is it still possible to use the ReasonML syntax for native binaries?
novocantico 5y ago
The main feedback I have is that I wanted to read this near the end of my lunch break, because I've been interested for years in the idea that a reasonably-restricted subset of TypeScript (who needs all that dynamism) can almost definitely be compiled to machine code and be made super fast, faster than V8 -- so I was looking for a TLDR in this article and spent a couple minutes looking for it and then just reading whole paragraphs and still don't really know what you've got here.
- mattdeboard 5y ago
  dang imagine how much more leisurely you could've read the article if you didn't also take some of your lunch break to write this comment!
- janpaul123 5y ago
  Good feedback; I should add a TL;DR. Basically this is a proposal to create a language that sits somewhere between Typescript and Rust, and which you can incrementally adopt if you already use Typescript.
tomxor 5y ago
Your example really clicked with me, having written a substantial quantity of JS in a "memory managed" way to avoid GC, and avoiding memcpy by passing buffers in place of pointers. My initial instinct is that putting such considerations behind a preprocessor syntax has the disadvantage of making them more opaque and magic, and that I personally would continue to do such things more explicitly - which I realise is an ironic thing to say about an untyped, interpreted language, it's probably just the little pseudo "grey beard" on my shoulder which occasionally whispers silly things about "building their own computer out of rocks and twigs". I guess the point is that there's a balance to the cost vs benefit: making it more convenient (what you call ergonomics), making it more accessible to those that were less likely to manually use that technique, and perhaps resulting in an average of more performant code; but at the cost of more obscurity, and more "magic", perhaps resulting in less educated programmers. I'm probably overthinking it. Ultimately this argument even applies to for loops, but it's worth being conscious of that cost - it's likely a good idea.
- janpaul123 5y ago
  Yeah I hear you; and even allude to that in some parts of the article, like this part: > Another idea to make Typescript–– a bit less restrictive and more ergonomic, would be to use reference-counting of objects, and then try to optimize most away using compile-time reference counting as pioneered by Lobster. This gives most of the advantages of manually managed memory, but makes the ownership model much easier to reason about. It is however slightly less performant, and more importantly, makes performance less predictable, since it becomes more reliant on compiler cleverness. Even Rust can hide actual performance behind abstractions, and I've already been bitten by that a few times.. Not sure what the right solution is here, but I agree that it's super important to think about this when designing a language like this.
- triyambakam 5y ago
  > having written a substantial quantity of JS in a "memory managed" way to avoid GC, and avoiding memcpy by passing buffers in place of pointers. What projects were you working on that required that? It sounds interesting
pjmlp 5y ago
Love it, you should check the Typescript compiler used by MakeCode as well. Maybe there are some ideas there.
transitivebs 5y ago
Really interesting article. I was doing some high-level research on a related question the other day: https://transitivebullsh.it/webassembly-research-9e231b80e6d54306adceff38ff22954c https://transitivebullsh.it/webassembly-research-9e231b80e6d... I know you've responded to a few people on here that Assemblyscript doesn't address the main issues you're talking about in the article, but honestly it does have a lot of things going for it. I'd love to see a more direct breakdown of this space that explains why prior works like assemblyscript, nectarjs, walt, etc all fall short, and where an ideal solution would need to do better. ^^ this is the type of thing I'd love to chat about if you're interested btw
- janpaul123 5y ago
  Nectarjs is interesting; I wasn't aware of that. How did it manage to avoid (for example) a garbage collector without making changes to the language?
Syzygies 5y ago
You might want to reconsider the ++ naming convention. Many people capable of a critical appraisal of C++ wouldn't want an association with C++. The prejudice that your name triggers is that you don't understand what others think C++ got wrong, and you're likely to be making the same mistakes. It doesn't look like you're making the same mistakes, but why trigger that prejudice?
vanderZwan 5y ago
"Why can't we have a language that compiles to highly optimized JS?" is definitely something that has crossed my mind, especially in situations where I reached for faking structs with TypedArrays. As soon as that gets more complicated than something like an array of x,y,z points things get difficult (not to mention almost impossible to debug) really fast. I suspect that if you could come up with an easy way to express a large tree really efficiently in a TypedArray in a relatively generic way, that you already will do better than most attempted solutions here.

mc4ndr3 5y ago

Why not write Rust directly, and target WASM for client side environments? I support efforts to tune existing tech stacks. But there is such a more direct path to performance, reliability, etc etc by dropping (alt)JS entirely now that anything can compile to WASM.

janpaul123 5y ago
I agree; that is what we built the Zaplib framework for. But the reality is that there are tons and tons of existing JS/TS codebases out there, and it'd be nice to have an incremental speedup path for them too.
michael_j_ward 5y ago
In the article https://zaplib.com/docs/blog_ts++.html#best-of-both-worlds https://zaplib.com/docs/blog_ts++.html#best-of-both-worlds
deleted 5y ago
[deleted]

mattgreenrocks 5y ago

The TypeScript++ example looks like the type of code that JITs typically like. Python has Numba, where users affix a @jit annotation to functions to request that. It works pretty well in my experience. However, at this point, I'm mostly of the opinion that langs need some notion of mechanical sympathy if they want to be used for high-performance. JS engines probably have tens of millions of dollars of dev effort poured into them by now, yet they get soundly beaten by WASM, which is much younger. The conceptual foundation matters a lot. That said, there's probably a nice space for an ergonomic, reasonably fast PL that sits between Rust and JS.

isaacimagine 5y ago
> JS engines probably have tens of millions of dollars of dev effort poured into them by now And JS engine JIT codegen modules are put to good use compiling wasm.
janpaul123 5y ago
Good points. I agree that choosing the abstractions wisely is key here.
discreteevent 5y ago
That was the main motivation behind the inventors of dart. They got frustrated with all the hacks they had to put into V8 just because JavaScript was so mechanically unsympathetic. You can hardly blame then because they originally came from a background of developing smalltalk and self VMs.
- emteycz 5y ago
  Isn't JS much more Smalltalk-ish than Dart? I don't have much experience with Dart, but it always seemed like a very OOP language to me (and not in the "message passing" meaning).
- mattgreenrocks 5y ago
  This is super interesting to me as a VM geek. I'd written off Dart as "Google's Swift" for the most part, but this makes a lot more sense. Thanks for the comment.
notriddle 5y ago
> That said, there's probably a nice space for an ergonomic, reasonably fast PL that sits between Rust and JS. Other than not running natively in web browsers, isn't that language called Ocaml?
- scns 5y ago
  Is it still possible to use the ReasonML syntax for native binaries?

novocantico 5y ago

The main feedback I have is that I wanted to read this near the end of my lunch break, because I've been interested for years in the idea that a reasonably-restricted subset of TypeScript (who needs all that dynamism) can almost definitely be compiled to machine code and be made super fast, faster than V8 -- so I was looking for a TLDR in this article and spent a couple minutes looking for it and then just reading whole paragraphs and still don't really know what you've got here.

mattdeboard 5y ago
dang imagine how much more leisurely you could've read the article if you didn't also take some of your lunch break to write this comment!
janpaul123 5y ago
Good feedback; I should add a TL;DR. Basically this is a proposal to create a language that sits somewhere between Typescript and Rust, and which you can incrementally adopt if you already use Typescript.

tomxor 5y ago

Your example really clicked with me, having written a substantial quantity of JS in a "memory managed" way to avoid GC, and avoiding memcpy by passing buffers in place of pointers. My initial instinct is that putting such considerations behind a preprocessor syntax has the disadvantage of making them more opaque and magic, and that I personally would continue to do such things more explicitly - which I realise is an ironic thing to say about an untyped, interpreted language, it's probably just the little pseudo "grey beard" on my shoulder which occasionally whispers silly things about "building their own computer out of rocks and twigs". I guess the point is that there's a balance to the cost vs benefit: making it more convenient (what you call ergonomics), making it more accessible to those that were less likely to manually use that technique, and perhaps resulting in an average of more performant code; but at the cost of more obscurity, and more "magic", perhaps resulting in less educated programmers. I'm probably overthinking it. Ultimately this argument even applies to for loops, but it's worth being conscious of that cost - it's likely a good idea.

janpaul123 5y ago
Yeah I hear you; and even allude to that in some parts of the article, like this part: > Another idea to make Typescript–– a bit less restrictive and more ergonomic, would be to use reference-counting of objects, and then try to optimize most away using compile-time reference counting as pioneered by Lobster. This gives most of the advantages of manually managed memory, but makes the ownership model much easier to reason about. It is however slightly less performant, and more importantly, makes performance less predictable, since it becomes more reliant on compiler cleverness. Even Rust can hide actual performance behind abstractions, and I've already been bitten by that a few times.. Not sure what the right solution is here, but I agree that it's super important to think about this when designing a language like this.
triyambakam 5y ago
> having written a substantial quantity of JS in a "memory managed" way to avoid GC, and avoiding memcpy by passing buffers in place of pointers. What projects were you working on that required that? It sounds interesting

pjmlp 5y ago

Love it, you should check the Typescript compiler used by MakeCode as well. Maybe there are some ideas there.

transitivebs 5y ago

Really interesting article. I was doing some high-level research on a related question the other day: https://transitivebullsh.it/webassembly-research-9e231b80e6d54306adceff38ff22954c https://transitivebullsh.it/webassembly-research-9e231b80e6d... I know you've responded to a few people on here that Assemblyscript doesn't address the main issues you're talking about in the article, but honestly it does have a lot of things going for it. I'd love to see a more direct breakdown of this space that explains why prior works like assemblyscript, nectarjs, walt, etc all fall short, and where an ideal solution would need to do better. ^^ this is the type of thing I'd love to chat about if you're interested btw

janpaul123 5y ago
Nectarjs is interesting; I wasn't aware of that. How did it manage to avoid (for example) a garbage collector without making changes to the language?

Syzygies 5y ago

You might want to reconsider the ++ naming convention. Many people capable of a critical appraisal of C++ wouldn't want an association with C++. The prejudice that your name triggers is that you don't understand what others think C++ got wrong, and you're likely to be making the same mistakes. It doesn't look like you're making the same mistakes, but why trigger that prejudice?

vanderZwan 5y ago

"Why can't we have a language that compiles to highly optimized JS?" is definitely something that has crossed my mind, especially in situations where I reached for faking structs with TypedArrays. As soon as that gets more complicated than something like an array of x,y,z points things get difficult (not to mention almost impossible to debug) really fast. I suspect that if you could come up with an easy way to express a large tree really efficiently in a TypedArray in a relatively generic way, that you already will do better than most attempted solutions here.