[Info-vax] Programming Languages (was: Re: VMS - The new file system. What do we know about it?...)

[Stephen Hoffman]

On 2016-11-14 18:57:12 +0000, Simon Clubley said:

> On 2016-11-14, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
>> On 2016-11-14 00:23:14 +0000, Simon Clubley said:
> ... I knew there was a lot of work done about that time to allow C in 
> the kernel (I've only ever written VMS device drivers in C) but I had 
> thought for some reason it was a driver only thing; I didn't realise it 
> extended to the rest of VMS as well.

It was to allow inner-mode code to be written in C.   Another part of 
the work was the kernel C library.   
http://labs.hoffmanlabs.com/node/769   There were all sorts of other 
details involved, such as adding pragmas to the compiler, and

>> As for ~2021 to ~2026 and the future and as much as I like and use C 
>> for system-level development work, it has problems and issues.   
>> Locally deprecating specific calls from the standard library is a 
>> common start toward more reliable C code is a start, as are knobs such 
>> as QUESTCODE.   Tools for scanning C code for errors, vulnerabilities 
>> and for dependencies on undefined behavior are increasingly common 
>> practice too, both by the original authors of the code involved and 
>> also by folks looking for weaknesses in the code.
> 
> In addition to language specific vulnerabilities, there are also the 
> vulnerabilities or issues which are independent of implementation 
> language such as missing logic checks or things the developer simply 
> didn't think to check for as well as trusting external data too much.

Ayup.

Rust addresses some of the more common issues with C, C++, Bliss or 
Macro32 development and maintenance, within the language itself.    But 
Rust doesn't address application- or OS-level issues and difficulties 
and security.

OpenVMS itself tends to lack APIs and implementations for those 
considerations, and the documentation for writing privileged-mode code 
is weak, and there are various and sundry other issues here.   The 
approach and the APIs currently provided by OpenVMS means that 
developers get to build up their own code and their own libraries and 
frameworks, or get to integrate some version of {open source library} 
and then hopefully remember to keep that current.   All certainly 
feasible, but also a good way to create various latent bugs as some of 
the sequences are complex at best.   Contrast this with what's 
available on some other platforms, were I don't have to create and 
debug and maintain pages and pages of bespoke code just getting a 
network connection established and secured, for instance.    Or any 
number of other tasks.  Lots of ways to make mistakes.   Lots of glue 
code necessary with OpenVMS, too — the sort of source code that we're 
often blind to as developers too, until we work with a language or a 
platform or an API design that reduces or eliminates all that glue code 
and that code-related baggage.

>> Accordingly, I'd be looking past C for system-level work.   Probably 
>> not to C++, though there are large system-level and application 
>> projects using (usually a subset of) C++ for development.   Definitely  
>> not to BASIC, Fortran or such, though those are fine choices for  
>> various applications.   Quite probably toward Rust for wholesale 
>> rewrites or wholly new system-level work, though that'd be a major  
>> shift for VSI and for OpenVMS end-users that might follow, and there 
>> are trade-offs there, too.  Rust avoids various of the worst of the 
>> holes within C, and Rust code is intended to interoperate with C 
>> libraries and frameworks.   There are some definite downsides to 
>> choosing Rust, not the least of which are its recent advent (such 
>> newness being major-scary for many organizations using OpenVMS), and 
>> that Rust isn't presently available on OpenVMS.   I would also look at 
>> Rust for application-level work, though there are other languages I'd 
>> consider there and that might be better choices than Rust and that are 
>> better choices than C, C++, BASIC and such.
> 
> The major problem with Rust is that it tends to make Perl code look 
> readable by comparison.

Rust syntax isn't that far off of C, C++ and similar languages, and 
which is the most typical comparison.

As for readability, many of the languages I've worked with have been 
problematic.  There are issues with Bliss — "keep adding dots until the 
code crashes, then remove one dot" is one of the canonical Bliss jokes 
— and with Macro32 — the macro capabilities are substantial and 
powerful and can be quite subtle, and some Macro32 code and some macros 
can make your eyes bleed.   COBOL is certainly readable, but there's 
always a whole lot to read when you're working with COBOL.   Languages 
like BASIC and Fortran can take staggering amounts of source code to 
do... not all that much, too.    It's all trade-offs.   Unreadable and 
unmaintainable code is possible in any language.

> It's designers have forgotten that you write the code once, but read it 
> many times - they have embarked on a minimalistic keyboard typing 
> language style which would probably make a TECO advocate proud...

Again, Rust syntax is not that far off of C or C++.   For better and 
for worse, of course.

> BTW, have the Rust developers stopped making incompatible changes to 
> newer versions of the language/APIs yet ?

Rust has been considered stable for almost as long as VSI has been around.

> It's not the fact Rust is new which is the major concern for me; it's 
> the above two issues which are the problems for me.

I'm conflicted around API stability and source code compatibility.   
That was and is one of the best features of OpenVMS, and it's also a 
feature that has utterly screwed OpenVMS.

But in general, I don't expect VSI to head in the direction of Rust as 
their primary implementation language.   Not anytime soon.   They're 
appropriately and undoubtedly exceedingly busy with the port and with 
necessary remediation to the foundation and the tools, and haven't 
(yet) started moving the platform forward.   That eventual work may 
(will?) involve security hardening and sandboxes, parsers, better 
frameworks, an installation- and patching-related overhaul, migration 
to LDAP authentication, and who knows what else.

http://rustbyexample.com/index.html
https://doc.rust-lang.org/book/
https://www.rust-lang.org/en-US/faq.html



-- 
Pure Personal Opinion | HoffmanLabs LLC