On 4/5/2022 8:21 PM, Dan Cross wrote:
> In article <t2ilf1$18mj$1@gioia.aioe.org>,
> chris <chris-nospam@tridac.net> wrote:
>> I think the point is that languages take time to evolve and the path
>> can be unstable until there is enough critical mass to produce a fully
>> documented and standard version. I would expect that to take a decade
>> or more. No good for serious work without that professionalism. Toy
>> and experimental otherwise.
>
> Java doesn't have a "standard" in the sense described here, but
> much as I don't care for it as a language I'd be hard pressed to
> describe it as a "toy" or "no good for serious work."

Java is not ISO/ANSI/ECMA standardized.

But the JCP process is really very similar to ISO/ANSI/ECMA.

Arne

In article <jb43vkFbiv7U2@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>On 4/5/22 19:46, Arne Vajhøj wrote:
>>
>> C and C++ are currently dominating the low level code area, but
>> there are some well known problem.
>>
>> Two of those problems are:
>> * buffer overruns
>> * memory leaks
>
>Both those problems were fixed 40 years ago. The fixes were
>ignored and the company offering Safe C went out of business.

This is simply false. That there existed _one_ implementation
that claimed to "fix" C 40 years ago does not mean that the
problems with C were fixed.

Moreover, buffer overruns and memory leaks are just two classes
of problems that some implementations may have taken steps to
fix. There are many, many others that more modern languages
address: type incompatibilities, pointer safety, non-nullable
reference types, well-defined ownership semantics, and many,
many others.

- Dan C.

In article <624cdd77$0$704$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 4/5/2022 8:21 PM, Dan Cross wrote:
>> In article <t2ilf1$18mj$1@gioia.aioe.org>,
>> chris <chris-nospam@tridac.net> wrote:
>>> I think the point is that languages take time to evolve and the path
>>> can be unstable until there is enough critical mass to produce a fully
>>> documented and standard version. I would expect that to take a decade
>>> or more. No good for serious work without that professionalism. Toy
>>> and experimental otherwise.
>>
>> Java doesn't have a "standard" in the sense described here, but
>> much as I don't care for it as a language I'd be hard pressed to
>> describe it as a "toy" or "no good for serious work."
>
>Java is not ISO/ANSI/ECMA standardized.
>
>But the JCP process is really very similar to ISO/ANSI/ECMA.

Sounds kind of like the Rust RFC process, but some posters here
seem to have suggested that without a document produced under
the auspicies of a relevant standards body, a language is not
viable for serious work.

- Dan C.

On 4/5/2022 8:27 PM, Dan Cross wrote:
> In article <624cdd77$0$704$14726298@news.sunsite.dk>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 4/5/2022 8:21 PM, Dan Cross wrote:
>>> In article <t2ilf1$18mj$1@gioia.aioe.org>,
>>> chris <chris-nospam@tridac.net> wrote:
>>>> I think the point is that languages take time to evolve and the path
>>>> can be unstable until there is enough critical mass to produce a fully
>>>> documented and standard version. I would expect that to take a decade
>>>> or more. No good for serious work without that professionalism. Toy
>>>> and experimental otherwise.
>>>
>>> Java doesn't have a "standard" in the sense described here, but
>>> much as I don't care for it as a language I'd be hard pressed to
>>> describe it as a "toy" or "no good for serious work."
>>
>> Java is not ISO/ANSI/ECMA standardized.
>>
>> But the JCP process is really very similar to ISO/ANSI/ECMA.
>
> Sounds kind of like the Rust RFC process, but some posters here
> seem to have suggested that without a document produced under
> the auspicies of a relevant standards body, a language is not
> viable for serious work.

I think several languages has been inspired by the JCP process.

For those not familiar with the process here is the short version:
- an expert group is formed
- the expert group produces a draft
- draft goes into public review and may be updated
based on feedback
- draft get approved or rejected by vote in the Executive Committee

Arne

On 4/5/2022 8:36 PM, Arne Vajhøj wrote:
> On 4/5/2022 8:27 PM, Dan Cross wrote:
>> In article <624cdd77$0$704$14726298@news.sunsite.dk>,
>> Arne Vajhøj  <arne@vajhoej.dk> wrote:
>>> On 4/5/2022 8:21 PM, Dan Cross wrote:
>>>> In article <t2ilf1$18mj$1@gioia.aioe.org>,
>>>> chris  <chris-nospam@tridac.net> wrote:
>>>>> I think the point is that languages take time to evolve and the path
>>>>> can be unstable until there is enough critical mass to produce a fully
>>>>> documented and standard version. I would expect that to take a decade
>>>>> or more. No good for serious work without that professionalism. Toy
>>>>> and experimental otherwise.
>>>>
>>>> Java doesn't have a "standard" in the sense described here, but
>>>> much as I don't care for it as a language I'd be hard pressed to
>>>> describe it as a "toy" or "no good for serious work."
>>>
>>> Java is not ISO/ANSI/ECMA standardized.
>>>
>>> But the JCP process is really very similar to ISO/ANSI/ECMA.
>>
>> Sounds kind of like the Rust RFC process, but some posters here
>> seem to have suggested that without a document produced under
>> the auspicies of a relevant standards body, a language is not
>> viable for serious work.
>
> I think several languages has been inspired by the JCP process.
>
> For those not familiar with the process here is the short version:
> - an expert group is formed
> - the expert group produces a draft
> - draft goes into public review and may be updated
>   based on feedback
> - draft get approved or rejected by vote in the Executive Committee

If it gets rejected the expert group gets the opportunity to rework
and submit to EC again.

Yes - that has happened!

Arne

In article <624cd4e1$0$701$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>[snip]
>For low level I can only think of two: Rust and Go. And they seem to
>have found different markets - the OS people like Rust and the
>container people like Go.

Disclaimer: I'm good friends with a number of the Go core team
folks. Go and Rust are very complementary, with Go being great
for engineering large project with many programmers working in
parallel in a shared code base, and Rust being great for
low-level bit-twiddly kinds of applications.

Go isn't so awesome at the kinds of low-level bare-metal
applications that Rust excels at, however, as it has a very
substantial runtime and expects a lot of OS support (projects
like Tamago and Biscuit/GERT not withstanding).

Getting Rust going on bare metal, in comparison, is almost
trivial: set up a stack and jump to main().

>[snip]
>Rust checks memory access *unless* in an unsafe block (idea borrowed
>from C# language). As a low level language Rust has the need to be able
>to do some flexible memory access - I can not imagine it is
>possible to write a device driver if only able to access memory
>in variables in the program.

It's possible if you are willing to play games with the linker,
and very early bootstrap, but it's sufficiently tedious that it
is just much easier to transmute an integer to a pointer via
unsafe. Noteably, you really only have to do that once, and you
can largely confine _most_ drivers to mostly safe code.

I don't think that Rust's unsafe was inspired by C#, but I
confess I haven't asked.

>Rust has a unique approach to memory handling based on
>ownership (idea borrowed from modern C++ best practice
>not C++ language) that avoids memory leaks without GC - as
>a low level language that may be used in real time
>context, then the standard solution to avoid memory
>leaks in high level languages GC could be problematic.

Yup. You get something _very_ close to managed memory without
the overhead of GC. Note that sometimes GC can be surprisingly
helpful in high-overhead situations (think tight loops where,
thanks to GC, you don't have to check ref counts or pointer
validity...), but generally you get much of that in Rust without
the additional overhead.

- Dan C.

On 4/5/2022 8:41 PM, Dan Cross wrote:
> In article <624cd4e1$0$701$14726298@news.sunsite.dk>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> Rust checks memory access *unless* in an unsafe block (idea borrowed
>>from C# language). As a low level language Rust has the need to be able
>> to do some flexible memory access - I can not imagine it is
>> possible to write a device driver if only able to access memory
>> in variables in the program.
>
> It's possible if you are willing to play games with the linker,
> and very early bootstrap, but it's sufficiently tedious that it
> is just much easier to transmute an integer to a pointer via
> unsafe. Noteably, you really only have to do that once, and you
> can largely confine _most_ drivers to mostly safe code.
>
> I don't think that Rust's unsafe was inspired by C#, but I
> confess I haven't asked.

I don't know for sure.

But it seems a bit unlikely that they by coincidence chose
the exact same construct.

unsafe {
...
}

>> Rust has a unique approach to memory handling based on
>> ownership (idea borrowed from modern C++ best practice
>> not C++ language) that avoids memory leaks without GC - as
>> a low level language that may be used in real time
>> context, then the standard solution to avoid memory
>> leaks in high level languages GC could be problematic.
>
> Yup. You get something _very_ close to managed memory without
> the overhead of GC. Note that sometimes GC can be surprisingly
> helpful in high-overhead situations (think tight loops where,
> thanks to GC, you don't have to check ref counts or pointer
> validity...), but generally you get much of that in Rust without
> the additional overhead.

Despite what many think then the problem with GC is not
overhead. Often GC is as efficient or even more efficient
than manual deallocation.

The problem with GC is the poor real time characteristics.
It tend to give small pauses at non-deterministic point.

Arne

In article <624ce3dd$0$694$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 4/5/2022 8:41 PM, Dan Cross wrote:
>> In article <624cd4e1$0$701$14726298@news.sunsite.dk>,
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> Rust checks memory access *unless* in an unsafe block (idea borrowed
>>>from C# language). As a low level language Rust has the need to be able
>>> to do some flexible memory access - I can not imagine it is
>>> possible to write a device driver if only able to access memory
>>> in variables in the program.
>>
>> It's possible if you are willing to play games with the linker,
>> and very early bootstrap, but it's sufficiently tedious that it
>> is just much easier to transmute an integer to a pointer via
>> unsafe. Noteably, you really only have to do that once, and you
>> can largely confine _most_ drivers to mostly safe code.
>>
>> I don't think that Rust's unsafe was inspired by C#, but I
>> confess I haven't asked.
>
>I don't know for sure.
>
>But it seems a bit unlikely that they by coincidence chose
>the exact same construct.
>
>unsafe {
> ...
>}

Quite possibly. I put out a question; I'll see if I hear
anything back. It appears that the `unsafe` keyword in
more or less present form was added in 2011 by Niko.

>>> Rust has a unique approach to memory handling based on
>>> ownership (idea borrowed from modern C++ best practice
>>> not C++ language) that avoids memory leaks without GC - as
>>> a low level language that may be used in real time
>>> context, then the standard solution to avoid memory
>>> leaks in high level languages GC could be problematic.
>>
>> Yup. You get something _very_ close to managed memory without
>> the overhead of GC. Note that sometimes GC can be surprisingly
>> helpful in high-overhead situations (think tight loops where,
>> thanks to GC, you don't have to check ref counts or pointer
>> validity...), but generally you get much of that in Rust without
>> the additional overhead.
>
>Despite what many think then the problem with GC is not
>overhead. Often GC is as efficient or even more efficient
>than manual deallocation.

Eh? It's commonly accepted that you're going to give up some
percentage of your capacity for GC overhead. The Go runtime
reserves 25% of CPU time for GC, for instance.

>The problem with GC is the poor real time characteristics.
>It tend to give small pauses at non-deterministic point.

That's the old style GC. Go's concurrent GC mostly avoids that
unless under severe memory pressure.

- Dan C.

Den 2022-04-06 kl. 01:22, skrev Chris Townley:
> On 06/04/2022 00:14, Arne Vajhøj wrote:
>> On 4/5/2022 1:25 PM, Simon Clubley wrote:
>>> On 2022-04-04, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 4/4/2022 1:56 PM, Simon Clubley wrote:
>>>>>
>>>>> Why wasn't Python 3 just another language mode in the existing compiler
>>>>> instead of being a whole different compiler ?
>>>>
>>>> (ignoring that I would not call Python a compiler)
>>>>
>>>
>>> In that case, would you have said (for example) UCSD Pascal wasn't
>>> a compiler ?
>>
>> I have never used USCD Pascal, but I assume that it has a compilation
>> step, so NO.
>>
>>> Python can output .pyc files but also has a way of running code
>>> interactively if desired.
>>
>> Modules get saved as .pyc files when first used.
>>
>> I would call that "caching of intermediate code for
>> interpretation" and not "compilation" but the difference
>> between "caching of intermediate code for interpretation"
>> and "JIT compilation" is pretty thin.
>>
>> But for no other reasons than common custom, then
>> I do not consider Python (CPython that is)
>> compiled.
>>
>> Arne
>>
>
> UCSD 'compilers' famously compiled to a pseudo code that was then
> interpreted. Didn't go down well then...
>
>

UCSD p-Machine:

https://en.wikipedia.org/wiki/P-code_machine#UCSD_p-Machine

A bit like Java byte-code or Python pyc files.

On 06/04/2022 01:41, Dan Cross wrote:

>
> Disclaimer: I'm good friends with a number of the Go core team
> folks. Go and Rust are very complementary, with Go being great
> for engineering large project with many programmers working in
> parallel in a shared code base, and Rust being great for
> low-level bit-twiddly kinds of applications.
>
> Go isn't so awesome at the kinds of low-level bare-metal
> applications that Rust excels at, however, as it has a very
> substantial runtime and expects a lot of OS support (projects
> like Tamago and Biscuit/GERT not withstanding).

[snip]

Simon says he dislikes the syntax of Rust - I took a quick look at Go,
and found that I didn't like it's syntax. Horrible, IMHO

--
Chris

In article <t2jh5l$75s$1@dont-email.me>,
Chris Townley <news@cct-net.co.uk> wrote:
>On 06/04/2022 01:41, Dan Cross wrote:
>> Disclaimer: I'm good friends with a number of the Go core team
>> folks. Go and Rust are very complementary, with Go being great
>> for engineering large project with many programmers working in
>> parallel in a shared code base, and Rust being great for
>> low-level bit-twiddly kinds of applications.
>>
>> Go isn't so awesome at the kinds of low-level bare-metal
>> applications that Rust excels at, however, as it has a very
>> substantial runtime and expects a lot of OS support (projects
>> like Tamago and Biscuit/GERT not withstanding).
>
>[snip]
>
>Simon says he dislikes the syntax of Rust - I took a quick look at Go,
>and found that I didn't like it's syntax. Horrible, IMHO

I sort of recall the language wars of the late 80s and early 90s
wherein people argued vehemently over whether `begin`/`end` or
curly braces where innately superior to one another, or whether
a block should open with a token on the same line as, say, a
conditional or start on the next line.

Looking at the matter now, I find that I just can't bring myself
to care all that much, particularly as we now have automated
tools that do reasonble (if imperfect) jobs of formatting code
to some standard in a uniform fashion. Arguments that used to
take up inordinate amounts of mental and emotional energy are
now settled by the machine. This is a good thing.

After working for a number of years in an O(10^9)-LOC codebase,
I found that the enforced uniformity was essential to cutting
down on cognitive load and understanding what was going on, even
if the mandated style wasn't one I preferred or found pleasing
aesthetically; any place where one can cut down in inessential
complexity is a good thing in large software systems. After a
few weeks it becomes invisible.

There are some languages with irredemably bad syntax, but once
you get beyond those, it just doesn't matter.

- Dan C.

On 2022-04-05, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> I think there is a big difference between what older languages (Ada,
> Pascal etc.) did and what Rust/C# does with unsafe blocks.
>
> The older languages typical enable/disable per compilation
> unit and common practice is to enable/disable for the entire
> project.
>
> (admitted Ada can simulate a block with pragma's)
>

That is most certainly _NOT_ what Ada does. Not at all.

In Ada, you don't need unsafe blocks as the unsafe attributes are
on specific uses of a variable, and not even on the variable as a
whole. That means you can do one very localised unsafe thing while
the code immediately surrounding that unsafe thing is still subject
to full checking.

A couple of examples:

https://www.adaic.org/resources/add_content/docs/95style/html/sec_5/5-9-3.html

for Unchecked_Access and:

https://www.adaic.org/resources/add_content/docs/95style/html/sec_5/5-9-1.html

for Unchecked_Conversion. With Unchecked_Conversion, you even get the
Valid attribute so you can check in a controlled way that what you have
done is acceptable so you don't even have to blindly hope that an unchecked
conversion is ok.

I like Ada.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-04-05, Chris Townley <news@cct-net.co.uk> wrote:
> On 06/04/2022 00:14, Arne Vajhøj wrote:
>> On 4/5/2022 1:25 PM, Simon Clubley wrote:
>>> On 2022-04-04, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 4/4/2022 1:56 PM, Simon Clubley wrote:
>>>>>
>>>>> Why wasn't Python 3 just another language mode in the existing compiler
>>>>> instead of being a whole different compiler ?
>>>>
>>>> (ignoring that I would not call Python a compiler)
>>>>
>>>
>>> In that case, would you have said (for example) UCSD Pascal wasn't
>>> a compiler ?
>>
>> I have never used USCD Pascal, but I assume that it has a compilation
>> step, so NO.
>>
>>> Python can output .pyc files but also has a way of running code
>>> interactively if desired.
>>
>> Modules get saved as .pyc files when first used.
>>
>> I would call that "caching of intermediate code for
>> interpretation" and not "compilation" but the difference
>> between "caching of intermediate code for interpretation"
>> and "JIT compilation" is pretty thin.
>>
>> But for no other reasons than common custom, then
>> I do not consider Python (CPython that is)
>> compiled.
>>
>> Arne
>>
>
> UCSD 'compilers' famously compiled to a pseudo code that was then
> interpreted. Didn't go down well then...
>

Exactly why I picked that example. Its pretty much the same thing
as what Python does.

Another example, closer to home: Is TPU a compiled language ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 4/6/2022 1:56 AM, Jan-Erik Söderholm wrote:
> Den 2022-04-06 kl. 01:22, skrev Chris Townley:
>> On 06/04/2022 00:14, Arne Vajhøj wrote:
>>> On 4/5/2022 1:25 PM, Simon Clubley wrote:
>>>> On 2022-04-04, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>> (ignoring that I would not call Python a compiler)
>>>>
>>>> In that case, would you have said (for example) UCSD Pascal wasn't
>>>> a compiler ?
>>>
>>> I have never used USCD Pascal, but I assume that it has a compilation
>>> step, so NO.
>>>
>>>> Python can output .pyc files but also has a way of running code
>>>> interactively if desired.
>>>
>>> Modules get saved as .pyc files when first used.
>>>
>>> I would call that "caching of intermediate code for
>>> interpretation" and not "compilation" but the difference
>>> between "caching of intermediate code for interpretation"
>>> and "JIT compilation" is pretty thin.
>>>
>>> But for no other reasons than common custom, then
>>> I do not consider Python (CPython that is)
>>> compiled.
>>
>> UCSD 'compilers' famously compiled to a pseudo code that was then
>> interpreted. Didn't go down well then...
>
> UCSD p-Machine:
>
> https://en.wikipedia.org/wiki/P-code_machine#UCSD_p-Machine
>
> A bit like Java byte-code or Python pyc files.

But Java class files and Python pyc files are a bit different.

Java source code get compiled into class files, optionally
the class files get packaged in a jar file, class files or
jar file get distributed, class files or jar file with
embedded class files get executed.

Python source code get distributed and when interpreted
Python (the most common Python implementation: CPython)
saves modules as pyc files but not the script itself.

But it is really a cache of intermediate code. And it is not
just my interpretation. Newer Python versions like to put
then in a __pycache__directory.

Nobody consider Java class files a cache.

Python storing pyc files has more in common with Java JIT
compilation. Java JIT compilation happens when the
program is actually run just like Python generates pyc files
when run. Most common JVM's does not persist the result
of the JIT compilation, but IBM J9 JVM is actually doing so.

Arne

On 4/6/2022 8:30 AM, Simon Clubley wrote:
> On 2022-04-05, Chris Townley <news@cct-net.co.uk> wrote:
>> On 06/04/2022 00:14, Arne Vajhøj wrote:
>>> On 4/5/2022 1:25 PM, Simon Clubley wrote:
>>>> On 2022-04-04, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>> On 4/4/2022 1:56 PM, Simon Clubley wrote:
>>>>>>
>>>>>> Why wasn't Python 3 just another language mode in the existing compiler
>>>>>> instead of being a whole different compiler ?
>>>>>
>>>>> (ignoring that I would not call Python a compiler)
>>>>>
>>>>
>>>> In that case, would you have said (for example) UCSD Pascal wasn't
>>>> a compiler ?
>>>
>>> I have never used USCD Pascal, but I assume that it has a compilation
>>> step, so NO.
>>>
>>>> Python can output .pyc files but also has a way of running code
>>>> interactively if desired.
>>>
>>> Modules get saved as .pyc files when first used.
>>>
>>> I would call that "caching of intermediate code for
>>> interpretation" and not "compilation" but the difference
>>> between "caching of intermediate code for interpretation"
>>> and "JIT compilation" is pretty thin.
>>>
>>> But for no other reasons than common custom, then
>>> I do not consider Python (CPython that is)
>>> compiled.
>>
>> UCSD 'compilers' famously compiled to a pseudo code that was then
>> interpreted. Didn't go down well then...
>>
>
> Exactly why I picked that example. Its pretty much the same thing
> as what Python does.

If the compilation is part of the build process then it is not the
same.

> Another example, closer to home: Is TPU a compiled language ?

Yes.

You take your TPU source, you build it to a section file
and you distribute that section file.

Arne

On 4/5/2022 9:30 PM, Dan Cross wrote:
> In article <624ce3dd$0$694$14726298@news.sunsite.dk>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 4/5/2022 8:41 PM, Dan Cross wrote:
>>> In article <624cd4e1$0$701$14726298@news.sunsite.dk>,
>>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> Rust has a unique approach to memory handling based on
>>>> ownership (idea borrowed from modern C++ best practice
>>>> not C++ language) that avoids memory leaks without GC - as
>>>> a low level language that may be used in real time
>>>> context, then the standard solution to avoid memory
>>>> leaks in high level languages GC could be problematic.
>>>
>>> Yup. You get something _very_ close to managed memory without
>>> the overhead of GC. Note that sometimes GC can be surprisingly
>>> helpful in high-overhead situations (think tight loops where,
>>> thanks to GC, you don't have to check ref counts or pointer
>>> validity...), but generally you get much of that in Rust without
>>> the additional overhead.
>>
>> Despite what many think then the problem with GC is not
>> overhead. Often GC is as efficient or even more efficient
>> than manual deallocation.
>
> Eh? It's commonly accepted that you're going to give up some
> percentage of your capacity for GC overhead.

No it is not.

With generational garbage collectors it is very fast to GC
short lived objects.

> The Go runtime
> reserves 25% of CPU time for GC, for instance.

I don't know Go that well.

But that is absolutely horrible.

It should be less than 5%.

Go does not use generational garbage collection - it tries
on escape analysis to put stuff on stack instead of heap. But
if the 25% is correct then they made the wrong decision.

>> The problem with GC is the poor real time characteristics.
>> It tend to give small pauses at non-deterministic point.
>
> That's the old style GC. Go's concurrent GC mostly avoids that
> unless under severe memory pressure.

No.

Go GC use STW. They have managed to reduce the time but it is
still a STW.

The only GC I am aware of that does not do STW is Azul Zing.

Arne

On 4/5/2022 2:05 PM, Simon Clubley wrote:
> It looks like Rust has come up with rather unique ways to screw up:

I think you have a mysterious understanding of what is unique in
programming.

(and this is not Rust as such but libraries written in Rust)

> https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust
>
> Take this one (which I picked at random) for example:
>
> https://rustsec.org/advisories/RUSTSEC-2020-0148.html

This is actually 3 problems.

Two problem with code that is not thread safe.

One problem with is a gross violation of Rust rules.

Neither is particular unique.

I am willing to claim that you can find examples of concurrency
problems in most languages.

And the last problem may not happen in high level languages, but
you can certainly do it in C - you can cast a const something *
to a something *. And likely pay the price at some point in time.

But note that all 3 are marked unsafe. So they are code that
should be reviewed extra careful.

> Or this one (which is a nice good old fashioned out of bounds memory access):
>
> https://rustsec.org/advisories/RUSTSEC-2020-0039.html

Very common error.

Definitely not unique.

And again the code is marked unsafe aka checks explicit disabled.

Default checked with ability to disable check is probably the best
that is possible for a low level language.

Arne

In article <624d95fe$0$706$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 4/5/2022 2:05 PM, Simon Clubley wrote:
>> It looks like Rust has come up with rather unique ways to screw up:
>
>I think you have a mysterious understanding of what is unique in
>programming.
>
>(and this is not Rust as such but libraries written in Rust)

Indeed. I read that quip as a statement along the lines of,
"tell me you don't know Rust without telling me that you don't
know Rust."

- Dan C.

In article <624d911f$0$702$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 4/5/2022 9:30 PM, Dan Cross wrote:
>> Eh? It's commonly accepted that you're going to give up some
>> percentage of your capacity for GC overhead.
>
>No it is not.

Sorry, but yes it is.

>With generational garbage collectors it is very fast to GC
>short lived objects.

That does not mean that you aren't going to give up some
percentage of your capacity for GC. GC is not infinitely fast.

>> The Go runtime
>> reserves 25% of CPU time for GC, for instance.
>
>I don't know Go that well.
>
>But that is absolutely horrible.
>
>It should be less than 5%.

Note that I said that, "the Go runtime _reserves_ 25% of CPU
time for GC." That is not the same as the Go runtime _using_
25% of CPU capacity for GC. In practice, overhead is closer
to 5% (which is still not 0%).

>Go does not use generational garbage collection - it tries
>on escape analysis to put stuff on stack instead of heap. But
>if the 25% is correct then they made the wrong decision.

Go's garbage collector is concurrent. Here's a video that Rick
Hudson presented about the Go GC:

https://www.youtube.com/watch?v=aiv1JOfMjm0

>>> The problem with GC is the poor real time characteristics.
>>> It tend to give small pauses at non-deterministic point.
>>
>> That's the old style GC. Go's concurrent GC mostly avoids that
>> unless under severe memory pressure.
>
>No.

Actually, yes.

>Go GC use STW. They have managed to reduce the time but it is
>still a STW.

Note that I said that, "Go's concurrent GC _mostly_ avoids
that unless under severe memory pressure."

>The only GC I am aware of that does not do STW is Azul Zing.

The LVB in Azul is basically a localized pause. It may be true
that Azul doesn't STW, but that doesn't mean that it's free.

"We also differentiate between the notion of a global safepoint,
where are all the mutator threads are stopped, and a checkpoint,
where individual threads pass through a barrier function"

(https://dl.acm.org/doi/pdf/10.1145/2076022.1993491 sec 4)

Under severe memory pressure pretty much all of the threads will
block in the LVB and the situation will be more or less
indistiguishable from a STW pause.

- Dan C.

On 4/6/2022 9:56 AM, Dan Cross wrote:
> In article <624d911f$0$702$14726298@news.sunsite.dk>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 4/5/2022 9:30 PM, Dan Cross wrote:
>>> Eh? It's commonly accepted that you're going to give up some
>>> percentage of your capacity for GC overhead.
>>
>> No it is not.
>
> Sorry, but yes it is.
>
>> With generational garbage collectors it is very fast to GC
>> short lived objects.
>
> That does not mean that you aren't going to give up some
> percentage of your capacity for GC. GC is not infinitely fast.

No.

But it does not need to use zero CPU.

It just need to be faster than the manual free calls.

Which it is.

>>>> The problem with GC is the poor real time characteristics.
>>>> It tend to give small pauses at non-deterministic point.
>>>
>>> That's the old style GC. Go's concurrent GC mostly avoids that
>>> unless under severe memory pressure.
>>
>> No.
>
> Actually, yes.
>
>> Go GC use STW. They have managed to reduce the time but it is
>> still a STW.
>
> Note that I said that, "Go's concurrent GC _mostly_ avoids
> that unless under severe memory pressure."

A GC STW is a GC STW.

>> The only GC I am aware of that does not do STW is Azul Zing.
>
> The LVB in Azul is basically a localized pause. It may be true
> that Azul doesn't STW, but that doesn't mean that it's free.

Of course it is not free.

It may likely use more CPU than a STW GC.

But it avoid STW.

(and it is Azul Zing - Azul Zulu is using traditional STW GC)

> Under severe memory pressure pretty much all of the threads will
> block in the LVB and the situation will be more or less
> indistiguishable from a STW pause.

That is not what tests show.

Tests show that Azul Zing avoid the GC pauses.

Hazelcast did a test with traditional JVM and Azul JVM.

Results showed that 99% percentile was 2 ms for both,
but 99.99% percentile was 40 ms for traditional and 8 ms
for Azul Zing.

It works.

Arne

On 4/5/22 20:20, Arne Vajhøj wrote:
> On 4/5/2022 8:08 PM, Bill Gunshannon wrote:
>> On 4/5/22 19:46, Arne Vajhøj wrote:
>>> C and C++ are currently dominating the low level code area, but
>>> there are some well known problem.
>>>
>>> Two of those problems are:
>>> * buffer overruns
>>> * memory leaks
>>
>> Both those problems were fixed 40 years ago.  The fixes were
>> ignored and the company offering Safe C went out of business.
>
> They were not fixed as the current C compilers allow
> the problems.
>
> Maybe they could have been fixed, but that does not really
> help those with C code today.
>

Let me re-word that. 40 years ago the problems were well known
and documented. A company created a C compiler and support package
to fix it. The industry rejected it because the cost (and I don't
mean the purchase price!) was too high.

It is interesting that very little of this made it into the C
Standard which is when they could have fixed all of it. And
they can't use the backwards compatibility argument because
there was no compatibility maintained between K&R and ANSI C.

bill

On 4/6/2022 12:08 PM, Bill Gunshannon wrote:
> On 4/5/22 20:20, Arne Vajhøj wrote:
>> On 4/5/2022 8:08 PM, Bill Gunshannon wrote:
>>> On 4/5/22 19:46, Arne Vajhøj wrote:
>>>> C and C++ are currently dominating the low level code area, but
>>>> there are some well known problem.
>>>>
>>>> Two of those problems are:
>>>> * buffer overruns
>>>> * memory leaks
>>>
>>> Both those problems were fixed 40 years ago.  The fixes were
>>> ignored and the company offering Safe C went out of business.
>>
>> They were not fixed as the current C compilers allow
>> the problems.
>>
>> Maybe they could have been fixed, but that does not really
>> help those with C code today.
>
> Let me re-word that.  40 years ago the problems were well known
> and documented.  A company created a C compiler and support package
> to fix it.  The industry rejected it because the cost (and I don't
> mean the purchase price!) was too high.
>
> It is interesting that very little of this made it into the C
> Standard which is when they could have fixed all of it.  And
> they can't use the backwards compatibility argument because
> there was no compatibility maintained between K&R and ANSI C.

How much is known about why that product failed?

I could have been the overhead. But I doubt it. Many languages
from that era did either check or had the option of enabling checks.

And today it would almost certainly not have been an issue. Most
languages check.

Arne

On Wednesday, April 6, 2022 at 9:36:05 AM UTC-7, Arne Vajhøj wrote:
> On 4/6/2022 12:08 PM, Bill Gunshannon wrote:
> > On 4/5/22 20:20, Arne Vajhøj wrote:
> >> On 4/5/2022 8:08 PM, Bill Gunshannon wrote:
> >>> On 4/5/22 19:46, Arne Vajhøj wrote:
> >>>> C and C++ are currently dominating the low level code area, but
> >>>> there are some well known problem.
> >>>>
> >>>> Two of those problems are:
> >>>> * buffer overruns
> >>>> * memory leaks
> >>>
> >>> Both those problems were fixed 40 years ago. The fixes were
> >>> ignored and the company offering Safe C went out of business.
> >>
> >> They were not fixed as the current C compilers allow
> >> the problems.
> >>
> >> Maybe they could have been fixed, but that does not really
> >> help those with C code today.
> >
> > Let me re-word that. 40 years ago the problems were well known
> > and documented. A company created a C compiler and support package
> > to fix it. The industry rejected it because the cost (and I don't
> > mean the purchase price!) was too high.
> >
> > It is interesting that very little of this made it into the C
> > Standard which is when they could have fixed all of it. And
> > they can't use the backwards compatibility argument because
> > there was no compatibility maintained between K&R and ANSI C.
> How much is known about why that product failed?
>
> I could have been the overhead. But I doubt it. Many languages
> from that era did either check or had the option of enabling checks.
>
> And today it would almost certainly not have been an issue. Most
> languages check.
>
> Arne

Bill, are you referring to
https://pages.cs.wisc.edu/~austin/scc.html

If so, that's certainly a valuable contribution to the C compiler ecosystem.. It's necessary, but not sufficient to address the kinds of UB we've been talking about. And, frankly, there are kinds of invalid pointer access that simply can't be caught without the other static guarantees that Rust makes, and /all/ current C compilers do not. For example, C simply isn't capable of inhibiting type punning. It's a core feature of the language, and at the same time a footgun.

Speaking of compilers vs. interpreters, I'd like to add "transpilers" like Google Web Toolkit to the mix. Write in modern Java and transpile to optimized JavaScript. Lots of fun! And, of course one has to admit the intense brain-fukery of Threaded Interpretive Languages. Is they compiled? Do they interpret? Only the debbil knows, and she ain't tellin'

On 2022-04-06, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 4/6/2022 8:30 AM, Simon Clubley wrote:
>
>> Another example, closer to home: Is TPU a compiled language ?
>
> Yes.
>
> You take your TPU source, you build it to a section file
> and you distribute that section file.
>

That's one way. Another way is to specify the TPU source you want to
run at startup using $ edit/tpu/command=filename.tpu just as you can
do in Python with Python source code.

You can also interactively enter TPU source code into the current
buffer and then use EXTEND EVE to compile it.

So you can use TPU in both modes, just as you can with Python...

The reason I do call Python a compiler is because when you are installing
a Python library from source, the source code gets compiled and the
compiled files are then placed inside a library directory just as would
happen when compiling a C program from source.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 4/6/2022 1:08 PM, plugh wrote:
> Speaking of compilers vs. interpreters, I'd like to add "transpilers"
> like Google Web Toolkit to the mix. Write in modern Java and
> transpile to optimized JavaScript.

I think GWT is dying.

But the model still exist. Both Kotlin and JavaScript has a version
targeting JavaScript.

Arne