[Info-vax] VMS Software Q1 '23 Update

[Craig A. Berry]

On 2/3/23 8:36 AM, Arne Vajhøj wrote:
> On 2/3/2023 8:58 AM, Dan Cross wrote:
>> In article <trhi5t$13ikm$2 at dont-email.me>,
>> Arne Vajhøj  <arne at vajhoej.dk> wrote:
>>> On 2/2/2023 10:08 AM, Single Stage to Orbit wrote:
>>>> On Thu, 2023-02-02 at 06:40 -0800, plugh wrote:
>>>>>> I'm currently teaching myself Rust and have been for the past two
>>>>>> years. It is a most interesting programming language.
>>>>>
>>>>> It would be interesting to make this available on the new VMS. I had
>>>>> some notes on this, but I don't think I kept them.
>>>>
>>>> LLVM supports x86_64 and ELF out the box, so I imagine the truly hard
>>>> bits wil be the bindings to OpenVMS calls and data structures.
>>>
>>> I suspect that there is a bit more to get a LLVM based compiler
>>> working on VMS x86-64 than that.
>>>
>>>>                                                                 Async
>>>> and locking primitives will need to be implemented, that won't be easy.
>>>
>>> Isn't async build on top of threads?
>>
>> No, not necessarily.  async can be used to build threads,
>> and async executors can run in threads, but the two are
>> in many ways duals of one another.
> 
> It is two very different programming models.
> 
> But the usual async await model is that it is syntactic
> sugar that under the hood creates a task that get scheduled
> to run in a thread pool.
> 
>  From as programming model perspective it is:
> 
> async await - task and thread pool - raw threads
> 
> But implementation wise it is different levels of abstraction:
> 
> async await
>      |
> task and thread pool
>      |
> raw threads
> 
> For someone developing applications in Rust then the
> programming model is what is important.
> 
> But for porting Rust compiler and runtime to a new OS,
> then the implementation matters.
> 
> My expectation would be that if the OS expose a
> working pthreads C library then Rust could do
> async await on that platform as all the layers
> in between would work.
> 
> Of course all this stuff is most useful if
> there is support for async IO. VMS most definitely
> support that. But depending on what Rust rely on
> then there may be a gap between what the Rust
> runtime expects and what VMS has.
> 
> Bridging *nix centric IO and VMS IO can be
> tricky. Just look at the Java IO on VMS
> mess.
> 
> So I am not definitely not saying that getting
> Rust running on VMS will be easy.

The fact that Erlang exists on VMS but (IIRC) without its concurrency
capabilities might be an indication of the challenges.  It looks like
Rust offers several different concurrency models, e.g.:

https://blog.logrocket.com/deep-dive-concurrency-rust-programming-language/