On Tuesday, 22 September 2020 at 06:13:30 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 21 September 2020 at 10:55:22 UTC, FeepingCreature wrote:
>> Still the best language I know. At least for now, until my current compiler project is off the ground...
>
> What are the key features of your language and what kind of memory management?

Hahaha...

Cx (rename pending) is pre-0.0.1. It's self-hosting, but barely. I'm probably still a year out from *having* memory management to speak of. I'm aiming for a sort of "D1 with macros" feature level right now to start. At the moment, the compiler massively leaks memory because I have neither GC nor managed memory; every array append reallocates the entire array. And I'm not even worrying about it, because I have about 66 other TODOs to handle first.

Give it time. :)

I'll definitely post about it once it's more presentable. Repo is at https://github.com/FeepingCreature/Cx/ in case you want to take a look at it- though note that you can't even build it rn because I don't have a clean solution for the bootstrapping problem, so at the moment the process is just "build the new binary with the old binary" and I'm not sure that all of my commits are even cleanly buildable with the previous commit's binary. If you want to play with it, ping me on irc (feep in #d on freenode) for a C backend dump to bootstrap from.

(But to answer your question, I'm vaguely hoping for something semi-rusty with a clean separation of owning and reading references.)

On Monday, 21 September 2020 at 09:29:21 UTC, Tomcruisesmart wrote:
> Hi,
> I'm looking for healthy conversation.
> What are the prominent downsides of the D programming language?

First of all let me say that the community is great, so this is probably what I would state on the upsides thread.

On the downsides, getting a clear roadmap actually done, instead of falling to the fallacy of paying to much attention what other languages are doing.

Also stating that D did it first hardly helps adoption.

Yes there are plenty of language features that D did it first, but now 10 years later since I bought Andrei's book, I have most of those features available in C# 9, Java 15, C++20, alongside the richness of their tooling, libraries and eco-systems.

And what is still missing from them, happens to be on their roadmaps anyway.

Also while everyone keeps arguing about the sense of having a GC or not in a systems language, and in what form, we have languages like Java managing TB heaps with 1ms pauses, and on Android it is even possible to write drivers with their Java flavour if one so wishes (post Treble).

While other companies ship devices running bare metal Go, .NET Core and had Unity chosen something like D, they wouldn't be doing Burst compiler nowadays and contributing back some of it into .NET tooling.

They managed to achieve this by just keep going at it regardless of the opposition against it.

So this is the biggest downside, not having one main pillar to which to create a strong statement of direction where others can gather around, while at the same time stabilizing the features that are still half-way there.

On Tuesday, 22 September 2020 at 07:10:34 UTC, Paulo Pinto wrote:
> On Monday, 21 September 2020 at 09:29:21 UTC, Tomcruisesmart wrote:
>> [...]
>
> First of all let me say that the community is great, so this is probably what I would state on the upsides thread.
>
> [...]

As usual, +1 on that kind of arguments

On Tuesday, 22 September 2020 at 07:10:34 UTC, Paulo Pinto wrote:
> So this is the biggest downside, not having one main pillar to which to create a strong statement of direction where others can gather around, while at the same time stabilizing the features that are still half-way there.

Yes, but in all fairness, there are just too many general purpose languages today that you need to look at to use specific frameworks.  E.g. Typescript/angular, Dart/flutter, Go/Python/Java/google cloud, c++/physics engines, swift/ios...

It is becoming difficult to justify investing time into a specific language with no framework attached to it. E.g. the main reason for me spending time with Go is Cloud Functions. If you want to write a game with custom physics you basically cannot avoid C++ (on the same budget).

To stand out you might have to target something specific like wasm or arduino. Basically be the best option for something narrow.

On Tuesday, 22 September 2020 at 07:02:15 UTC, FeepingCreature wrote:
> management to speak of. I'm aiming for a sort of "D1 with macros" feature level right now to start. At the moment, the compiler massively leaks memory because I have neither GC nor managed memory; every array append reallocates the entire array. And I'm not even worrying about it, because I have about 66 other TODOs to handle first.

*nods* I've been pondering about using Python as an (AST-)macro language for a test-bed for language design. There are some upsides (and downsides) to using a well established scripting language for meta-programming.


> I'll definitely post about it once it's more presentable. Repo is at https://github.com/FeepingCreature/Cx/ in case you want to take a look at it- though note that you can't even build it

Thanks! At a glance it looks very similar to D. You seem to keep the class/struct distinction? (I'll look at it more closely when I get more time.)


> (But to answer your question, I'm vaguely hoping for something semi-rusty with a clean separation of owning and reading references.)

Good choice, by «semi-rusty» I hope your intent is to allow low level programming with back pointers can be done in a clean-looking fashion as well.

On Tuesday, 22 September 2020 at 07:02:15 UTC, FeepingCreature wrote:
>
> (But to answer your question, I'm vaguely hoping for something semi-rusty with a clean separation of owning and reading references.)

People who ask for required ownership often don't know what they are asking for. If ownership (single of course) is introduced, many data structures will no longer work. Right now one of D's benefits is that many data structures just work out of the box and even with GC.

I want a sea of objects, single ownership is way too limiting.

On Tuesday, 22 September 2020 at 09:47:44 UTC, IGotD- wrote:
> People who ask for required ownership often don't know what they are asking for. If ownership (single of course) is introduced, many data structures will no longer work. Right now one of D's benefits is that many data structures just work out of the box and even with GC.
>
> I want a sea of objects, single ownership is way too limiting.

I believe Microsoft has a research language where ownership is tied to a group of objects.

I actually think C++'s model works out ok, when you add custom allocators to the mix. But it would be better if the compiler could ellide allocations or simply avoid calling side-effect-free destructors if the entire (local) allocator pool was released. I also want compiler support for embedded refcounts (shared_ptr is costly).

There is no certain way to establish how memory is allocated and released in C++, so that does prevent (analytical) optimization opportunities.

The key challenge is really providing some mechanisms that makes memory management, initialization and finalization analytically tractable and providing more optimization opportunities.

(I think "provably memory safe" is too expensive in terms of development freedom and time, so ignore that aspect. "Safer" is good enough. "Safe" isn't really needed or realistic.)

On Tuesday, 22 September 2020 at 10:00:46 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 22 September 2020 at 09:47:44 UTC, IGotD- wrote:
>> People who ask for required ownership often don't know what they are asking for. If ownership (single of course) is introduced, many data structures will no longer work. Right now one of D's benefits is that many data structures just work out of the box and even with GC.
>>
>> I want a sea of objects, single ownership is way too limiting.
>
> ...
> (I think "provably memory safe" is too expensive in terms of development freedom and time, so ignore that aspect. "Safer" is good enough. "Safe" isn't really needed or realistic.)

I concur with this. The point is to make it possible to write good code, not to force you into what I think the way to write good code is.

In my experience, 90% of memory allocations are owned by one declaration and only visible inside its lifetime. My dream goal is to have references be "well-behaved" by default - scoped, nonnullable, immutable, nonreferentiable - where each of those can be opted out of as desired. Given such references, it's usually easy to do correct memory management automatically.

On Tuesday, 22 September 2020 at 10:00:46 UTC, Ola Fosheim Grøstad wrote:
>
> I believe Microsoft has a research language where ownership is tied to a group of objects.
>
> I actually think C++'s model works out ok, when you add custom allocators to the mix. But it would be better if the compiler could ellide allocations or simply avoid calling side-effect-free destructors if the entire (local) allocator pool was released. I also want compiler support for embedded refcounts (shared_ptr is costly).
>
> There is no certain way to establish how memory is allocated and released in C++, so that does prevent (analytical) optimization opportunities.
>
> The key challenge is really providing some mechanisms that makes memory management, initialization and finalization analytically tractable and providing more optimization opportunities.
>
> (I think "provably memory safe" is too expensive in terms of development freedom and time, so ignore that aspect. "Safer" is good enough. "Safe" isn't really needed or realistic.)

Pony is another language that allows objects cross referencing but just like the Microsoft research language they have something called "regions" in which the objects are allowed to cross reference.

In Rust you pretty much are required to use Rc (reference count) + RefCell (runtime bottow checker) for cross references or when there isn't a single ownership. That means that Rust suddenly becomes a garbage collected language + it must track borrow checker in runtime because the compiler cannot know that during compile time. This of course adds overhead code which I would consider in many cases unnecessary.

On 9/22/20 1:23 PM, FeepingCreature wrote:
>> (I think "provably memory safe" is too expensive in terms of development freedom and time, so ignore that aspect. "Safer" is good enough. "Safe" isn't really needed or realistic.)
> 
> I concur with this. The point is to make it possible to write good code, not to force you into what I think the way to write good code is.
> 
> In my experience, 90% of memory allocations are owned by one declaration and only visible inside its lifetime. My dream goal is to have references be "well-behaved" by default - scoped, nonnullable, immutable, nonreferentiable - where each of those can be opted out of as desired. Given such references, it's usually easy to do correct memory management automatically.

For example in GUI code widgets reference each other all over the place. Cyclic dependencies are the reason that Rust has no GUI even like dlangui despite Rust community has much more resources. So I totally agree to IGotD: "People who ask for required ownership often don't know what they are asking for."