On Tuesday, 14 September 2021 at 20:31:24 UTC, Paulo Pnito wrote:
>
> Well, Go is bootstraped and the GC is written in Go itself.
>
> https://github.com/golang/go/blob/master/src/runtime/malloc.go
>
> In any case, just like C and C++ have subsets for embedded use, in TamaGo you can for example do DMA in plain Go code.

So Go isn't totally dependent on the GC, just like D isn't. Good to know - I won't make myself silly by claiming otherwise in future debates. And your original point, that Go is a contender in systems programming space, is easy to believe when the language implements it's own GC.

>
> Coming back to D, basically my point is that GC is part of the productivity equation, even in systems programming.
>
> Naturally there are scenarios where any kind of memory allocation is a no-go, those where SPARK, MISRA-C and formal methods are the only options.

No disagreement here. I have seen many others here say the same.

> If you prefer one of those typical car analogies, classical manual memory management is like driving stick with fossil fuel, while using D with all its features, is driving a Porsche Taycan.

And the best cars are ones that are automatic by default but can switch manually if need be. For example, when you're driving a downhill route you might want to use a lower gear than normal to save your brake pads. JavaScript would I think be the car with absolutely no manual gear control and runs the risk of overheating it's brakes as a result.

On Thursday, 16 September 2021 at 11:43:09 UTC, Paulo Pinto wrote:
>
> What TLS standard?
>
> POSIX, C11, C++11, Java, .NET, Win32 are the only standards that come to my mind where some kind of TLS is included, and naturally all of them have different semantics.

The TLS standard determined by executable format standard (like ELF) and also in the RunTime ABI for the specific CPU architecture.

On Wednesday, 15 September 2021 at 10:28:05 UTC, IGotD- wrote:
> On Wednesday, 15 September 2021 at 10:00:39 UTC, Walter Bright wrote:
>>
>> GC already is an optional feature in D.
>
> It depends what you mean by that, arrays and about all other data structures rely on GC. Also entire Phobos require GC.
>
> D without any libraries does not rely on GC but then you have removed many useful features of the language. The situation is similar with C++ but there the library only depends on malloc/free without any extra memory penalty and tracing penalty.



    I just realized, hahaha. Duh. If D can call C or C++ libraries then
it doesn't even need a line of D API.

  I'd been reading comments about how API's depend on the GC, but on these comment boards
there are people trying to find a place in the world.

  I can say that I'm definitely not the most knowledgable programmer or best one, although
I might know a thing or two some others don't.  I think that thinking down on others,
or saying that they can't, is one way of making oneself feel better when facing insecurities.

  The opinion battle...  Well, D is among C++, Swift and Objective C.  I know C++
is a bit hairy, and Objective C, if I remember correctly, doesn't have complete error checking, Smalltalk based, more like a script.  D is one of the few languages that
has a full range of features.

C is very simple, that's one thing I've come to appreciate. And, with C structs you can
still do it all, just not as easily as in a class, but there's trade offs.  C can make
something like type checked JS, because you can implement prototyping with the structs.


I've had some ideas for a syntax that could hypothetically be a discretely simple notation. It would be
space blocked, like Python and I've thought of a trick or two to bring the needed symbols
down to a minimum. Also, it could use symbols like -> for conditionals, ~> for loops to increase lingual accessibility.  I have also thought of a scheme to eliminate try/catch blocks altogether, without losing any of their use.
If possible I would opt to eliminate the need for left side statement typing, while retaining strong typing.

ty

On Thursday, 16 September 2021 at 15:59:09 UTC, IGotD- wrote:

> The TLS standard determined by executable format standard (like ELF) and also in the RunTime ABI for the specific CPU architecture.

I fail to see how anything of that is relevant for "embedded without an OS" development.

On Friday, 17 September 2021 at 13:10:23 UTC, Araq wrote:
>
> I fail to see how anything of that is relevant for "embedded without an OS" development.

The compiler follows the RunTime ABI for the specific CPU architecture. That means how the compiled code accesses the TLS variables which is something you cannot completely decide for your self.

On Friday, 17 September 2021 at 13:14:01 UTC, IGotD- wrote:
> The compiler follows the RunTime ABI for the specific CPU architecture. That means how the compiled code accesses the TLS variables which is something you cannot completely decide for your self.

Well, but the compiler doesn't have to do that as long as the semantics of TLS are preserved.