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

> But the point is that types don't belong that the OS level. You can have your type composition in user space, at the language level -- what's the problem with that?

I don't do kernel programming, so I don't care what kernels do internally. As an application programmer, I want usable APIs. I want an API that makes resource leaks inexpressible, that doesn't let me seek intrinsically sequential streams, etc. Of course, such an API can't possibly be a C API.

> Haskell and OCaml run on Unix just fine.

Haskell has an I/O model that's barely safer than C's. The only improvements are that the `Handle` type is abstract and the `bracket` function is a `try...finally` of sorts. OCaml fares even worse: Can I open a single file for both input and output with just the standard library? In either language, is there a comprehensive solution for manipulating memory-mapped files?

> It would be a mistake to bake types into the OS -- whatever that even means -- because nobody has found the perfect type system.

Making a usable interface to OS services doesn't require a “perfect” type system, just a type system that prevents the most common mistakes that happen when using OS services. OS services are to a large extent about manipulating resources, so substructural types can help a lot.



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

Search: