Live data from Hacker News

Goodbye C++, Hello C

momentsingraphics.de

131–140 of 222 posts

Re: Goodbye C++, Hello C

#131
post #71

Earlier quoted context omitted.

Safety is complete orthogonal to being a bare-metal language (See Rust). You can have a completely locked down platform with an unsafe language (See iOS). I'd argue that anyone who thinks language safety is some authoritarian handcuff doesn't really understand low-level programming to begin with.

I actually think safety should be guaranteed at an OS/hardware level and not at a software level. If it's guaranteed that my process can only make a mess inside it's own memory allocations, let the software be as unsafe as it wants.

Then you'll be happy to learn that what you propose has been the case for consumer computers since protected mode was added to Intel 80286 processors in 1982.

I think few people in this discussion are worrying about programs directly affecting other programs through memory unsafety, exactly because this doesn't really happen for software that isn't a driver or inside the OS kernel. The problem with memory unsafety is that it often allows exploits that corrupt or steal user data, or gain unauthorized access to a system. That's not a problem when you are the only user of your software and you only have access to your own data, but once you have other peoples data or run on other peoples system I think you should at least consider the advantages of using a safe(r) language.

Re: Goodbye C++, Hello C

#132

Earlier quoted context omitted.

> I've seen slow compiling code with hundreds of identically named functions. I sometimes think I've seen everything programmers do, and then something like this pops up. > You can make your C++ code compile fast by simply not using slow paths through the compiler. D is fast to compile because it sidesteps or redesigns features that make for slow compilation.

D is horribly slow to compile template-heavy code for exactly the same reasons as c++. And it encourages lots of monomorphization in e.g. ranges. The enhanced introspection and reflection (and CTFE) capabilities coupled with mixins also encourage code that is very slow to compile.

As opposed to encouraging manually written code which is also not free to compile but has the added benefit of potentially introducing bugs?

Re: Goodbye C++, Hello C

#133
post #49

Earlier quoted context omitted.

> the general trend of nudging, cajoling more and more coders into using managed, very high level, safe languages and runtimes This is a good thing: these languages and runtimes are indeed much safer, and also much more productive than C. You can even still get the same amount of low-level control with Rust. > in general discouraging peeking under the hood, at the hardware level, as something raw, wild or unsafe. C i…

Lunacy. What is the evidence for this? Look at all the locked-down walled-garden platforms proliferating, and this famously prescient story: https://www.gnu.org/philosophy/right-to-read.en.html 20 years ago, many people thought RMS was a completely insane lunatic. Yet now he seems more like a prophet. It's not hard to see where things are going if you read between the lines. Increasingly, "safety and security" is bei…

20 years ago many people earned a living selling commercial compilers, and the PC was the exception to vertical integration.

Plenty of people knew what RMS was talking about.

But GPL was very bad for business, said those there were against it, so the new world of shareware and public domain is here again.

Re: Goodbye C++, Hello C

#134

Yesterday I finished a complex library in C++20, which I wrote "Rust style" by following the ISO C++ guidelines. I used 0 `new`, no smart pointers, all by-value returns, move semantics and STL containers. It literally took a month to write, but it worked as expected at the second attempt (first failed due to forgetting a `}` in a format string). I did not see a single segmentation fault and it works fine on both Linu…

Would you mind sharing a link to the ISO C++ guidelines you mention?

Re: Goodbye C++, Hello C

#135

Yesterday I finished a complex library in C++20, which I wrote "Rust style" by following the ISO C++ guidelines. I used 0 `new`, no smart pointers, all by-value returns, move semantics and STL containers. It literally took a month to write, but it worked as expected at the second attempt (first failed due to forgetting a `}` in a format string). I did not see a single segmentation fault and it works fine on both Linu…

Would you mind sharing a link to the ISO C++ guidelines you mention?

presumably https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

Re: Goodbye C++, Hello C

#136
post #103
post #15

If you really like the simplicity of C I highly recommend Nim: * Compiles to C, so you stand on the shoulders of giants wrt compilers. * Very low overhead GC that doesn't "stop the world". I was working on a project recently where I had to just write a bunch of stuff to disk, and I tried Node, and then Java, and they were about the same, and I figured - yep, makes sense, it's IO bound. Nim got twice the throughput w/…

Use mmap and you won't need to write anything to disk; the operating system will do it for you. That's C's killer feature while also being the last thing on earth languages like Node and Java would ever permit developers to do.

> while also being the last thing on earth languages like Node and Java would ever permit developers to do.

You sure about that?

https://www.npmjs.com/package/mmap-io

https://docs.oracle.com/en/java/javase/11/docs/api/java.base...

mmap is a system call, not some C-exclusive fancy feature. If your language can print something on the screen, there is no reason it can't mmap a file.

And if the serialization was the bottleneck, mmap would not have changed anything anyway.

Re: Goodbye C++, Hello C

#137

Earlier quoted context omitted.

Lunacy. What is the evidence for this? Look at all the locked-down walled-garden platforms proliferating, and this famously prescient story: https://www.gnu.org/philosophy/right-to-read.en.html 20 years ago, many people thought RMS was a completely insane lunatic. Yet now he seems more like a prophet. It's not hard to see where things are going if you read between the lines. Increasingly, "safety and security" is bei…

> Look at all the locked-down walled-garden platforms proliferating I don’t think I’m getting the connection here —- Rust was incubated at Mozilla and is now managed by its own open-source foundation. There’s nothing particularly closed or “walled garden” about it. By contrast, Apple’s ecosystem is the canonical example of a walled garden. But it’s overwhelmingly programmed in unsafe languages (C, C++, and Objective-…

Actually GNU project is one of the culprits for C spreading into a world of that was already moving into C++ and other safer languages.

> When you want to use a language that gets compiled and runs at high speed, the best language to use is C. C++ is ok too, but please don’t make heavy use of templates. So is Java, if you compile it.

https://www.gnu.org/prep/standards/html_node/Source-Language...

20 years ago, it was more like

> When you want to use a language that gets compiled and runs at high speed, the best language to use is C. Using another language is like using a non-standard feature: it will cause trouble for users. Even if GCC supports the other language, users may find it inconvenient to have to install the compiler for that other language in order to build your program. For example, if you write your program in C++, people will have to install the GNU C++ compiler in order to compile your program. > > C has one other advantage over C++ and other compiled languages: more people know C, so more people will find it easy to read and modify the program if it is written in C.

http://gnu.ist.utl.pt/prep/standards/html_node/Source-Langua...

Thank GNU for C.

Re: Goodbye C++, Hello C

#138
post #98

Earlier quoted context omitted.

> In early PC's, the way you ran software was to copy code from a magazine and compile and run it on your workstation. Being a PC user at all meant being a tinkerer/hacker a few decades ago. Bullshit. Except for the brief period of time when the Altair was the only thing going on in the Micro space… the Apple II, Atari 800, IBM PC and TRS-80 amongst others were marketed in the late 70s/early 80s with off the shelf, r…

The new windows does not even run on hardware which doesn't have TMP. You really don't see signs that computers are getting more closed?

PC was an accident caused by IBM's failure to put Compaq into line.

All other platforms were hardly any different from Apple, in fact Apple is just like they always have been

Re: Goodbye C++, Hello C

#139
post #76
post #49

Earlier quoted context omitted.

> the general trend of nudging, cajoling more and more coders into using managed, very high level, safe languages and runtimes This is a good thing: these languages and runtimes are indeed much safer, and also much more productive than C. You can even still get the same amount of low-level control with Rust. > in general discouraging peeking under the hood, at the hardware level, as something raw, wild or unsafe. C i…

This is a good thing: these languages and runtimes are indeed much safer, and also much more productive than C. You can even still get the same amount of low-level control with Rust. How do you bootstrap languages like Rust? Another 'safe' language? What about that one? Someone somewhere has to be working at the asm level.

Source code available,

http://www.projectoberon.com/

Re: Goodbye C++, Hello C

#140

Earlier quoted context omitted.

"I know my software just works" is really hubris. The fly-by-the-seat-of-our-pants game industry has cranked up programmers egos and made them ignore a wide range of tools and practices that have been proven time and time again to improve developer velocity and reduce defects.

"proven" sounds like cargo-culting dogma. The same was said of OOP in the 90s, and look what that caused. Hence my distrust of the snake-oil. Also, my real-world experience with wading through the abstraction insanity often seen in C++ (and justified because it's "safer") to find and fix bugs, and even more so with the sheer baroqueness of Enterprise Java (arguably an "even safer language"), shows that "reduce defect…

For the corpse it makes little difference how it got hit.
Post reply on HN