www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Zig vs D generics

reply Walter Bright <newshound2 digitalmars.com> writes:
https://news.ycombinator.com/item?id=33142751
Oct 09 2022
next sibling parent Salih Dincer <salihdb hotmail.com> writes:
On Sunday, 9 October 2022 at 21:48:38 UTC, Walter Bright wrote:

 https://news.ycombinator.com/item?id=33142751


Can we create a real derived structure with templates at compile 
time? Still, I remembered that there was such a thing as a static 
structure. What can the Zig programming language add to D?

SDB 79
Oct 09 2022
prev sibling parent reply Kagamin <spam here.lot> writes:
In contrast, C++ code attempting to call non-constexpr functions 
(i.e. functions only accessible at run time) in a constexpr 
context (i.e. functions which are available both at compile time 
and run time) will give an error at the call site.


Eh? So can C++ support an allocator that works both at compile 
time and at run time? I use such allocator in my D code so it's 
ctfeable.
Oct 10 2022
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 10 October 2022 at 07:30:38 UTC, Kagamin wrote:

In contrast, C++ code attempting to call non-constexpr 
functions (i.e. functions only accessible at run time) in a 
constexpr context (i.e. functions which are available both at 
compile time and run time) will give an error at the call site.


 Eh? So can C++ support an allocator that works both at compile 
 time and at run time? I use such allocator in my D code so it's 
 ctfeable.


Depends on how much you expect from it, featurewise,

https://www.cppstories.com/2021/constexpr-new-cpp20
Oct 10 2022
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 10 October 2022 at 07:30:38 UTC, Kagamin wrote:

 Eh? So can C++ support an allocator that works both at compile 
 time and at run time? I use such allocator in my D code so it's 
 ctfeable.


No, only encapsulated types can hold memory. This is the right 
approach when you don't have garbage collection. If you allow 
manual compile time allocation you end up with something that 
doesn't scale in terms of debugging.

Or you need a very advanced debugger.
Oct 10 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 10 October 2022 at 09:55:32 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 10 October 2022 at 07:30:38 UTC, Kagamin wrote:

 Eh? So can C++ support an allocator that works both at compile 
 time and at run time? I use such allocator in my D code so 
 it's ctfeable.


 No, only encapsulated types can hold memory. This is the right 
 approach when you don't have garbage collection. If you allow 
 manual compile time allocation you end up with something that 
 doesn't scale in terms of debugging.

 Or you need a very advanced debugger.


Argh, I couldn't make this work either in C++20. I thought 
std::string("hello world) should be constexpr returnable. 
Apparently not, unless I did something wrong. (That is a big 
weakness, so I really hope I did something wrong. ;-)
Oct 10 2022
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 10 October 2022 at 10:23:44 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 10 October 2022 at 09:55:32 UTC, Ola Fosheim Grøstad 
 wrote:

 On Monday, 10 October 2022 at 07:30:38 UTC, Kagamin wrote:

 Eh? So can C++ support an allocator that works both at 
 compile time and at run time? I use such allocator in my D 
 code so it's ctfeable.


 No, only encapsulated types can hold memory. This is the right 
 approach when you don't have garbage collection. If you allow 
 manual compile time allocation you end up with something that 
 doesn't scale in terms of debugging.

 Or you need a very advanced debugger.


 Argh, I couldn't make this work either in C++20. I thought 
 std::string("hello world) should be constexpr returnable. 
 Apparently not, unless I did something wrong. (That is a big 
 weakness, so I really hope I did something wrong. ;-)


I guess you did something wrong, :)

https://godbolt.org/z/qKPGvbd1W

```cpp
#include <string>
#include <iostream>

constexpr std::string hello() {
     return std::string("hello world");
}

int main() {
     static constexpr auto greeting = hello();

     std::cout << greeting << std::endl;
}
```
Oct 10 2022
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 10 October 2022 at 14:18:52 UTC, Paulo Pinto wrote:

 I guess you did something wrong, :)


Didn't work in clang for me… but good to know that it is supposed 
to work.
Oct 10 2022
next sibling parent Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Monday, 10 October 2022 at 16:27:11 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 10 October 2022 at 14:18:52 UTC, Paulo Pinto wrote:

 I guess you did something wrong, :)


 Didn't work in clang for me… but good to know that it is 
 supposed to work.


I was rather sure it was supposed not to work. There is 
`constexpr new` in C++20, but memory allocated with it must be 
`constexpr delete`’d. Could be that GCC’s `std::string` does not 
allocate memory for initializing the string with a literal, but 
Clang does.

My advice: Don’t rely on GCC’s behavior.
Oct 10 2022
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 10 October 2022 at 16:27:11 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 10 October 2022 at 14:18:52 UTC, Paulo Pinto wrote:

 I guess you did something wrong, :)


 Didn't work in clang for me… but good to know that it is 
 supposed to work.


As it stands, you shouldn't rely on clang for anything beyond 
C++17, it is hit and miss with newer revisions until some big 
shot takes over Apple and Google's role on frontend development.
Oct 10 2022
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 10 October 2022 at 18:19:29 UTC, Paulo Pinto wrote:

 As it stands, you shouldn't rely on clang for anything beyond 
 C++17, it is hit and miss with newer revisions until some big 
 shot takes over Apple and Google's role on frontend development.


I am good. You can to some extent test and provide fall-backs if 
you want to write portable open source code that is based on 
C++20 features:

https://en.cppreference.com/w/cpp/feature_test
open source code that is based on C++20.
Oct 11 2022
prev sibling parent reply Tejas <notrealemail gmail.com> writes:
On Monday, 10 October 2022 at 18:19:29 UTC, Paulo Pinto wrote:

 On Monday, 10 October 2022 at 16:27:11 UTC, Ola Fosheim Grøstad 
 wrote:

 On Monday, 10 October 2022 at 14:18:52 UTC, Paulo Pinto wrote:

 I guess you did something wrong, :)


 Didn't work in clang for me… but good to know that it is 
 supposed to work.


 As it stands, you shouldn't rely on clang for anything beyond 
 C++17, it is hit and miss with newer revisions until some big 
 shot takes over Apple and Google's role on frontend development.


Why is Apple not willing to develop clang nowadays? Haven't seen 
them express interest in Carbon or anything other than Swift
Oct 11 2022
next sibling parent ryuukk_ <ryuukk.dev gmail.com> writes:
On Tuesday, 11 October 2022 at 14:49:44 UTC, Tejas wrote:

 On Monday, 10 October 2022 at 18:19:29 UTC, Paulo Pinto wrote:

 On Monday, 10 October 2022 at 16:27:11 UTC, Ola Fosheim 
 Grøstad wrote:

 On Monday, 10 October 2022 at 14:18:52 UTC, Paulo Pinto wrote:

 I guess you did something wrong, :)


 Didn't work in clang for me… but good to know that it is 
 supposed to work.


 As it stands, you shouldn't rely on clang for anything beyond 
 C++17, it is hit and miss with newer revisions until some big 
 shot takes over Apple and Google's role on frontend 
 development.


 Why is Apple not willing to develop clang nowadays? Haven't 
 seen them express interest in Carbon or anything other than 
 Swift


Swift is a much better language than C++, why would they invest 
in a buggy, ugly, messy and bloated language?

Apple main audience is system/app developers, they have taste and 
want to enable people to do tasteful things, C++ is ugly

Have you tried SwiftUI? give it a try, you'll understand why
Oct 11 2022
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 11 October 2022 at 14:49:44 UTC, Tejas wrote:

 On Monday, 10 October 2022 at 18:19:29 UTC, Paulo Pinto wrote:

 On Monday, 10 October 2022 at 16:27:11 UTC, Ola Fosheim 
 Grøstad wrote:

 On Monday, 10 October 2022 at 14:18:52 UTC, Paulo Pinto wrote:

 I guess you did something wrong, :)


 Didn't work in clang for me… but good to know that it is 
 supposed to work.


 As it stands, you shouldn't rely on clang for anything beyond 
 C++17, it is hit and miss with newer revisions until some big 
 shot takes over Apple and Google's role on frontend 
 development.


 Why is Apple not willing to develop clang nowadays? Haven't 
 seen them express interest in Carbon or anything other than 
 Swift


clang is good enough for their purposes, Metal Shading Language 
is a C++14 dialect, IO Kit uses a Embedded C++ dialect and C++17 
is good enough for DriverKit and is the current baseline for LLVM 
contributions.

Swift is explicitly developed as the replacement for C, C++ and 
Objective-C on Apple platforms, this goal is even mentioned on 
its documentation and they made the point to re-assert it on this 
year's WWDC.

The analysis of iOS 16 binaries apparently shows that "Swift 
adoption continues its exponential climb and surpassed C++ this 
year".

https://blog.timac.org/2022/1005-state-of-swift-and-swiftui-ios16/

Note that while Apple has released a header only library for 
using Metal APIs from C++, not only it is a very bare bones 
experience when compared with Objective-C and Swift, it actually 
depends on the Objective-C runtime, by creating wrapper classes 
around objc_msgSend.
Oct 11 2022
next sibling parent reply IGotD- <nise nise.com> writes:
On Tuesday, 11 October 2022 at 15:56:11 UTC, Paulo Pinto wrote:

 Swift is explicitly developed as the replacement for C, C++ and 
 Objective-C on Apple platforms, this goal is even mentioned on 
 its documentation and they made the point to re-assert it on 
 this year's WWDC.

 The analysis of iOS 16 binaries apparently shows that "Swift 
 adoption continues its exponential climb and surpassed C++ this 
 year".


C++ is starting to become EOL and languages like Swift will take 
over more and more. Swift is cross platform and available on 
Linux and Windows.

SwiftUI is currently Apple only but if they decide to make it 
open source so that others can adapt it for Linux GUIs and 
Windows then it becomes even more interesting, it's basically a 


Currently Swift is not bootstrapped and there is a lot of C++ in 
the compiler itself. Right now there is a lot of work to make 
Swift work together with C++. Similar to D this is step to 
gradually rewrite the Swift compiler in Swift. Swift will just as 
D have the same C++ FFI advantage.

There is currently very little reason to choose C++ over any 
other modern alternative today for a new project. We will clearly 
see that as big companies contributions for C++ will wane. Will 
there even be enough interest to implement C++23?
Oct 11 2022
next sibling parent user1234 <user1234 12.de> writes:
On Tuesday, 11 October 2022 at 16:14:39 UTC, IGotD- wrote:

 Currently Swift is not bootstrapped and there is a lot of C++ 
 in the compiler itself. Right now there is a lot of work to 
 make Swift work together with C++.


That's almost certain that the Swift language developpers need 
that interop to bootstrap the language since they use the LLVM 
C++ API.
Oct 11 2022
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 11 October 2022 at 16:14:39 UTC, IGotD- wrote:

 On Tuesday, 11 October 2022 at 15:56:11 UTC, Paulo Pinto wrote:

 ...


 Currently Swift is not bootstrapped and there is a lot of C++ 
 in the compiler itself. ...


Bootstraping plans are already in motion,

https://forums.swift.org/t/implementing-parts-of-the-swift-compiler-in-swift/59524


 There is currently very little reason to choose C++ over any 
 other modern alternative today for a new project. We will 
 clearly see that as big companies contributions for C++ will 
 wane. Will there even be enough interest to implement C++23?


There are still many domains where for better or worse, C++ 
rules, and it will for years to come due to ecosystem synergies, 
see COBOL, Fortran and C. Many tend to forget C is only 10 years 
younger than COBOL.

However when several big names in the ecosystem start playing 
with alternatives, we might be at the start of stagnation of the 
ISO process, but even then, remember many devs keep coding in C89 
by choice, and same reasoning can be applied to C++ revisions.

Since we are on D forums, what matters is what piece of the pie D 
can still get hold of, specially in the mist of stiff competition.
Oct 11 2022
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 11 October 2022 at 16:14:39 UTC, IGotD- wrote:

 C++ is starting to become EOL and languages like Swift will 
 take over more and more. Swift is cross platform and available 
 on Linux and Windows.


Swift is much higher level, although there has been some talk of 
making it more capable for machine-level programming.


platform, you can basically always expect the support on "foreign 
platforms" to be subpar and if it isn't you have to plan for 
platforms being dropped in the future for non-technical reasons.

They may technically be cross platform, but they sure ain't 
politically cross platform :-).



 SwiftUI is currently Apple only but if they decide to make it 
 open source


This will not happen with the current culture. Apple is a company 
that doesn't shy away from patenting and suing over user 
interface mechanisms and design.



 There is currently very little reason to choose C++ over any 
 other modern alternative today for a new project.


Objectively speaking, there are plenty of reasons to write 
performance parts of a new application in C++, if you already 
know it, as it provides more options than any other competitor.  
And while C has better interop and portability, C++ still has a 
wider array of interop and portability options than any other 
single alternative.

This will remain true until we see a clear sign that other 
languages are cutting into C++ at scale. Right now they are just 
nibbling around the edges.



 We will clearly see that as big companies contributions for C++ 
 will wane. Will there even be enough interest to implement 
 C++23?


Clang seems to be on track with C++23. They are behind on some 
select features of C++20: https://en.cppreference.com/w/cpp/20
Oct 12 2022
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 12 October 2022 at 11:27:26 UTC, Ola Fosheim 
Grøstad wrote:

 On Tuesday, 11 October 2022 at 16:14:39 UTC, IGotD- wrote:

 ...



 There is currently very little reason to choose C++ over any 
 other modern alternative today for a new project.


 Objectively speaking, there are plenty of reasons to write 
 performance parts of a new application in C++, if you already 
 know it, as it provides more options than any other competitor. 
  And while C has better interop and portability, C++ still has 
 a wider array of interop and portability options than any other 
 single alternative.

 This will remain true until we see a clear sign that other 
 languages are cutting into C++ at scale. Right now they are 
 just nibbling around the edges.


C++ was created for writing distributed systems at AT&T, nowadays 
other languages rule in across all projects that are part of 
Cloud Native Computing Foundation, they aren't just a tiny bunch,

https://landscape.cncf.io/

C++ ruled the GUI frameworks tooling during the 1990's, with C++ 
frameworks being shipped with every compiler, nowadays with 
exception of Microsoft, there isn't an OS vendor left shipping a 
C++ GUI framework with the platform SDK. Qt seems to be the last 
man standing, and even them, had to turn into enterprise 
customers to keep their developers going.

C++ still has many key domains, when the head of ISO C++ does a 
public plea for developers to improve C++ instead of going 
elsewhere, while presenting his own flavour of C++-vnext, one 
needs to wonder if it will ever be anything past ISO C++26.

Penny and penny laid up will be many.
Oct 12 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 12 October 2022 at 12:24:05 UTC, Paulo Pinto wrote:

 C++ ruled the GUI frameworks tooling during the 1990's, with 
 C++ frameworks being shipped with every compiler, nowadays with 
 exception of Microsoft, there isn't an OS vendor left shipping 
 a C++ GUI framework with the platform SDK. Qt seems to be the 
 last man standing, and even them, had to turn into enterprise 
 customers to keep their developers going.


Computers get more memory, cores, GPUs and scripting languages 
with JITs. For most applications it would make more sense to use 
a JIT for the GUI. Not surprising that the application area shift 
over time.

But not necessarily for all: C++ is still competitive for 
audio/video/embedded where you want to build the GUI from the 
ground up to get a competitive advantage.


 C++ still has many key domains, when the head of ISO C++ does a 
 public plea for developers to improve C++ instead of going 
 elsewhere, while presenting his own flavour of C++-vnext, one 
 needs to wonder if it will ever be anything past ISO C++26.


LLVM has ensured that there are many other options, so people 
have more compilers to play with. That means there will be less 
space for any singular language.  The big features like 
stack-less coroutines isn't really a hobbyist implementation 
task. There is one big mistake in C++20: they added too many 
demanding features in one release. It will take years for 
developers to figure out how to make the best use of coroutines 
and concepts. C++ need to slow down a bit, they shouldn't add 
stuff faster than programmers can establish best practices, the 
result will be chaos.
Oct 12 2022
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Wednesday, 12 October 2022 at 12:55:25 UTC, Ola Fosheim 
Grøstad wrote:

 On Wednesday, 12 October 2022 at 12:24:05 UTC, Paulo Pinto 
 wrote:

 C++ ruled the GUI frameworks tooling during the 1990's, with 
 C++ frameworks being shipped with every compiler, nowadays 
 with exception of Microsoft, there isn't an OS vendor left 
 shipping a C++ GUI framework with the platform SDK. Qt seems 
 to be the last man standing, and even them, had to turn into 
 enterprise customers to keep their developers going.


 Computers get more memory, cores, GPUs and scripting languages 
 with JITs. For most applications it would make more sense to 
 use a JIT for the GUI. Not surprising that the application area 
 shift over time.


That's BS, and i am glad you are not the one responsible of 
making the iPhone i use

Look at Android, you need 2x the amount of power and ram than an 
iPhone for similar workloads

Nobody use computers anymore, except some nerds like us

People use resource constrained devices that runs with a battery

JIT is forbidden in games because it introduce stutters

It is forbidden in iOS because it drains the battery and it is a 
security nightmare

And as the games becomes more resource intensive and the gameplay 
loop shorter and shorter due to the popularity of high refresh 
rate screens, nobody will want a language that's slow with a JIT 
and a poor man's GC

The GC is debatable as we get more cores we can offload the GC 
work, but GC's like one D has is a handicap nobody wants, both 
Unity/Unreal offer a concurrent/generational one

It's no wonder D fails to grow, wrong analysis and wrong 
expectations

What the new popular languages promote? and why they gain 
popularity?

Why people want to comeup with BetterC++ and not use what's 
already available

If we keep being delusional, we'll loose everything, and we'll 
die due to demography, who's gonna left to keep make the D?


lua, python, swift, nim, pascal all at once, what people say 
about this kind of thing? "Jack of all trades, master of none"?
Oct 12 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 12 October 2022 at 15:21:07 UTC, ryuukk_ wrote:

 That's BS, and i am glad you are not the one responsible of 
 making the iPhone i use


No need to get personal. Paulo stated a fact, C++ was more 
central to GUI development in the 90s than today. I stated a 
fact, more UIs are done using higher level approaches as current 
hardware ha substantial more resources than in the 90s. That is 
true for mobiles too. Many mobile apps on iPhone use Dart or 
JavaScript, so it is clearly present.


 refresh rate screens, nobody will want a language that's slow 
 with a JIT and a poor man's GC


Dart.
JavaScript.
Oct 12 2022
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Wednesday, 12 October 2022 at 15:48:34 UTC, Ola Fosheim 
Grøstad wrote:

 On Wednesday, 12 October 2022 at 15:21:07 UTC, ryuukk_ wrote:

 refresh rate screens, nobody will want a language that's slow 
 with a JIT and a poor man's GC


 Dart.
 JavaScript.


Is D a system language or it is a language to do websites?

Can D's GC compete with Javascript's V8 GC?

Dart uses AOT for release
Oct 12 2022
next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Wednesday, 12 October 2022 at 16:22:50 UTC, ryuukk_ wrote:

 Is D a system language or it is a language to do websites?


I primarily use D to do websites.
Oct 12 2022
parent Sergey <kornburn yandex.ru> writes:
On Wednesday, 12 October 2022 at 16:37:26 UTC, Adam D Ruppe wrote:

 On Wednesday, 12 October 2022 at 16:22:50 UTC, ryuukk_ wrote:

 Is D a system language or it is a language to do websites?


 I primarily use D to do websites.


As a front-end?
Oct 12 2022
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 12 October 2022 at 16:22:50 UTC, ryuukk_ wrote:

 Is D a system language or it is a language to do websites?

 Can D's GC compete with Javascript's V8 GC?


Now you confuse me. We were talking about why C++ is less needed 
in GUI development now in comparison to the 90s.

Javascript has been used for iPhone apps for at least a decade, 
in WebViews. Regular end users often didn't notice the difference 
as they were dressed up as native widgets and fine tuned. Or they 
used native widgets controlled by JavaScript.

JavaScript, Lua and other scripting languages have been used for 
GUIs of games, mobile apps and desktop apps even when the 
application engine is written in C++.

The ui-logic is often not very demanding. Which is why this 
approach makes sense.
Oct 12 2022
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Wednesday, 12 October 2022 at 16:50:36 UTC, Ola Fosheim 
Grøstad wrote:

 On Wednesday, 12 October 2022 at 16:22:50 UTC, ryuukk_ wrote:

 Is D a system language or it is a language to do websites?

 Can D's GC compete with Javascript's V8 GC?


 Now you confuse me. We were talking about why C++ is less 
 needed in GUI development now in comparison to the 90s.

 Javascript has been used for iPhone apps for at least a decade, 
 in WebViews. Regular end users often didn't notice the 
 difference as they were dressed up as native widgets and fine 
 tuned. Or they used native widgets controlled by JavaScript.

 JavaScript, Lua and other scripting languages have been used 
 for GUIs of games, mobile apps and desktop apps even when the 
 application engine is written in C++.

 The ui-logic is often not very demanding. Which is why this 
 approach makes sense.


The topic was why Apple ditch C++/LLVM and why it's being phased 
out as a language

Then you said some things about the future is JIT and GCs

Then i said, that's why D doesn't grow

You derailed, i tried to put topic on track

OP title is "Zig vs D generics", not GCs, JITs or C++

Otherwise we do Java and we don't need generics, or we do 
Javascript and dynamic and we don't need no struct
Oct 12 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 12 October 2022 at 17:19:57 UTC, ryuukk_ wrote:

 The topic was why Apple ditch C++/LLVM and why it's being 
 phased out as a language


This never happend. There is no point in propagating this 
assumption. Let's stick to the facts:

https://jobs.apple.com/en-us/details/200310241/c-compiler-engineer



 Then you said some things about the future is JIT and GCs


I said that for the UI, scripting languages with JITs are 
probably more suitable than C++ and similar languages. Which is a 
historical evolution that follows the development of hardware. 
This is just a reflection of reality. I am not talking about the 
future. I am talking about the past and the present. This is not 
a new trend.
Oct 12 2022
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Wednesday, 12 October 2022 at 17:36:55 UTC, Ola Fosheim 
Grøstad wrote:

 On Wednesday, 12 October 2022 at 17:19:57 UTC, ryuukk_ wrote:

 The topic was why Apple ditch C++/LLVM and why it's being 
 phased out as a language


 This never happend. There is no point in propagating this 
 assumption. Let's stick to the facts:

 https://jobs.apple.com/en-us/details/200310241/c-compiler-engineer



 Then you said some things about the future is JIT and GCs


 I said that for the UI, scripting languages with JITs are 
 probably more suitable than C++ and similar languages. Which is 
 a historical evolution that follows the development of 
 hardware. This is just a reflection of reality. I am not 
 talking about the future. I am talking about the past and the 
 present. This is not a new trend.


Apple went with Swift as an evolution to C++ and ObjC; no JIT and 
no GC and yet it powers SwiftUI, modern, easy to use and 
efficient declarative UI framework

They didn't lower their standard when they came up with something 
new, they stick to their motto

Where is async in D btw?
Oct 12 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 12 October 2022 at 17:59:37 UTC, ryuukk_ wrote:

 Apple went with Swift as an evolution to C++ and ObjC; no JIT 
 and no GC and yet it powers SwiftUI, modern, easy to use and 
 efficient declarative UI framework


This is getting very off topic. Apple has always had a lock-in 
strategy where they try to get developers to create "iOS only 
apps" and "iOS first apps". This is a political game, not a 
technical one. They did the same with the GPU API Metal.

You can control a 2D UI from a scripting language or from D, but 
there will be no noticeable performance difference on modern 
hardware. Both approaches are equally valid.
Oct 12 2022
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Wednesday, 12 October 2022 at 18:06:15 UTC, Ola Fosheim 
Grøstad wrote:

 On Wednesday, 12 October 2022 at 17:59:37 UTC, ryuukk_ wrote:

 Apple went with Swift as an evolution to C++ and ObjC; no JIT 
 and no GC and yet it powers SwiftUI, modern, easy to use and 
 efficient declarative UI framework


 This is getting very off topic. Apple has always had a lock-in 
 strategy where they try to get developers to create "iOS only 
 apps" and "iOS first apps". This is a political game, not a 
 technical one. They did the same with the GPU API Metal.



It has nothing to do with politics, it has to do with efficiency, 
apple was in the krhonos working groupd for vulkan, but they 
decided against it and went with their own due to specific needs


Instead they proposed WebGPU, common interface powered by native 
implementation for each OS, and that one is a huge success

https://architosh.com/2017/02/apples-webgpu-standard-proposal-aiming-at-common-access-to-explicit-graphics/
Oct 12 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 12 October 2022 at 18:24:39 UTC, ryuukk_ wrote:

 Instead they proposed WebGPU, common interface powered by 
 native implementation for each OS, and that one is a huge 
 success


An upcoming W3C standard for browsers. If you set the trajectory 
then you secure the position of your own product. You have to 
look at that in conjunction with WebGL2:

https://registry.khronos.org/webgl/specs/latest/2.0-compute/

This has no relevance for D though.
Oct 12 2022
parent Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 12 October 2022 at 18:58:51 UTC, Ola Fosheim 
Grøstad wrote:

 On Wednesday, 12 October 2022 at 18:24:39 UTC, ryuukk_ wrote:

 Instead they proposed WebGPU, common interface powered by 
 native implementation for each OS, and that one is a huge 
 success


 An upcoming W3C standard for browsers. If you set the 
 trajectory then you secure the position of your own product. 
 You have to look at that in conjunction with WebGL2:

 https://registry.khronos.org/webgl/specs/latest/2.0-compute/

 This has no relevance for D though.


WebGL 2.0 compute is dead.

Google killed it by asserting they would rather focus on WebGPU 
instead.

https://bugs.chromium.org/p/chromium/issues/detail?id=1131991
Oct 14 2022
prev sibling next sibling parent Kagamin <spam here.lot> writes:
On Wednesday, 12 October 2022 at 16:22:50 UTC, ryuukk_ wrote:

 Is D a system language or it is a language to do websites?

 Can D's GC compete with Javascript's V8 GC?


On one hand there's forum.dlang.org, which is written in D and is 
fast and lightweight, on the other hand I heard many complaints 
that twitter and reddit web clients are heavy. Which one is 
better?
Oct 14 2022
prev sibling parent wjoe <invalid example.com> writes:
On Wednesday, 12 October 2022 at 16:22:50 UTC, ryuukk_ wrote:

 On Wednesday, 12 October 2022 at 15:48:34 UTC, Ola Fosheim 
 Grøstad wrote:

 On Wednesday, 12 October 2022 at 15:21:07 UTC, ryuukk_ wrote:

 refresh rate screens, nobody will want a language that's slow 
 with a JIT and a poor man's GC


 Dart.
 JavaScript.


 Is D a system language or it is a language to do websites?

 Can D's GC compete with Javascript's V8 GC?


I haven't benchmarked but I would expect that the fork() based GC 
can compete since it pauses only for the duration of the fork() 
system call. Everything else can be done concurrently.
And, unlike MS Windows, Apple's iOS is based on Darwin (BSD) so I 
would assume that a fork() interface is present there, too.

For your convenience: 
https://dlang.org/blog/2019/07/22/symmetry-autumn-of-code-experience-report-porting-a-fork-based-gc/
Oct 14 2022
prev sibling parent reply IGotD- <nise nise.com> writes:
On Wednesday, 12 October 2022 at 11:27:26 UTC, Ola Fosheim 
Grøstad wrote:

 Swift is much higher level, although there has been some talk 
 of making it more capable for machine-level programming.


Swift is about just as high level as D, classes come with extra 
metadata both dynamic and static just like D. Managed pointers 
(reference types) are ARC so it should be better suited for 
embedded systems. Unlike D that has  system and unsafe blocks for 
Rust, for direct access to memory, Swift offers 
UnsafePointer/UnsafeMutablePointer, 
UnsafeBufferPointer/UnsafeMutableBufferPointer among others. 
Certainly an interesting approach, maybe that's the only thing 
that is needed. Swift does not have  safe/ trusted/ system for 
foreign functions, you just call them so maybe Walter was right 
after all.



 platform, you can basically always expect the support on 
 "foreign platforms" to be subpar and if it isn't you have to 
 plan for platforms being dropped in the future for 
 non-technical reasons.

 They may technically be cross platform, but they sure ain't 
 politically cross platform :-).


Maybe true but that applies for any platform/library. Just look 
what happened to Qt. In the case of Swift, yes the Linux/Windows 
implementations lag behind Apple.
Oct 12 2022
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 12 October 2022 at 12:41:44 UTC, IGotD- wrote:

 Certainly an interesting approach, maybe that's the only thing 
 that is needed. Swift does not have  safe/ trusted/ system for 
 foreign functions, you just call them so maybe Walter was right 
 after all.


It might be the only thing people need for writing regular apps 
with a bit of oomph here and there, but the people that use C for 
signal processing etc are less likely to look at Swift as a 
replacement.

D has some high level features too, but does not evolve in that 
direction? It is evolving in the direction of C, it seems.


 Maybe true but that applies for any platform/library. Just look 
 what happened to Qt. In the case of Swift, yes the 
 Linux/Windows implementations lag behind Apple.


Yes, the Qt case is interesting as it tells us that GPL isn't 
enough when you need a big budget to drive the evolution of a 
library.

So maybe the open source community should find some structural 
way to have many independent parts that interoperate. You 
basically need a set of open source protocol definitions, with 
language support, that people can attach their efforts to rather 
than being a tiny contributor to a gigantic structure.

The current open source community have these monoliths that are 
clogging up the pipelines when they become too large to change 
without a commercial entity behind it.

Some "distributed" innovation is certainly needed.
Oct 12 2022
prev sibling parent reply Tejas <notrealemail gmail.com> writes:
On Tuesday, 11 October 2022 at 15:56:11 UTC, Paulo Pinto wrote:

 On Tuesday, 11 October 2022 at 14:49:44 UTC, Tejas wrote:

 [...]


 clang is good enough for their purposes, Metal Shading Language 
 is a C++14 dialect, IO Kit uses a Embedded C++ dialect and 
 C++17 is good enough for DriverKit and is the current baseline 
 for LLVM contributions.

 [...]




But C++20 introduced modules, which will massively reduce build 
times

Is that feature alone not enough to get up to C++20? It's such a 
fundamental change
Oct 12 2022
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 12 October 2022 at 14:52:26 UTC, Tejas wrote:

 But C++20 introduced modules, which will massively reduce build 
 times

 Is that feature alone not enough to get up to C++20? It's such 
 a fundamental change


It might be, but I think only Microsoft has a complete 
implementation?

Regardless, C++20 "concepts" is basically syntax sugar, but it 
makes it so much less tedious to write generic code that it is a 
game changer in my view. If you want to write generic code that 
is (C++ code is often limited in terms of generic programming).

C++20 coroutines can potentially change the structuring of 
programs to such an extent at it might create "a new language" if 
used extensively, but I don't think many know how to make use of 
those yet, so the potential impact is difficult to judge.

Anyway, there is no shortage of new projects. Here is the number 
of new Github projects over the past two months:

language | number of new projects
----|-----
C++ | 133K
C    | 90K
Rust | 24K
Zig  |  0.4K
D    |  0.2K


Nearly an order of magnitude more new projects for C/C++ than 
Rust. Granted, getting within 10%, for Rust, is pretty impressive.

If we look at what the most starred new projects are used for we 
get:

* *C++*: wasm runtime, audible feedback app, a compiler-compiler, 
physics module, remote loader, database, firewall workaround,  etc

* *Rust*: tls, crypto-bot strategy, a javascript jit hack, drag 
and drop utility for GTK, sqlite filesystem, postgressql monitor, 
crypto currency tool, package manager improvement, text based ui 
library

* *Zig*: parsing project, bindings for opencv, ssl for wasm, 
webgpu library, validation library, protobuf library, binding for 
tensorflow, midi synth, coff file dump

* *D*: ui library, xml dom library, library for interfacing with 
xdg, cell-based text interface, a D library, config file library, 
math library, D sorting tool, pack/unpack tool, gameboy emulator 
(work in progress)


So there is a notable difference in what kind of projects we get 
as the most popular ones. If we compare Rust with C++ we see that 
the Rust ones are more geared towards tooling, crypto etc. I 
didn't go beyond the first page, though.

If we look at Zig then we see that it is mostly about building up 
the Zig eco system. For D we also get some of the same, basically 
libraries.

The volumes for Zig and D are low, so the results could be more 
random than the ones for Rust.
Oct 12 2022
prev sibling parent reply Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Monday, 10 October 2022 at 14:18:52 UTC, Paulo Pinto wrote:

 I guess you did something wrong, :)
 ```cpp
 #include <string>
 #include <iostream>

 constexpr std::string hello() {
     return std::string("hello world");
 }

 int main() {
     static constexpr auto greeting = hello();

     std::cout << greeting << std::endl;
 }
 ```


This only works because you initialize the `std::string` with a 
literal. It fails on this:
```cpp
      return std::string("hello ") + "world";
```
Oct 10 2022
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 10 October 2022 at 16:59:56 UTC, Quirin Schroll wrote:

 On Monday, 10 October 2022 at 14:18:52 UTC, Paulo Pinto wrote:

 I guess you did something wrong, :)
 ```cpp
 #include <string>
 #include <iostream>

 constexpr std::string hello() {
     return std::string("hello world");
 }

 int main() {
     static constexpr auto greeting = hello();

     std::cout << greeting << std::endl;
 }
 ```


 This only works because you initialize the `std::string` with a 
 literal. It fails on this:
 ```cpp
      return std::string("hello ") + "world";
 ```


Because that was what I was replying to in first place.

As for your example, I have to cross check it on VC++ 2022 latest 
and its current support for upcoming ISO C++23, and what ISO says 
about it.
Oct 10 2022
parent Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 10 October 2022 at 18:23:42 UTC, Paulo Pinto wrote:

 On Monday, 10 October 2022 at 16:59:56 UTC, Quirin Schroll 
 wrote:

 On Monday, 10 October 2022 at 14:18:52 UTC, Paulo Pinto wrote:

 I guess you did something wrong, :)
 ```cpp
 #include <string>
 #include <iostream>

 constexpr std::string hello() {
     return std::string("hello world");
 }

 int main() {
     static constexpr auto greeting = hello();

     std::cout << greeting << std::endl;
 }
 ```


 This only works because you initialize the `std::string` with 
 a literal. It fails on this:
 ```cpp
      return std::string("hello ") + "world";
 ```


 Because that was what I was replying to in first place.

 As for your example, I have to cross check it on VC++ 2022 
 latest and its current support for upcoming ISO C++23, and what 
 ISO says about it.


And the conclusion is, when using C++ latest compliance to C++23, 
VC++ 2022 19.33 complains about it, while VC++ 2022 latest is 
more than happy to handle it,

VS 2022 19.33 => https://godbolt.org/z/ofes3a78z

VS 2022 latest => https://godbolt.org/z/v1Y8Ec65W

In C++23 most string related operations are now constexpr.

https://eel.is/c++draft/string.classes
Oct 11 2022
prev sibling parent German Diago <german.diago cppmaster.net> writes:
On Monday, 10 October 2022 at 07:30:38 UTC, Kagamin wrote:

In contrast, C++ code attempting to call non-constexpr 
functions (i.e. functions only accessible at run time) in a 
constexpr context (i.e. functions which are available both at 
compile time and run time) will give an error at the call site.


 Eh? So can C++ support an allocator that works both at compile 
 time and at run time? I use such allocator in my D code so it's 
 ctfeable.


Yes, it does, but it has limits 
https://www.cppstories.com/2021/constexpr-new-cpp20/

As for the comment about C++ code attemping to call non-constexpr 
functions. Careful with not marking functions constexpr. I used 
to think it was a hell of thing. But if you think of it, 
constexpr is part of the user contract. You could make a function 
non-ctfe by accident in D and break user code. C++ is explicit 
about it.
Oct 11 2022