Hacker News Reader

Hacker News

Comment by pjmlp | Hacker News Reader

Parent Full thread

pjmlp

C doesn't tick any box regarding:

- vector execution units

- out of order execution

- delay slots

- L1 and L2 explicit cache access

- MMU access

- register windows

- gpgpu

All of that is given access by Assembly opcodes, not C specific language features.

And if you going to refer to language extensions to ISO C for writing inline Assembly, or compiler intrinsics, well the first OS written only in high level language with compiler intrinsics was done 10 years before C existed and is still being sold by Unisys.

The only thing that C has going for it are religious embedded devs that won't touch anything else other than C89 (yep not even C99), or FOSS UNIX clones.

And yeah, thanks to those folks, the Linux Kernel Security summit will have plenty of material for future conferences.

View on HN

Which modern, portable language gives you direct control over the MMU, out of order execution, delay slots and explicit cache access, other than hardware specific assembler? None that I know of can do this in a hardware agnostic way. Do tell.

I clearly mentioned that assembler was required for much of this, where components aren't programmed by MMIO. This would be the same regardless of whether you used Rust, Go, or FORTRAN77 to write your kernel.

I'm not even going to bother with your security comments, we all agree by now. There are plenty of people using C99 in embedded at least in userspace, even the Linux kernel uses some C99 extensions (eg. --std=gnu89 with gcc), and those FOSS UNIX clones have taken over the planet at this point in terms of smartphone adoption, data center servers etc. Despite the obvious flaws, this is still a better world to live in than Microsoft's proposed monoculture of the 1990's.

None, including C, which makes it nothing special. Any compiled language can call into Assembly.

The phones I know as having taken over the world run on C++, Objective-C, Swift, Java, with very little C still left around, and with its area being reduced with each OS release.

As for data centers, there is a certain irony that on Azure those FOSS run on top of Hyper-V, written in C++, on Google Cloud run on top of gVisor written in Go, on Amazon on top of Firecracker written in Rust, and on ChromeOS containers written in a mix of Go/Rust.

> Any compiled language can call into Assembly.

So ... you're repeating what I already said.

Android -> Linux -> mostly C, and assembly

IOS -> Darwin -> XNU -> C/C++, and assembly

Hyper-V runs as a Windows Server role. Windows kernel is C, and assembly

gVisor runs on Linux -> C, assembly

Firecracker runs on KVM, which runs on Linux -> C, assembly

In every single thing you have listed, the closest thing to the "bare metal" is C, and assembly. THAT's what makes C special. Its level of adoption, ubiquity and accessibility. Not its spectacular lack of security risks.

Anyway, you have come a very long way from where the parent poster started which was:

  Most of the stuff people think of as being the "metal" in 
  C are, in many cases, virtual abstractions created by the 
  operating system.

To which I merely pointed out, on the other side of the interface layer is, most commonly C. And assembly.

Operating Systems design has to and is obviously evolving away from this. I disagree that we have reached "peak C" and that is going to decline before it gets bigger.

Unfortunately pjmlp many of the conversations we have start this way, and devolve into this. I don't think I'm going to bother again. I think one (or both) of us will just have to agree to disagree. Have a nice day.

> None, including C, which makes it nothing special. Any compiled language can call into Assembly.

I wish you joy and entertainment interfacing your managed data structures with assembly code.

Yesterday I was forced to look into COM for the first time. There was some kind of callback that I was interested in, and it had basically two arrays as arguments, only in a super abstract from. I'm not lying, it was 30 lines of code before the function could actually access the elements in the arrays (with special "safe" function calls to get/set data).

Of course, that stupid callback had to be wrapped as a method in a class, and had to be statically declared as a callback with a special macro that does member pointer hackery, and that has to be wrapped in some more BEGIN_MAP/END_MAP (or so) macros. Oh yeah, and don't forget to list these declarations in the right order.

Thanks, but that's not why I wanted to become a programmer.

I have done it multiple times in the past calling Assembly via JNI, from Oberon, from Turbo Basic, from Turbo Pascal, from Delphi, from .NET.

C is not a special snowflake.

> And yeah, thanks to those folks, the Linux Kernel Security summit will have plenty of material for future conferences.

In the meantime, did you find a memory leak in my code? https://news.ycombinator.com/item?id=21275440

Not that I want to vehemently disagree with your security statements, but I think I'd love to have a little bit more "show" and less "tell". That also applies to showing practicality of managed languages, practicality of 90's business software development (C++/COM), practicality of dead commercial languages (Delphi + VCL).

Giving just endless lists of ancient buzzwords doesn't help.

It is coming for sure, I have not forgoten about it, I just have a private life to take care of, you know?

Regarding show, don't tell.

The 21st century React Native for Windows is written on top of COM/C++,

https://github.com/microsoft/react-native-windows

https://www.youtube.com/watch?v=IUMWFExtDSg

We are having a Delphi conference in upcoming weeks, https://entwickler-konferenz.de/, and it gets regularly featured on the German press, https://www.dotnetpro.de/delphi-959606.html.

> It is coming for sure, I have not forgoten about it, I just have a private life to take care of, you know?

I was thinking you'd look at it before writing your next 25 comments, but it seems I was wrong. So I'll just wait, it's fine.

> The 21st century React Native for Windows is written on top of COM/C++

From a skim I could find exactly zero mentions of COM/C++ stuff in there. Sure, this RN might sit on a pile of stuff that has COM buried underneath. That doesn't mean that COM is a necessity to do this React stuff, and not even that it's a good design from a developer's perspective.

You give zero ideas what's a good idea about COM. Just buzzwords and links to stuff and more stuff, with no relation obvious to me.

If you actually have to go through the whole COM boilerplate and the abominations to build a project with COM, just to connect to a service, because some people thought it wasn't necessary to provide a simple API (connect()/disconnect()/read_next_event()) then the whole thing isn't so funny anymore.

ReactNative for Windows uses WinUI and XAML Islands, which is UWP, aka COM.

I really don't know what kind of COM you have been writing, because COM from VCL, MFC, ATL, UWP, Delphi, .NET surely doesn't fulfill that description.

As for what COM is good for,

"Component Software: Beyond Object-Oriented Programming"

https://www.amazon.com/Component-Software-Object-Oriented-Pr...

Maybe I was unclear, but it was a C++ program (dealing with macros, as I said - VARIANTS and DISP_IDs and PROPERTIES and stuff). No joy to use.

As for other languages, I haven't touched COM at all but the idea of making GUIDs for stuff and registering components in the operating system doesn't seem a good default approach to me. Pretty sure it's more reliable to link object files together by default, so you can control and change what you get without the bureaucracy of versioning, etc.

> ReactNative for Windows uses WinUI and XAML Islands, which is UWP, aka COM.

Is the fact that COM is buried under this pile more than an unfortunate implementation detail?

Reply on news.ycombinator.com