On Sunday, 23 October 2022 at 13:38:03 UTC, matheus wrote:

Yeah, that's why I don't like "hyped" languages.

We use C# at work too, mainly because it's a well designed language (quite easy to learn), has good support (ecosystem) and IDEs. Sure it's a bit verbose, but the upsides make it worth it.

D has so much potential to be a replacement for many other languages.

It could replace Python, C# in some cases, C++ for sure, C with betterC, maybe even R or Julia.

What is needs though is to be stable and have an LTS branch.

Companies don't really care at all what language you use, they care about economics and risk mitigation.

If I say to my team "let's write the next thing in D", the first question will be about ecosystem, IDEs and other things surrounding the language, not the language itself, no matter how good it is, unfortunately.

I really hope that one day we will have a bigger following (which will enable us to make better tools), because there are so many things D is better at than many other languages.

On Sunday, 23 October 2022 at 14:55:56 UTC, Imperatorn wrote:

That's not all true, TLS version is not needed

Go became the cloud native language without that BS

Java was held back because of it, wich helped C# penetrate the bloat driven corporates

As they figured it out, Oracle started to speed up development of the language:

• multiple GCs
• pattern matching
• var
• data class
• green threads
• graalvm

Now C# try to fight back

• record
• pattern matching
• green thread
• nativeaot

Go now is being held back by corporates (amazon/google/microsoft), just like rust

D should be free to experiment, not every language needs to be taken hostage by corporates

As you said, corporates don't care about what language they use, they'll dump it if they find something that suits their cost requirements better

• simplifying the language

• finishing the existing features

• drastically improving ergonomics in some areas

• invest massively in tooling

• keep experiment with new ideas and take a look at the backlog of DIPs

That's what i'd do if i knew how to make and had to work on a language

Mistakes of the past need to go, otherwise people will constantly look for alternative, that alternative needs to be D+1 that fixed past mistakes, and not double down on them, because demography mean the people who rely the mistake will disappear, and the new generation of devs will choose something else

On Sunday, 23 October 2022 at 19:39:49 UTC, ryuukk_ wrote:

But Go has not changed all that much until recently, with minimal breakage.

How is Rust held back by corporations though?

Yes, but since there is no willingness to take breaking changes in D there seems to be some kind of gridlock as far as language design and evolution goes.

Right now there seems to be a flurry of alternatives that aim for the same use scenario as C++. Within 5-10 years some of them will gather a following or C++/Rust will evolve fast enough to keep the competing solutions at a distance.

How can D position itself without a significant change in strategy, which would require a new leadership style? Can you see that happening within a timespan of 3 years?

On Sunday, 23 October 2022 at 19:39:49 UTC, ryuukk_ wrote:

I'm not sure what that means. When large companies make languages they can't push too much abstract compiler technology ideas on the masses because that would hurt the adoption. When companies throw millions into new languages, that would be a waste of money if nobody can use it. One use case is Swift which in my mind is not that difficult but still some Apple developers think it is too complicated. The Apple management is keeping the language developers on a leach so that they don't get out of hand with their academics. Imagine trying to push Rust onto Apple developers, that simply wouldn't have worked and they would have rejected it.

On Thursday, 20 October 2022 at 13:37:07 UTC, Don Allen wrote:

use std::cell::RefCell;

fn main() {
    let foo = RefCell::new(5);
    let bar = || {
        *foo.borrow_mut() = 17;
    };
    let baz = || {
        *foo.borrow_mut() = 42;
    };
    bar();
    println!("{}", foo.borrow());
    baz();
    println!("{}", foo.borrow());
    }

Yes, I believe this shows maybe the biggest weakaness of Rust. I could live with a language having a syntax like that (still better than C++, at least the old standards), but it does slows down working compared to most other new-generation languages.

Too bad. Rust's error handling seems so advanced. I'm not talking only about the ability to be safe without a stop-the-world GC, but about it's ability to detect other errors too. A good example is it's UTF-8 string type. Not only it is guaranteed to point to valid memory, it is statically guaranteed to point to valid UTF-8! A D programmer needs to rely on contract programming instead. Although I think that placing a few asserts is still be a good idea even in Rust.

Disclaimer: the above is likely to be humbug because I have no usage experience of Rust, only studied it's docs.

On Monday, 24 October 2022 at 20:04:00 UTC, Dukc wrote:

use std::cell::RefCell;

fn main() {
    let foo = RefCell::new(5);
    let bar = || {
        *foo.borrow_mut() = 17;
    };
    let baz = || {
        *foo.borrow_mut() = 42;
    };
    bar();
    println!("{}", foo.borrow());
    baz();
    println!("{}", foo.borrow());
    }

I'd disagree about "biggest". My use of closures would get me a summons from the Rust Unidiomatic Police. In other words, my guess is that not many run across the problem I did.

A more serious weakness, in my opinion, is the difficulty of dealing with global state. Statics must be initialized, but the initializer must be known at compile-time. So if you want to define a global that you need to initialize with a value only known at run-time and will never change again, you must define it as mutable, with all the issues that raises. And its type will need to be Option and the compile-time-known initializer will have to be None. You then mutate it to be Some(what-you-want) at run-time. References to this will have to be in an "unsafe" block, even though the situation would be perfectly safe if immutable statics could be initialized at runtime (I think they may be trying to fix this with something available only in the nightly version, but I am not positive).

Then there's the problem I've mentioned earlier -- Rust considers everything to be multi-threaded, even if it isn't. And it imposes restrictions on the programmer that are only needed in multi-threaded situations, such as considering mutable statics to be unsafe. Even if the mutable static is wrapped in a mutex, you still need to use unsafe blocks to refer to it.

Not all GCs are stop-the-world. And, in my opinion, the negativity about garbage collectors is exaggerated. There's an awful lot of software out there written in gc-ed languages, e.g., Python, Go, Javascript, that we all use every day, even on our phones, and that performs adequately or more than adequately.

Yes, there are a lot of positive things to say about Rust. But for me, the insistence on no GC disqualifies it from use in situations where a GC-ed language would do the job, because of the cost in programming difficulty that that insistence imposes, e.g., lifetime hell and frustrating battles with the borrow-checker. And that difficulty is compounded by the multi-threaded assumption and the handling of statics.

On Tuesday, 25 October 2022 at 17:16:58 UTC, Don Allen wrote:

But Rust is a system level programming language, it was designed for writing device drivers, filesystems, and other resource constrained and latency critical software, where languages with runtime environments can't be used, even if you're okay with them

Even the actual software libraries used by higher level languages in mobile applications are wrappers over the extremely power/compute efficient C/C++ libraries that were written with misery and paranoia, it's not as if a higher level languages' tech stack doesn't involve lower level language, but the opposite is true

Thus, Rust always assumes the worst case scenarios and makes the programmer distort their code to make it compile, and, unless you use lots of unsafe, the code really belongs to "if it compiles, it doesn't have memory bugs" camp of software

On Tuesday, 25 October 2022 at 17:16:58 UTC, Don Allen wrote:

When developing C++ code, I was solving this problem by just embedding a Lua interpreter (and also a much less known http://squirrel-lang.org/ because its syntax resembles C). This approach provides GC and easy programming for the parts of a program, which are not performance critical.

Seems like Rust also can do this just fine: https://docs.rs/rlua/latest/rlua/

On Tuesday, 25 October 2022 at 17:42:42 UTC, Siarhei Siamashka wrote:

Hey buddy, someone else on the internet that has used Squirrel. I thought I was alone :D

I wish I could have used D instead tho

On Tuesday, 25 October 2022 at 17:37:22 UTC, Tejas wrote:

That's true and is essentially what I'm saying -- Rust is fine for what it was designed for, but it is not suitable for ordinary application development. But this is ignored by many in the Rust community and even by Mozilla, which, for example, is using Rust in Firefox.

Except I'm talking about the pain inflicted on the user of the language, not the pain it took to create the language and its supporting libraries.

There are plenty of examples of gc-ed languages that do the same without Rust's difficulty.