Give feedback on ValueScript

[voltrevo]

ValueScript is free and open source. We want it to be guided by community feedback.

Comment here for small things or questions about giving substantial feedback.

If you have something detailed or thorny, please open a dedicated issue for it.

[Metalymph]

Hi! First of all congratulations for your great job, it's indeed a good improvement over TS/JS environment in terms of safety (avoiding side effects) and performance thanks to the no GC to RC aspect. There are however some points which are not clear to me, being a subsystem forced to interact with the outer world:

• If functions are pure by default, how you handles the specific cases where you want to pass a parameter from TypeScript to the inner ValueScript execution and have it back (essentially a "projection" of the mutable value) in order to avoid multiple allocations? For instance in the request/response model you can avoid a good amount of dynamic allocations rewriting a specific pre-allocated buffer and doing so, not instantiating a response (and also some requests) object to return. Supposing i use ValueScript for a request handler so, how can i force the subsystem to take a "mutable" param?
• Which is the context switch cost of calling the ValueScript environment evaluation inside (for instance) a TypeScript program?
• Since ValueScript launches a new thread instead of a concurrent task on the same single threaded JS runtime, can i lunch multiple instances of ValueScript runtime?

Thanks for your time and i hope i'm been specific enough :)

[voltrevo]

Hi @Metalymph. Thanks for your feedback and sorry for the slow reply.

If functions are pure by default, how you handles the specific cases where you want to pass a parameter from TypeScript to the inner ValueScript execution and have it back (essentially a "projection" of the mutable value) in order to avoid multiple allocations? For instance in the request/response model you can avoid a good amount of dynamic allocations rewriting a specific pre-allocated buffer and doing so, not instantiating a response (and also some requests) object to return. Supposing i use ValueScript for a request handler so, how can i force the subsystem to take a "mutable" param?

Well if you want to keep the ValueScript system pure, then you don't do that. However, these kinds of foreign interactions are planned, so that you can introduce the kinds of things you're talking about if you choose.

Which is the context switch cost of calling the ValueScript environment evaluation inside (for instance) a TypeScript program?

Good question. Not sure yet.

Since ValueScript launches a new thread instead of a concurrent task on the same single threaded JS runtime, can i lunch multiple instances of ValueScript runtime?

Absolutely :).

[Metalymph]

Hi @voltrevo and thanks for your kind answer.

Having multiple isolated runtimes is a good advantage but only if you have a way to preallocate the single runtimes before the several calls to start the runtimes, avoiding the context switch costs at least partially (the warm-up/launching part) exactly like a executors pool.

This is a good project especially for TS related codebases indeed. Congratulations for your great work :) !

[simonvarey]

Thanks so much for this language! I've been thinking for a while that something like this would help for writing bug-free TypeScript, so I was really glad to see that you had implemented these ideas.

I was wondering if you had though any more about transpiling to JavaScript. That seemed like a major use case to me, replacing/extending compiling from TypeScript. I have been playing around a bit with some related ideas in my value-semantics module, but I haven't tried to implement copy-on-write functionality in JavaScript.

I would also make the fact that ValueScript uses structural comparison more prominent, as the lack of structural comparison in JavaScript is one of its most annoying deficiencies.

[voltrevo]

@simonvarey Hey! I'm glad you like it :).

I've taken a step back from ValueScript but still have hopes to develop it further in the future. However, I forked ValueScript to create Summon for the purpose of generating circuits for MPC cryptography. That project is very active, so you might find it interesting. (Also: mpc.pse.dev.)

I was wondering if you had though any more about transpiling to JavaScript.

It's definitely an interesting alternative. I've been more interested in intentionally avoiding dependence on a JS engine to maximize portability. This isn't to avoid JS, I love JS, but you can run in JS via WebAssembly rather than generating JS code. I haven't made this approach particularly available/accessible, but you can take a look at how the playground does it for an example. The thing is, if you want ValueScript to compile to JS so that they can be more deeply interoperable, then I think that doesn't really work - they just don't fit together properly. I think it's better to simply pass messages between the systems, which you can do with the WebAssembly solution (which could be done a lot better than the unofficial implementation in the playground). What's more interesting to me is that ValueScript could be more performant by transpiling to JS, but I just haven't gotten around to trying it, and probably won't for quite some time now.

[simonvarey]

Summon looks very interesting, although I must admit the cryptography and zero-knowledge proof stuff mostly goes over my head.

I think I had a slightly different use case for transpiling ValueScript to JavaScript. You see, I’m not a huge fan of JavaScript, but I have to use it for web development. (Well, I suppose with WebAssembly I don’t need to use JavaScript, but using JavaScript makes things easier in some ways). What I had in mind was a workflow similar to TypeScript, where a whole module is written ValueScript, and then transpiled into JavaScript as a whole. ValueScript/JavaScript interoperability therefore isn’t an issue, and on the web we have a JS engine anyway. Attempting to import other JS libraries, and using web APIs, are issues that would still need to be addressed.

Anyway, I think there might be something there, so I’ll keep investigating,