On 04/03/2024 22:11, Lawrence D'Oliveiro wrote:
> On Mon, 4 Mar 2024 15:41:43 +0100, David Brown wrote:
>
>> ... Lady Ada Lovelace is often regarded (perhaps
>> incorrectly) as the first computer programmer.
>
> She was the first, in written records, to appreciate some of the not-so-
> obvious issues in computer programming.

Yes. That includes realising that computers could do more than number
crunching. She was also involved in checking, correcting and commenting
some of Babbage's programs, and also was the first to publish an
algorithm (for Bernouli numbers) designed specifically for executing on
a computer. And she did all this without a working computer.

So while calling her "the first computer programmer" is inaccurate, she
was definitely a key computer science pioneer.

On 3/3/2024 7:13 am, Lynn McGuire wrote:
>
> "The Biden administration backs a switch to more memory-safe programming
> languages. The tech industry sees their point, but it won't be easy."
>
> No. The feddies want to regulate software development very much. They
> have been talking about it for at least 20 years now. This is a very
> bad thing.

A responsible, good progreammer or a better C/C++ pre-processor can
avoid a lot of problems!!

Lynn McGuire <lynnmcguire5@gmail.com> writes:
>On 3/3/2024 9:31 AM, Scott Lurndal wrote:
>> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>>> "White House to Developers: Using C or C++ Invites Cybersecurity Risks"
>>>
>>> https://www.pcmag.com/news/white-house-to-developers-using-c-plus-plus-invites-cybersecurity-risks
>>>
>>> "The Biden administration backs a switch to more memory-safe programming
>>> languages. The tech industry sees their point, but it won't be easy."
>>>
>>> No. The feddies want to regulate software development very much.
>>
>> You've been reading far to much apocalyptic fiction and seeing the
>> world through trump-colored glasses. Neither reflect reality.
>
>Nope, I actually have had a Professional Engineer's License in Texas for
>34 years now and can tell you all about what it takes to get one and
>what it takes to keep one.
>
>This bunch of crazies in the White House wants to do the same thing to
>software development.
>

Nothing in the quoted article supports your ridiculous assertion.

On 3/5/2024 1:01 AM, David Brown wrote:
> On 04/03/2024 21:36, Chris M. Thomasson wrote:
>> On 3/4/2024 12:44 AM, David Brown wrote:
>>> On 03/03/2024 23:01, Chris M. Thomasson wrote:
>>>> On 3/3/2024 12:23 PM, David Brown wrote:
>>>>> On 03/03/2024 19:18, Kaz Kylheku wrote:
>>>
>>>>>> Embedded systems often need custom memory management, not
>>>>>> something that
>>>>>> the language imposes. C has malloc, yet even that gets disused in
>>>>>> favor
>>>>>> of something else.
>>>>>>
>>>>>
>>>>> For safe embedded systems, you don't want memory management at all.
>>>>> Avoiding dynamic memory is an important aspect of safety-critical
>>>>> embedded development.
>>>>>
>>>>
>>>> You still have to think about memory management even if you avoid
>>>> any dynamic memory? How are you going to mange this memory wrt your
>>>> various data structures needs....
>>>
>>> To be clear here - sometimes you can't avoid all use of dynamic
>>> memory and therefore memory management.  And as Kaz says, you will
>>> often use custom solutions such as resource pools rather than generic
>>> malloc/free.   Flexible network communication (such as Ethernet or
>>> other IP networking) is hard to do without dynamic memory.
>> [...]
>>
>> Think of using a big chunk of memory, never needed to be freed and is
>> just there per process. Now, you carve it up and store it in a cache
>> that has functions push and pop. So, you still have to manage memory
>> even when you are using no dynamic memory at all... Fair enough, in a
>> sense? The push and the pop are your malloc and free in a strange
>> sense...
>>
>
> I believe I mentioned that.  You do not, in general, "push and pop" -
> you malloc and never free.  Excluding debugging code and other parts
> useful in testing and developing, you have something like :
>
> enum { heap_size = 16384; }
> alignas(max_align_t) static uint8_t heap[heap_size];
> uint8_t * next_free = heap;
>
> void free(void * ptr) {
>     (void) ptr;
> }
>
> void * malloc(size_t size) {
>     const size_t align = alignof(max_align_t);
>     const real_size = size ? (size + (align - 1)) & ~(align - 1)
>                 : align;
>     void * p = next_free;
>     next_free += real_size;
>     return p;
> }
>
>
> Allowing for pops requires storing the size of the allocations (unless
> you change the API from that of malloc/free), and is only rarely useful.
>  Generally if you want memory that temporary, you use a VLA or alloca
> to put it on the stack.
>

wrt systems with no malloc/free I am thinking more along the lines of a
region allocator mixed with a LIFO for a cache, so a node based thing.
The region allocator gets fed with a large buffer. Depending on specific
needs, it can work out nicely for systems that do not have malloc/free.
The pattern I used iirc, was something like:

// pseudo code...
_______________________
node*
node_pop()
{ // try the lifo first...

node* n = lifo_pop();

if (! n)
{
// resort to the region allocator...

n = region_allocate_node();

// note, n can be null here.
// if it is, we are out of memory.

// note, out of memory on a system
// with no malloc/free...
}

return n;
}

void
node_push(
node* n
) {
lifo_push(n);
} _______________________

make any sense to you?

On 3/5/2024 2:27 AM, David Brown wrote:
> On 05/03/2024 08:08, Lawrence D'Oliveiro wrote:
>> On Tue, 5 Mar 2024 00:03:54 -0600, Lynn McGuire wrote:
>>
>>> On 3/3/2024 11:43 PM, Lawrence D'Oliveiro wrote:
>>>
>>>> Did you know the life-support system on the
>>>> International Space Station was written in Ada? Not something you would
>>>> trust C++ code to, let’s face it.
>>>
>>> Most of the Ada code was written in C or C++ and converted to Ada for
>>> delivery.
>>
>> Was it debugged again? Or was it assumed that the translation was bug-
>> free?
>
> With Ada, if you can get it to compile, it's ready to ship :-)
>
>

Really? Any logic errors in the program itself?

On 2024-03-05, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> On 3/5/2024 2:27 AM, David Brown wrote:
>> On 05/03/2024 08:08, Lawrence D'Oliveiro wrote:
>>> On Tue, 5 Mar 2024 00:03:54 -0600, Lynn McGuire wrote:
>>>
>>>> On 3/3/2024 11:43 PM, Lawrence D'Oliveiro wrote:
>>>>
>>>>> Did you know the life-support system on the
>>>>> International Space Station was written in Ada? Not something you would
>>>>> trust C++ code to, let’s face it.
>>>>
>>>> Most of the Ada code was written in C or C++ and converted to Ada for
>>>> delivery.
>>>
>>> Was it debugged again? Or was it assumed that the translation was bug-
>>> free?
>>
>> With Ada, if you can get it to compile, it's ready to ship :-)
>>
> Really? Any logic errors in the program itself?

Ariane 5 rocket incident of 1996: The Ada code didn't catch the hardware
overflow exception from forcing a 64 bit floating-point value into a 16
bit integer. The situation was not expected by the code which was
developed for the Ariane 4, or something like that.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 3/5/2024 1:24 PM, Kaz Kylheku wrote:
> On 2024-03-05, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> On 3/5/2024 2:27 AM, David Brown wrote:
>>> On 05/03/2024 08:08, Lawrence D'Oliveiro wrote:
>>>> On Tue, 5 Mar 2024 00:03:54 -0600, Lynn McGuire wrote:
>>>>
>>>>> On 3/3/2024 11:43 PM, Lawrence D'Oliveiro wrote:
>>>>>
>>>>>> Did you know the life-support system on the
>>>>>> International Space Station was written in Ada? Not something you would
>>>>>> trust C++ code to, let’s face it.
>>>>>
>>>>> Most of the Ada code was written in C or C++ and converted to Ada for
>>>>> delivery.
>>>>
>>>> Was it debugged again? Or was it assumed that the translation was bug-
>>>> free?
>>>
>>> With Ada, if you can get it to compile, it's ready to ship :-)
>>>
>> Really? Any logic errors in the program itself?
>
> Ariane 5 rocket incident of 1996: The Ada code didn't catch the hardware
> overflow exception from forcing a 64 bit floating-point value into a 16
> bit integer. The situation was not expected by the code which was
> developed for the Ariane 4, or something like that.
>

I need to study up on that one; Thanks. Fwiw, the joint strike fighter
C++ rules are interesting to me as well. Can a little bugger make one of
its air-to-air missiles fire? Now I can hear one of my friends saying,
see, I told you that human programmers cannot be trusted... ;^) lol.

ADA is bullet proof... Until its not... ;^)

On 3/4/2024 11:07 PM, Lawrence D'Oliveiro wrote:
> On Mon, 4 Mar 2024 21:23:49 -0800, Chris M. Thomasson wrote:
>
>> On 3/4/2024 8:43 PM, Lawrence D'Oliveiro wrote:
>>
>>> On Tue, 5 Mar 2024 02:46:33 +0000, Malcolm McLean wrote:
>>>
>>>> The less code you have, the less that can go wrong.
>>>
>>> This can also mean using the build system to automatically generate
>>> some repetitive things, to avoid having to write them manually.
>>
>> Does the build system depend on anything coded in C?
>
> These days, it might be Rust.

The keyword is might... Right?

Kaz Kylheku <433-929-6894@kylheku.com> writes:
> On 2024-03-05, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> On 3/5/2024 2:27 AM, David Brown wrote:
>>> On 05/03/2024 08:08, Lawrence D'Oliveiro wrote:
>>>> On Tue, 5 Mar 2024 00:03:54 -0600, Lynn McGuire wrote:
>>>>
>>>>> On 3/3/2024 11:43 PM, Lawrence D'Oliveiro wrote:
>>>>>
>>>>>> Did you know the life-support system on the
>>>>>> International Space Station was written in Ada? Not something you would
>>>>>> trust C++ code to, let’s face it.
>>>>>
>>>>> Most of the Ada code was written in C or C++ and converted to Ada for
>>>>> delivery.
>>>>
>>>> Was it debugged again? Or was it assumed that the translation was bug-
>>>> free?
>>>
>>> With Ada, if you can get it to compile, it's ready to ship :-)
>>>
>> Really? Any logic errors in the program itself?
>
> Ariane 5 rocket incident of 1996: The Ada code didn't catch the hardware
> overflow exception from forcing a 64 bit floating-point value into a 16
> bit integer. The situation was not expected by the code which was
> developed for the Ariane 4, or something like that.

A numeric overflow occurred during the Ariane 5's initial flight -- and
the software *did* catch the overflow. The same overflow didn't occur
on Ariane 4 because of its different flight profile. There was a
management decision to reuse the Ariane 4 flight software for Ariane 5
without sufficient review.

The code (which had been thoroughly tested on Ariane 4 and was known not
to overflow) emitted an error message describing the overflow exception.
That error message was then processed as data. Another problem was that
systems were designed to shut down on any error; as a result, healthy
and necessary equipment was shut down prematurely.

This is from my vague memory, and may not be entirely accurate.

*Of course* logic errors are possible in Ada programs, but in my
experience and that of many other programmers, if you get an Ada program
to compile (and run without raising unhandled exceptions), you're likely
to be much closer to a working program than if you get a C program to
compile. A typo in a C program is more likely to result in a valid
program with different semantics.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 3/5/2024 1:58 PM, Keith Thompson wrote:
> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>> On 2024-03-05, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>>> On 3/5/2024 2:27 AM, David Brown wrote:
>>>> On 05/03/2024 08:08, Lawrence D'Oliveiro wrote:
>>>>> On Tue, 5 Mar 2024 00:03:54 -0600, Lynn McGuire wrote:
>>>>>
>>>>>> On 3/3/2024 11:43 PM, Lawrence D'Oliveiro wrote:
>>>>>>
>>>>>>> Did you know the life-support system on the
>>>>>>> International Space Station was written in Ada? Not something you would
>>>>>>> trust C++ code to, let’s face it.
>>>>>>
>>>>>> Most of the Ada code was written in C or C++ and converted to Ada for
>>>>>> delivery.
>>>>>
>>>>> Was it debugged again? Or was it assumed that the translation was bug-
>>>>> free?
>>>>
>>>> With Ada, if you can get it to compile, it's ready to ship :-)
>>>>
>>> Really? Any logic errors in the program itself?
>>
>> Ariane 5 rocket incident of 1996: The Ada code didn't catch the hardware
>> overflow exception from forcing a 64 bit floating-point value into a 16
>> bit integer. The situation was not expected by the code which was
>> developed for the Ariane 4, or something like that.
>
> A numeric overflow occurred during the Ariane 5's initial flight -- and
> the software *did* catch the overflow. The same overflow didn't occur
> on Ariane 4 because of its different flight profile. There was a
> management decision to reuse the Ariane 4 flight software for Ariane 5
> without sufficient review.
>
> The code (which had been thoroughly tested on Ariane 4 and was known not
> to overflow) emitted an error message describing the overflow exception.
> That error message was then processed as data. Another problem was that
> systems were designed to shut down on any error; as a result, healthy
> and necessary equipment was shut down prematurely.
>
> This is from my vague memory, and may not be entirely accurate.
>
> *Of course* logic errors are possible in Ada programs, but in my
> experience and that of many other programmers, if you get an Ada program
> to compile (and run without raising unhandled exceptions), you're likely
> to be much closer to a working program than if you get a C program to
> compile. A typo in a C program is more likely to result in a valid
> program with different semantics.
>

So close you can just feel its a 100% correct and working program?

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
[...]
> ADA is bullet proof... Until its not... ;^)

The language is called Ada, not ADA.

Of course no language that can be used for real work can be completely
bulletproof. Ada is designed to be relatively safe (and neither of
these newsgroups is the place to discuss the details.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 3/5/2024 2:11 PM, Keith Thompson wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> [...]
>> ADA is bullet proof... Until its not... ;^)
>
> The language is called Ada, not ADA.

I wonder how many people got confused?

> Of course no language that can be used for real work can be completely
> bulletproof. Ada is designed to be relatively safe (and neither of
> these newsgroups is the place to discuss the details.)
>

That's fine.

On Tue, 5 Mar 2024 11:11:03 +0200, Michael S wrote:

> On Tue, 5 Mar 2024 01:54:46 -0000 (UTC)
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> Discord did some benchmarking of its back-end servers, which had been
>> using Go, and decided that switching to Rust offered better
>> performance.
>
> - for big and complex real-world back-end processing, writing working
> solution in go will take 5 time less man hours than writing it in Rust

Nevertheless, they found the switch to Rust worthwhile.

On Tue, 5 Mar 2024 11:31:11 +0100, David Brown wrote:

> That includes realising that computers could do more than number
> crunching.

Or, conversely, realizing that all forms of computation (including symbol
manipulation) can be expressed as arithmetic? Maybe that came later, cf
“Gödel numbering”.

On Tue, 5 Mar 2024 13:48:25 -0800, Chris M. Thomasson wrote:

> On 3/4/2024 11:07 PM, Lawrence D'Oliveiro wrote:
>
>> On Mon, 4 Mar 2024 21:23:49 -0800, Chris M. Thomasson wrote:
>>
>>> Does the build system depend on anything coded in C?
>>
>> These days, it might be Rust.
>
> The keyword is might... Right?

Might does not make right.

On 3/5/2024 4:25 PM, Lawrence D'Oliveiro wrote:
> On Tue, 5 Mar 2024 13:48:25 -0800, Chris M. Thomasson wrote:
>
>> On 3/4/2024 11:07 PM, Lawrence D'Oliveiro wrote:
>>
>>> On Mon, 4 Mar 2024 21:23:49 -0800, Chris M. Thomasson wrote:
>>>
>>>> Does the build system depend on anything coded in C?
>>>
>>> These days, it might be Rust.
>>
>> The keyword is might... Right?
>
> Might does not make right.

So, what is the right language to use?

On 5/3/2024 9:51 pm, Mr. Man-wai Chang wrote:
> On 3/3/2024 7:13 am, Lynn McGuire wrote:
>>
>> "The Biden administration backs a switch to more memory-safe programming
>> languages. The tech industry sees their point, but it won't be easy."
>>
>> No. The feddies want to regulate software development very much. They
>> have been talking about it for at least 20 years now. This is a very
>> bad thing.
>
> A responsible, good progreammer or a better C/C++ pre-processor can
> avoid a lot of problems!!

Or maybe A.I.-assisted code analyzer?? But there are still blind spots...

On 05/03/2024 21:51, Chris M. Thomasson wrote:
> On 3/5/2024 1:01 AM, David Brown wrote:
>> On 04/03/2024 21:36, Chris M. Thomasson wrote:
>>> On 3/4/2024 12:44 AM, David Brown wrote:
>>>> On 03/03/2024 23:01, Chris M. Thomasson wrote:
>>>>> On 3/3/2024 12:23 PM, David Brown wrote:
>>>>>> On 03/03/2024 19:18, Kaz Kylheku wrote:
>>>>
>>>>>>> Embedded systems often need custom memory management, not
>>>>>>> something that
>>>>>>> the language imposes. C has malloc, yet even that gets disused in
>>>>>>> favor
>>>>>>> of something else.
>>>>>>>
>>>>>>
>>>>>> For safe embedded systems, you don't want memory management at
>>>>>> all. Avoiding dynamic memory is an important aspect of
>>>>>> safety-critical embedded development.
>>>>>>
>>>>>
>>>>> You still have to think about memory management even if you avoid
>>>>> any dynamic memory? How are you going to mange this memory wrt your
>>>>> various data structures needs....
>>>>
>>>> To be clear here - sometimes you can't avoid all use of dynamic
>>>> memory and therefore memory management.  And as Kaz says, you will
>>>> often use custom solutions such as resource pools rather than
>>>> generic malloc/free.   Flexible network communication (such as
>>>> Ethernet or other IP networking) is hard to do without dynamic memory.
>>> [...]
>>>
>>> Think of using a big chunk of memory, never needed to be freed and is
>>> just there per process. Now, you carve it up and store it in a cache
>>> that has functions push and pop. So, you still have to manage memory
>>> even when you are using no dynamic memory at all... Fair enough, in a
>>> sense? The push and the pop are your malloc and free in a strange
>>> sense...
>>>
>>
>> I believe I mentioned that.  You do not, in general, "push and pop" -
>> you malloc and never free.  Excluding debugging code and other parts
>> useful in testing and developing, you have something like :
>>
>> enum { heap_size = 16384; }
>> alignas(max_align_t) static uint8_t heap[heap_size];
>> uint8_t * next_free = heap;
>>
>> void free(void * ptr) {
>>      (void) ptr;
>> }
>>
>> void * malloc(size_t size) {
>>      const size_t align = alignof(max_align_t);
>>      const real_size = size ? (size + (align - 1)) & ~(align - 1)
>>                  : align;
>>      void * p = next_free;
>>      next_free += real_size;
>>      return p;
>> }
>>
>>
>> Allowing for pops requires storing the size of the allocations (unless
>> you change the API from that of malloc/free), and is only rarely
>> useful.   Generally if you want memory that temporary, you use a VLA
>> or alloca to put it on the stack.
>>
>
> wrt systems with no malloc/free I am thinking more along the lines of a
> region allocator mixed with a LIFO for a cache, so a node based thing.
> The region allocator gets fed with a large buffer. Depending on specific
> needs, it can work out nicely for systems that do not have malloc/free.
> The pattern I used iirc, was something like:
>
> // pseudo code...
> _______________________
> node*
> node_pop()
> {
>     // try the lifo first...
>
>     node* n = lifo_pop();
>
>     if (! n)
>     {
>         // resort to the region allocator...
>
>         n = region_allocate_node();
>
>         // note, n can be null here.
>         // if it is, we are out of memory.
>
>         // note, out of memory on a system
>         // with no malloc/free...
>     }
>
>     return n;
> }
>
> void
> node_push(
>     node* n
> ) {
>      lifo_push(n);
> }
> _______________________
>
>
> make any sense to you?
>

I know what you are trying to suggest, and I understand how it can sound
reasonable. In some cases, this can be a useful kind of allocator, and
when it is suitable, it is very fast. But it is has two big issues for
small embedded systems.

One problem is the "region_allocate_node()" - getting a lump of space
from the underlying OS. That is fine on "big systems", and it is normal
that malloc/free systems only ask for memory from the OS in big lumps,
then handle local allocation within the process space for efficiency.
(This can work particularly well if each thread gets dedicated lumps, so
that no locking is needed for most malloc/free calls.)

But in a small embedded system, there is no OS (an RTOS is generally
part of the same binary as the application), and providing such "lumps"
would be dynamic memory management. So if you are using a system like
you describe, then you would have a single statically allocated block of
memory for your lifo stack.

Then there is the question of how often such a stack-like allocator is
useful, independent of the normal stack. I can imagine it is
/sometimes/ helpful, but rarely. I can't think off-hand of any cases
where I would have found it useful in anything I have written.

As I (and others) have said elsewhere, in small embedded systems and
safety or reliability critical systems, you want to avoid dynamic memory
and memory management whenever possible, for a variety of reasons. If
you do need something, then specialise allocators are more common -
possibly including lifos like this.

But it's more likely to have fixed-size pools with fixed-size elements,
dedicated to particular memory tasks. For example, if you need to track
multiple in-flight messages on a wireless mesh network, where messages
might take different amounts of time to be delivered and acknowledged,
or retried, you define a structure that holds all the data you need for
a message. Then you decide how many in-flight messages you will support
as a maximum. This gives you a statically allocated array of N structs.
Block usage is then done by a bitmap, typically within a single 32-bit
word. Finding a free slot is a just finding the first free zero, and
freeing it is clearing the correct bit.

There are, of course, many other kinds of dedicated allocators that can
be used in other circumstances.

On Tue, 5 Mar 2024 22:58:10 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> On Tue, 5 Mar 2024 11:11:03 +0200, Michael S wrote:
>
> > On Tue, 5 Mar 2024 01:54:46 -0000 (UTC)
> > Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> >
> >> Discord did some benchmarking of its back-end servers, which had
> >> been using Go, and decided that switching to Rust offered better
> >> performance.
> >
> > - for big and complex real-world back-end processing, writing
> > working solution in go will take 5 time less man hours than writing
> > it in Rust
>
> Nevertheless, they found the switch to Rust worthwhile.

I read a little more about it.
https://discord.com/blog/why-discord-is-switching-from-go-to-rust

Summary: performance of one of Discord's most heavy-duty servers
suffered from weakness in implementation of Go garbage collector. On
average the performance was satisfactory, but every two minutes there
was spike in latency. The latency during the spike was not that big
(300 msec), but they stilled were feeling that they want better.
They tried to tune GC, but the problem appeared to be fundamental.
So they just rewrote this particular server in Rust. Naturally, Rust
does not collect garbage, so this particular problem disappeared.

The key phrase of the story is "This service was a great candidate to
port to Rust since it was small and self-contained".
I'd add to this that even more important for eventual success of
migration was the fact that at time of rewrite server was already
running for several years, so requirements were stable and
well-understood.
Another factor is that their service does not create/free that many
objects. The delay was caused by mere fact of GC scanning rather than
by frequent compacting of memory pools. So, from the beginning it was
obvious that potential fragmentation of the heap, which is the main
weakness of "plain" C/C++/Rust based solutions for Web back-ends, does
not apply in their case.

There is also non-technical angle involved: Discord is fueled by
investor's money. It's not that they have no revenues at all, but their
revenues at this stage are not supposed to cover their expenses.
Companies that operate in such mode have different
perspective to just about everything. I mean, different from
perspective of people like myself, working in a company that fights hard
to stay profitable and succeeds more often than not.

I have few questions about the story, most important one is whether the
weakness of this sort is specific to GC of Go, due to its relative
immaturity or more general and applies equally to most mature GCs on
the market, i.e. J2EE and .NET.
Another question is whether the problem is specific to GC-style of
automatic memory management (AMM) or applies, at least to some degree,
to other forms of AMM, most importantly, to AMMs based on Reference
Counting used by Swift and also popular in C++.
Of course, I don't expected that my questions will be answered fully on
comp.lang.c, but if some knowledgeable posters will try to answer I
would appreciate.

On 06/03/2024 12:02, Michael S wrote:
> On Tue, 5 Mar 2024 22:58:10 -0000 (UTC)
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> On Tue, 5 Mar 2024 11:11:03 +0200, Michael S wrote:
>>
>>> On Tue, 5 Mar 2024 01:54:46 -0000 (UTC)
>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>
>>>> Discord did some benchmarking of its back-end servers, which had
>>>> been using Go, and decided that switching to Rust offered better
>>>> performance.
>>>
>>> - for big and complex real-world back-end processing, writing
>>> working solution in go will take 5 time less man hours than writing
>>> it in Rust
>>
>> Nevertheless, they found the switch to Rust worthwhile.
>
> I read a little more about it.
> https://discord.com/blog/why-discord-is-switching-from-go-to-rust
>
> Summary: performance of one of Discord's most heavy-duty servers
> suffered from weakness in implementation of Go garbage collector. On
> average the performance was satisfactory, but every two minutes there
> was spike in latency. The latency during the spike was not that big
> (300 msec), but they stilled were feeling that they want better.
> They tried to tune GC, but the problem appeared to be fundamental.
> So they just rewrote this particular server in Rust. Naturally, Rust
> does not collect garbage, so this particular problem disappeared.
>
> The key phrase of the story is "This service was a great candidate to
> port to Rust since it was small and self-contained".
> I'd add to this that even more important for eventual success of
> migration was the fact that at time of rewrite server was already
> running for several years, so requirements were stable and
> well-understood.
> Another factor is that their service does not create/free that many
> objects. The delay was caused by mere fact of GC scanning rather than
> by frequent compacting of memory pools. So, from the beginning it was
> obvious that potential fragmentation of the heap, which is the main
> weakness of "plain" C/C++/Rust based solutions for Web back-ends, does
> not apply in their case.

From the same link:

"Rust uses a relatively unique memory management approach that
incorporates the idea of memory “ownership”. Basically, Rust keeps track
of who can read and write to memory. It knows when the program is using
memory and immediately frees the memory once it is no longer needed. It
enforces memory rules at compile time, making it virtually impossible to
have runtime memory bugs.⁴ You do not need to manually keep track of
memory. The compiler takes care of it."

This suggests the language automatically takes care of this. But you
have to write your programs in a certain way to make it possible. The
programmer has to help the language keep track of what owns what.

So you will probably be able to do the same thing in another language.
But Rust will do more compile-time enforcement by restricting how you
share objects in memory.

On 05/03/2024 23:34, Chris M. Thomasson wrote:
> On 3/5/2024 2:11 PM, Keith Thompson wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> [...]
>>> ADA is bullet proof... Until its not... ;^)
>>
>> The language is called Ada, not ADA.
>
> I wonder how many people got confused?
>

Apparently you and Malcolm got confused.

Others who mentioned the language know it is called "Ada". I not only
corrected you, but gave an explanation of it, in the hope that with that
clarity, you'd learn.

On 05/03/2024 23:02, Chris M. Thomasson wrote:
> On 3/5/2024 1:58 PM, Keith Thompson wrote:
>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>> On 2024-03-05, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>>>> On 3/5/2024 2:27 AM, David Brown wrote:
>>>>> On 05/03/2024 08:08, Lawrence D'Oliveiro wrote:
>>>>>> On Tue, 5 Mar 2024 00:03:54 -0600, Lynn McGuire wrote:
>>>>>>
>>>>>>> On 3/3/2024 11:43 PM, Lawrence D'Oliveiro wrote:
>>>>>>>
>>>>>>>> Did you know the life-support system on the
>>>>>>>> International Space Station was written in Ada? Not something
>>>>>>>> you would
>>>>>>>> trust C++ code to, let’s face it.
>>>>>>>
>>>>>>> Most of the Ada code was written in C or C++ and converted to Ada
>>>>>>> for
>>>>>>> delivery.
>>>>>>
>>>>>> Was it debugged again? Or was it assumed that the translation was
>>>>>> bug-
>>>>>> free?
>>>>>
>>>>> With Ada, if you can get it to compile, it's ready to ship :-)
>>>>>
>>>> Really? Any logic errors in the program itself?
>>>
>>> Ariane 5 rocket incident of 1996: The Ada code didn't catch the hardware
>>> overflow exception from forcing a 64 bit floating-point value into a 16
>>> bit integer. The situation was not expected by the code which was
>>> developed for the Ariane 4, or something like that.
>>
>> A numeric overflow occurred during the Ariane 5's initial flight -- and
>> the software *did* catch the overflow.  The same overflow didn't occur
>> on Ariane 4 because of its different flight profile.  There was a
>> management decision to reuse the Ariane 4 flight software for Ariane 5
>> without sufficient review.
>>
>> The code (which had been thoroughly tested on Ariane 4 and was known not
>> to overflow) emitted an error message describing the overflow exception.
>> That error message was then processed as data.  Another problem was that
>> systems were designed to shut down on any error; as a result, healthy
>> and necessary equipment was shut down prematurely.
>>
>> This is from my vague memory, and may not be entirely accurate.

That matches my recollection too.

>>
>> *Of course* logic errors are possible in Ada programs, but in my
>> experience and that of many other programmers, if you get an Ada program
>> to compile (and run without raising unhandled exceptions), you're likely
>> to be much closer to a working program than if you get a C program to
>> compile.  A typo in a C program is more likely to result in a valid
>> program with different semantics.
>>
>
> So close you can just feel its a 100% correct and working program?

Didn't you notice the smiley in my comment? It used to be a running
joke that if you managed to get your Ada code to compile, it was ready
to ship. The emphasis is on the word "joke".

On 06/03/2024 01:25, Lawrence D'Oliveiro wrote:
> On Tue, 5 Mar 2024 11:31:11 +0100, David Brown wrote:
>
>> That includes realising that computers could do more than number
>> crunching.
>
> Or, conversely, realizing that all forms of computation (including symbol
> manipulation) can be expressed as arithmetic?

That's also a reasonable way to put it. I have not read any of her
writings, so I don't know exactly how she described things.

> Maybe that came later, cf
> “Gödel numbering”.

That's getting a few steps further on - it is treating programs as data,
and I don't think there's any reason to suspect that was something Ada
Lovelace thought about. It's also very theoretical, while Ada was more
interested in the practical applications of computers.

On 06/03/2024 13:31, David Brown wrote:
> On 05/03/2024 23:34, Chris M. Thomasson wrote:
>> On 3/5/2024 2:11 PM, Keith Thompson wrote:
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>> [...]
>>>> ADA is bullet proof... Until its not... ;^)
>>>
>>> The language is called Ada, not ADA.
>>
>> I wonder how many people got confused?
>>
>
> Apparently you and Malcolm got confused.
>
> Others who mentioned the language know it is called "Ada".  I not only
> corrected you, but gave an explanation of it, in the hope that with that
> clarity, you'd learn.
>

Whoever wrote this short Wikipedia article on it got confused too as it
uses both Ada and ADA:

https://simple.wikipedia.org/wiki/Ada_(programming_language)

(The example program also includes 'Ada' as some package name. Since it
is case-insensitive, 'ADA' would also work.)

Here's also a paper that uses 'ADA' (I assume it is the same language):

https://www.sciencedirect.com/science/article/abs/pii/0166361582900136

Personally I'm not bothered whether anyone uses Ada or ADA. Is 'C'
written in all-caps or only capitalised? You can't tell!

On Wed, 6 Mar 2024 13:50:16 +0000
bart <bc@freeuk.com> wrote:

> On 06/03/2024 13:31, David Brown wrote:
> > On 05/03/2024 23:34, Chris M. Thomasson wrote:
> >> On 3/5/2024 2:11 PM, Keith Thompson wrote:
> >>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> >>> [...]
> >>>> ADA is bullet proof... Until its not... ;^)
> >>>
> >>> The language is called Ada, not ADA.
> >>
> >> I wonder how many people got confused?
> >>
> >
> > Apparently you and Malcolm got confused.
> >
> > Others who mentioned the language know it is called "Ada".  I not
> > only corrected you, but gave an explanation of it, in the hope that
> > with that clarity, you'd learn.
> >
>
> Whoever wrote this short Wikipedia article on it got confused too as
> it uses both Ada and ADA:
>
> https://simple.wikipedia.org/wiki/Ada_(programming_language)
>
> (The example program also includes 'Ada' as some package name. Since
> it is case-insensitive, 'ADA' would also work.)
>

Your link is to "simple Wikipedia". I don't know what it is
exactly, but it does not appear as authoritative as real Wikipedia

https://en.wikipedia.org/wiki/Ada_(programming_language)

> Here's also a paper that uses 'ADA' (I assume it is the same
> language):
>
> https://www.sciencedirect.com/science/article/abs/pii/0166361582900136
>

The article published 1982. The language became official in 1983.
Possibly, in 1982 there still was a confusion w.r.t. its name.

> Personally I'm not bothered whether anyone uses Ada or ADA. Is 'C'
> written in all-caps or only capitalised? You can't tell!
>

If only ADA, written in upper case, was not widely used for something
else...