On Saturday, 7 May 2022 at 19:30:08 UTC, Dukc wrote:

Yes, I agree with this in some cases. It depends on the full application. I often only use 1, 2 or 3 external libraries, but then I also need those specific ones. So it depends on what the application area, sure. How many unfilled gaps can you live with for that particular case?

For instance, if you need a solver, you are generally better off using the language that has the best API for that specific solver. You don't want to mess around with bugs in the API when programming the solver correctly is challenge! No space for "gaps" in the dev environment in that case.

Either way, I don't think web applications is a fair comparison, as it is more about the Cloud services enabling fast-boot-specialized-infrastructure, possibly with custom runtimes, for the most commonly used languages. (No executables allowed.)

It is very difficult to get access and compete in that space.

D could probably be more competitive for real time chat, game servers and services where you tailor the infrastructure yourself to run 24/7.

Yes, it is not about maximizing CPU performance. It is about infrastructure support. Instant boot, instant shutdown, automatic scaling. Basically one executable per web address in the extreme case (one server per "function").

If you are doing something mainstream, you basically will find something that get you there faster using a mainstream language (for that purpose).

Smaller languages are better off looking for the "underserved" niches. Could be gaming server. Could be something else, but run-of-the-mill web-services is "overserved" by others, so is basically impossible to do anything interesting in that space that will make developers gravitate towards you.

On Friday, 6 May 2022 at 23:29:38 UTC, user1234 wrote:

CTFE is so. Several implementations may exist but people only remember one in particular.

On Monday, 9 May 2022 at 20:45:41 UTC, Basile B. wrote:

IMO the one that allows mixin (makesomecode()) is the only one that's worth, being the first or not.

On Saturday, 7 May 2022 at 19:30:08 UTC, Dukc wrote:

Yes.

I tried D a few times over the past twenty years or so, passing on it the first time over GC performance concerns (I was a bit of a purist) and the second time over uncertainty around D1 vs D2. I came back to it in the past week or two for use in a hobby project after trying many other options…

I’m so tired of jumping through hoops to combine build systems just so I can use one neat Go library or one neat Rust library or just build most (but not all) of mobile app in Flutter/Dart …however, the standard libraries for these languages don’t support UUIDs or graphemes, so I need to pull in even more dependencies and then one hobby coder owning a small test helper project ten layers deep in my dependency graph introduces a subtle incompatibility that ripples through my whole build system and I’m almost back to square one. It would be nice if choosing a language didn’t have to mean choosing the entire build system and ecosystem of hobby projects that comes with it. Worse, these build systems’ support for mixing languages is mostly superficial. Rust’s Cargo, for example, or Go’s Get, are neither optional nor easy to integrate into other build systems. Have you ever tried combining C++ and Rust in the same project?

So I keep looking back to C++ or even C to just build a cross-platform base that can be extended with plugins written in whatever other language, and then scripting languages start to look good. Lately I started looking at compiled functional languages that integrate easily with C because I expect I’ll need their expressiveness and type safety for some tricky data transformations. OCaml gets pretty close - if it came with pkg-config support to find the runtime library, I might even have stopped there! However, I looked even further and found D has it all: it’s compiled, it integrates easily with existing C code whether I’m using GCC or Clang, it doesn’t force me to use a bespoke build system (I’m avoiding DUB so far, Meson is good for me), and wonder of wonders: it has standard library support for iterating through Unicode text one grapheme at a time! Well I’m sure I’ll encounter a rough edge or two. Maybe I’ll even move on again. However, with CTFE and lazy parameters to boot it’ll take more than one or two scrapes to shake my newfound hope in this language.

On Tuesday, 10 May 2022 at 04:16:32 UTC, Joshua wrote:

I am a bit puzzled by your experience. It is not uncommon to use "vendoring" of libraries in Go, so I am not quite sure why you feel bound to something specific. Granted Go have other issues that are annoying, e.g. no exceptions and not the best abstraction mechanism.

That said, D seems to have switched focus from C++ to C lately, so it might be a good fit for your needs. The tradeoff is that you cannot have a modern GC and also have good C interop.

On Friday, 6 May 2022 at 13:23:30 UTC, max haughton wrote:

I have taken a look at the repo, and it looks promising, is it able to compile a subset of the language at this point?

Is there a mailing list for it? I'd like to subscribe if there is, but summertime is unfortunately very busy, so I won't have any time until late in the autumn. It would be very interesting to see how you think about your concept though.

On Tuesday, 10 May 2022 at 07:00:03 UTC, Ola Fosheim Grøstad wrote:

Right! Ok, what I mean is that I can easily combine D, C, and C++ in the same binary build target because none of these languages are tied to a build system that supports only one language. As an example, if I'm willing write a bit of C-interop boilerplate and make some decisions about garbage collection, a meson.build like the following just works:

project('myapp', ['d', 'c', 'cpp'])

executable('myapp', ['lib.d', 'lib.c', 'lib.c++'])

I can't throw Rust into the same build target, but even if I could I'd still have to deal with the fact that doing anything interesting in Rust (or Go) requires using Cargo (or go get) to download 10× more dependencies than I asked for, which is 10× more long-term instability than I intended to accept. I don't mean to be excessively critical: they're wonderful languages, and having the option to reuse work from such large ecosystems is truly amazing. AFAIK, nothing remotely similar existed for compiled languages more than 10 or 15 years ago. I'm just not a fan of the trade-off: it's like, "Everything you can see in this vast ecosystem is free to reuse, all you have to do is use this here build system which supports the only programming language you'll ever need. Isn't that great? Now go forth and make a name for yourself by rewriting useful libraries from other other inferior languages into our new paradise!" It's exciting and fun and so much work and at the end you get... a silo. Not so with D (or at least not as far as I know yet! ☺)

On Tuesday, 10 May 2022 at 23:08:18 UTC, Joshua wrote:

Hm, I get a feeling you speak more of packages than builds? I assume any build system that generates makefiles can be extended to work well with Go and Rust?

It is easier to create C wrappers in D than Go, for modern C++ not so much, as modern C++ is heavy on header files.