Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> move this memory around

A lot of people seem to assume that Chris (the author) was talking about managed memory, which he never mentioned once. Managed memory is runtime safety, a type system is compile-time safety. He's complaining about the type system. As an example:

> address memory as a flat range of bytes [...] I can then typecast into byte-aligned structs

You should never have to do that. You shouldn't be able to do that. Your job should be far simpler. Look at unique_ptr: a whole class of bugs are eliminated by this ZERO cost abstraction. Possibly what Chris is advocating is being able to describe what an I/O port is to the compiler and then using that abstraction to write your SCSI driver. This intent should be compiled down to as-good machine code (if not better) than what your C compiler would have given you - in the same way that unique_ptr is compiled.

I don't think any existing language gets this right.



> You should never have to do that. You shouldn't be able to do that.

Someone, at somepoint, has to do this though. Custom memory allocators are more or less predicated on having a byte buffer you chop up and use like this.

I think the best we get -- especially in driver code -- is well thought out design that have low cost abstractions between the device details and the application logic. But that seems like a library detail more than a compiler or language one.


> I don't think any existing language gets this right.

Which is precisely the reason C is still used.

Until we have a language that produces at least as good results as C and is safer we're not going to see any change in this area.


Agreed. I was pointing out that my interpretation of the email was a hypothetical tone, instead of a factual tone. As far as I'm concerned C isn't good enough, but I generally keep my mouth shut about it because I can't offer anything constructive to the discussion: I don't know what a "good C" would look like.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: