On Wednesday, 22 January 2014 at 02:18:43 UTC, Vladimir Panteleev wrote:
> Hi,
>
> What's the current situation of using D without Phobos/Druntime?
>
> Sometimes, it's quite useful to be able to use D to create tiny EXEs/DLLs. For example, create simple DLL plugins that will be loaded into non-D programs, or even not have a 50-line program take half a meg. Additionally, some tasks require injecting a DLL systemwide (into every running process), so it is critical to minimize the impact by being as unintrusive as possible and having a minimal overhead.
>
> I've started a "framework" for this purpose a while ago[1], but I heard of people starting similar projects since then and I think they've gotten further than me. Would there be any interest in collaborating and turning this into a community project?
>

I'm curious, what is your motivation for pursuing this?  What's your ultimate objective?

D is NOT a systems language. So no point in application level
comparison with C. Set aside syntactic similarities.

If your language does not have the C / C++ *semantics* of new /
delete, or, better yet, owned pointers in Rust that automatically
free their memory when they go out of scope, but instead forces a
GC down your throat for some of the most basic array and standard
library functionality, you will never, ever write kernel level
code that stands a chance against C, C++ or Rust.

Other than that, a "D with owned pointers" and an opt-in GC
relegated to a library implementation (maybe with some minimal
language hooks) would be my language of choice. I love D's
templates.

I understand that this would be a complete redesign of the
language and Phobos, and would break most of the D code out
there. That's why it won't happen.

Everybody seems to realize this, finally. Just have a look at the
last (long) GC thread. Comparisons of D with Java and C# all over.

On 1/25/14 2:15 PM, Frank Bauer wrote:
> D is NOT a systems language. So no point in application level
> comparison with C. Set aside syntactic similarities.
>
> If your language does not have the C / C++ *semantics* of new /
> delete, or, better yet, owned pointers in Rust that automatically
> free their memory when they go out of scope, but instead forces a
> GC down your throat for some of the most basic array and standard
> library functionality, you will never, ever write kernel level
> code that stands a chance against C, C++ or Rust.
>
> Other than that, a "D with owned pointers" and an opt-in GC
> relegated to a library implementation (maybe with some minimal
> language hooks) would be my language of choice. I love D's
> templates.
>
> I understand that this would be a complete redesign of the
> language and Phobos, and would break most of the D code out
> there. That's why it won't happen.
>
> Everybody seems to realize this, finally. Just have a look at the
> last (long) GC thread. Comparisons of D with Java and C# all over.

Wait, what?

Andrei

On Saturday, 25 January 2014 at 22:15:29 UTC, Frank Bauer wrote:
> D is NOT a systems language. So no point in application level
> comparison with C. Set aside syntactic similarities.
>
> If your language does not have the C / C++ *semantics* of new /
> delete, or, better yet, owned pointers in Rust that automatically
> free their memory when they go out of scope, but instead forces a
> GC down your throat for some of the most basic array and standard
> library functionality, you will never, ever write kernel level
> code that stands a chance against C, C++ or Rust.
>
> Other than that, a "D with owned pointers" and an opt-in GC
> relegated to a library implementation (maybe with some minimal
> language hooks) would be my language of choice. I love D's
> templates.
+1
> I understand that this would be a complete redesign of the
> language and Phobos, and would break most of the D code out
> there. That's why it won't happen.
>
> Everybody seems to realize this, finally. Just have a look at the
> last (long) GC thread. Comparisons of D with Java and C# all over.

Unfortunately, D is not similar to Java or C# (from the point of view of the garbage collector). :/

Am 25.01.2014 23:33, schrieb Andrei Alexandrescu:
> On 1/25/14 2:15 PM, Frank Bauer wrote:
>> D is NOT a systems language. So no point in application level
>> comparison with C. Set aside syntactic similarities.
>>
>> If your language does not have the C / C++ *semantics* of new /
>> delete, or, better yet, owned pointers in Rust that automatically
>> free their memory when they go out of scope, but instead forces a
>> GC down your throat for some of the most basic array and standard
>> library functionality, you will never, ever write kernel level
>> code that stands a chance against C, C++ or Rust.
>>

The guys at Xerox PARC, Swiss Federal Institute of Technology in Zurich,
Cisco, Olivetti seem to think otherwise.

Sadly the industry never cared for their research in programming languages and safe OS systems.

--
Paulo

On Saturday, 25 January 2014 at 22:15:29 UTC, Frank Bauer wrote:
> D is NOT a systems language. So no point in application level
> comparison with C. Set aside syntactic similarities.

Urgh...

> If your language does not have the C / C++ *semantics* of new /
> delete,

Setting aside syntax, it's extremely trivial to implement C++-style new/delete as function templates.

> or, better yet, owned pointers in Rust that automatically
> free their memory when they go out of scope, but instead forces a
> GC down your throat for some of the most basic array and standard
> library functionality,

Array functionality *that C and C++ do not have*. D slices are plenty useful without the primitives that allocate, such as concatenation. This very thread is an example of how you're not forced to use a runtime that implements these primitives.

> Other than that, a "D with owned pointers" and an opt-in GC
> relegated to a library implementation (maybe with some minimal
> language hooks) would be my language of choice. I love D's
> templates.

The GC is a library implementation with language hooks.

> I understand that this would be a complete redesign of the
> language and Phobos, and would break most of the D code out
> there. That's why it won't happen.

There aren't that many language features that depend on a GC, and the ones that do can be disabled with a custom runtime.

druntime/Phobos are designed for a mixed allocation strategy, where tracing GC is one of the strategies used. Many Phobos types and functions do not rely on a GC.

> Everybody seems to realize this, finally. Just have a look at the
> last (long) GC thread. Comparisons of D with Java and C# all over.

Java and C# do not function well without GC at all (disregarding the effort you'd have to go through to get a Java or C# implementation without GC).

D definitely *does*.

On Saturday, 25 January 2014 at 22:15:29 UTC, Frank Bauer wrote:
> D is NOT a systems language. So no point in application level
> comparison with C. Set aside syntactic similarities.
>
> If your language does not have the C / C++ *semantics* of new /
> delete,

C doesn't have new/delete.

> or, better yet, owned pointers in Rust that automatically
> free their memory when they go out of scope, but instead forces a
> GC down your throat for some of the most basic array

You can do C style array/pointer fiddling in D without the GC. You can't new or append, but you can't do that in C either. Seems to me, you're comparing more to C++/Rust than to C.

> and standard library functionality,

You have access to C's standard library from D.

> you will never, ever write kernel level
> code that stands a chance against C, C++ or Rust.

Your points don't apply to D vs C.

On Saturday, 25 January 2014 at 23:01:12 UTC, Jakob Ovrum wrote:
> Setting aside syntax, it's extremely trivial to implement C++-style new/delete as function templates.

I am interested in this.  I am currently using new/destroy.  If you know of a way to use templates for this (aside from RefCounted and Scoped) please elaborate. It would be quite helpful for me.

> The GC is a library implementation with language hooks.

I am implementing a custom runtime and am very interested in this as well.  This was the heart of my previous post.  I see that the runtime hooks can be used to implement an alternate GC, but do you think these hooks could be used to implement a reference counted, owned pointer, etc... implementation as an alternative to a GC? Are there any currently missing runtime hooks preventing such an implementation?

Mike

On Saturday, 25 January 2014 at 23:02:44 UTC, anonymous wrote:
> C doesn't have new/delete.

Please read-before-write (non atomic operation): C has the *semantics* of new / delete with malloc and free. D has too, if you constrain yourself to memory allocation via std.c.stdlib.malloc and free, which means no object allocation with *new* anymore. We don't want to constrain ourselves to that, do we? What we want is malloc/free *semantics* throughout if we choose so.

> You can do C style array/pointer fiddling in D without the GC. You can't new or append, but you can't do that in C either. Seems to me, you're comparing more to C++/Rust than to C.

> You have access to C's standard library from D.

I'm aware that I can use a D subset that is roughly equivalent to C and C's standard library. This subset is precisely what I am *not* talking about. I am talking about all the great modern architectural features of D and Phobos.

> Your points don't apply to D vs C.

It does if I want to use D in its entirety not just its subset equivalent to C.

So if I want C++ new/delete or Rust's owned pointer semantics I should constrain myself to D's subset that is equivalent to C and forget about Phobos altogether? Welcome to the *new* D.

On Saturday, 25 January 2014 at 23:01:12 UTC, Jakob Ovrum wrote:
> Setting aside syntax, it's extremely trivial to implement C++-style new/delete as function templates.

Fine. Can I use it with Phobos?

> Array functionality *that C and C++ do not have*. D slices are plenty useful without the primitives that allocate, such as concatenation.

I love D's slices. Super elegant. Can't imagine how one could ever invent half slices, i.e. array pointers without length ;)

> This very thread is an example of how you're not forced to use a runtime that implements these primitives.

We must be in two different threads:

On Wednesday, 22 January 2014 at 02:18:43 UTC, Vladimir Panteleev wrote:
> - A "standard library" which does not require runtime support, but can also be used when using Druntime (as a GC-free alternative to Phobos)

On Wednesday, 22 January 2014 at 04:13:41 UTC, Mike wrote:
> Phobos will not be useful to me unless I can find some way to make it lighter and GC-Free. ... I would _really_ like to have the
> whole concept of a GC decoupled from D. There are many suitable memory models to use with D, and the memory model seems like it should be a platform feature, not a language feature.

I understand from this thread that we are at a GC-free Hello World at this point. Well ...

> The GC is a library implementation with language hooks.

No it is not. It is part of the language. Every allocation *inside* the language (i.e. with new) goes through the GC.

> There aren't that many language features that depend on a GC, and the ones that do can be disabled with a custom runtime.

I don't want to miss out on a single language feature of D. Where is that GC-free runtime?

> druntime/Phobos are designed for a mixed allocation strategy, where tracing GC is one of the strategies used. Many Phobos types and functions do not rely on a GC.

In theory (which gives me hope), not in practice. Where is that GC-free Phobos?

> Java and C# do not function well without GC at all (disregarding the effort you'd have to go through to get a Java or C# implementation without GC).
>
> D definitely *does*.

Again, this gives me hope. Please Walter, Andrei: search all the forums for "I want D with opt-in GC" (fuzzy search, that is) and count matches.