Cppfront : A new syntax for C++ (page 3)

September 19, 2022

Re: Cppfront : A new syntax for C++

Posted by Paulo Pinto
in reply to Ola Fosheim Grøstad

Permalink

Paulo Pinto

Posted in reply to Ola Fosheim Grøstad

Permalink

On Monday, 19 September 2022 at 06:44:05 UTC, Ola Fosheim Grøstad wrote:

On Sunday, 18 September 2022 at 15:16:20 UTC, IGotD- wrote:

Then I skimmed through Sutters CppFront presentation and quickly realized that it doesn't help much at all.

It is just an experiment in the initial stage, clearly quite personal at this point.

If he gets arenas right then that could be a significant improvement. Enough to get some adoption.

All this time spent on trying "fix" C++, think what you could have done with a new language or an existing sane one.

People create new languages all the time, most die off, stagnates and simply fail to reach critical mass.

What's good is that the world has moved on and there are plenty of alternatives and more a popping up all the time.

The alternatives are most likely competing with each other and to a lesser extent affecting C++ in the short term.

Many alternatives make it harder to build a competing eco-system. So it isn’t obvious that this is a disadvantage for C++. If there was a single strong contender for hardware-oriented programming then it might hurt C++, but right now there is none.

Other than C that is.

And eventually everyone sending patches to the Linux kernel, might as well brush up their Rust skills.

https://www.zdnet.com/article/linus-torvalds-rust-may-make-it-into-the-next-linux-kernel-after-all/

On 9/18/2022 1:47 AM, Paulo Pinto wrote: > Eventually using unsafe languages will require clearance from a cyber security government agency. This trend is why D is steadily moving towards 100% memory safety.

On 9/17/2022 4:32 PM, claptrap wrote: > Is DIP1000 the new Phobos vs Tango? I recently went through all the DIP1000 bugs in bugzilla. Many were pronounced in the n.g. as DIP1000 killers, but they have PRs now to fix them. DIP1000 is in good shape. > put everything else on the back burner for 10 years Ignoring everything else we've done.

On Monday, 19 September 2022 at 07:43:24 UTC, Paulo Pinto wrote:

Other than C that is.

Right, but CPU/SoC manufacturers have some interest in getting support for their hardware in LLVM/Clang or the GCC suite, so for the less esoteric devices C and C++ can be considered to be the same (same or similar compiler core, with some configuration differences).

And eventually everyone sending patches to the Linux kernel, might as well brush up their Rust skills.

Sure, but I perceive Rust as more of a high level approach with functional leanings, that also allows some low level programming. I guess one motivation for Carbon is to take that extra step towards a more hardware oriented vantage point with eco system backwards compatibility, in comparison with Rust. Still, it is not clear what Carbon will become like at this point and it seems to take in quite a bit of high level influence from Rust, ML and other such languages with a "high" abstraction level. I also am not sure if there is enough people with a focus on embedded and hardware that are engaging with the Carbon design process, which is a pity since the process is open for anyone to join.

Most system languages seem to suffer from not taking in the full use-case spectrum from the start. That appears to be an obstacle for most alternative system programming platforms, including D. It turns out that it is very difficult to change course later, as we can see with D and memory allocation (process, culture and design-dependencies appears to make late changes very difficult on a "social" level).

On Monday, 19 September 2022 at 09:03:42 UTC, Walter Bright wrote: > On 9/17/2022 4:32 PM, claptrap wrote: >> Is DIP1000 the new Phobos vs Tango? > > I recently went through all the DIP1000 bugs in bugzilla. Many were pronounced in the n.g. as DIP1000 killers, but they have PRs now to fix them. > > DIP1000 is in good shape. > > > put everything else on the back burner for 10 years > > Ignoring everything else we've done. Cool, please focus on getting Dip1000 finalized ❤️ D will prevail!

On 9/19/2022 2:30 AM, Dukc wrote: > I think you mean memory safe RAII and reference counting. DIP1000 enables limited forms of those, but in practice one still tends to be stuck mostly with the GC, static memory and the stack. @live, which deals with memory allocation, is the step after DIP1000.

Forums