While historically you've been a C and Assembly guy (and the odd shell scripting and such), what do you think of functional languages such as Lisp, Closure, Haskell, etc? Do you see any advantages to them, or do you view them as frivolous and impractical?
If you decide to do so, thanks for taking the time to answer my question! You're a legend at what you do, and I think it's awesome that the significantly less interesting me can ask you a question like this.
This is close enough to the question I had in mind that I've decided to comment on this thread instead. My question would have been phrased as: Do you ever see yourself wanting to do kernel programming in something other than C and assembly?
Particularly I'm wondering if he has any interest in Rust or Go, since they are actually targeting themselves at lower levels. I doubt he'd want to put Haskell in the kernel; whereas he might have different opinions about it outside that domain. Of course hopefully h
Linux can be ported anywhere, but the complexity increases if you include other languages as part of the kernel.
Linux is self-hosting in C. There is very little to do in the way of porting, relatively speaking. And by that I mean there is a lot, but you don't have to rewrite giant chunks of the thing.
Would you want to have to implement a minimal compiler for C, or minimal compilers for Rust/Go and C?
Or maybe you mean: Include a native back-end for gcc and let the front-end do the work? I can see value in
Me, personally? I wouldn't want to do anything you describe. I'm wagering Linus doesn't either. The question was if he was *interested* in these new languages. Laying that aside now, what you're describing might be easier with Clang. That leads (heheh) to another question, and a quick googling seems to indicate that the kernel can't be built with Clang yet...
"Particularly I'm wondering if he has any interest in Rust or Go, since they are actually targeting themselves at lower levels."
Context is a thing, and it should be understood. Having Rust or Go as an option in a distro is completely go-ahead (not for me, but for distro maintainers).
I understood the "lower levels" aspect to apply to 1) Linus as a programmer 2) Linus as a kernel maintainer 3) lower levels as kind of a thing where performance, binary compatibility perchance, and 3) fuck you
Rust can't be used to build a kernel because you can't handle OOM reliably.
From context I'm getting that's Out Of Memory. I don't know much about Rust; but what you're describing sounds more like a problem with the current implementation rather than the language itself... unless the developers painted themselves into a corner by specifying that allocation failure must panic and can't return something like a NULL.
If all else fails, immortality can always be assured by spectacular error.
-- John Kenneth Galbraith
Functional languages? (Score:5, Interesting)
While historically you've been a C and Assembly guy (and the odd shell scripting and such), what do you think of functional languages such as Lisp, Closure, Haskell, etc? Do you see any advantages to them, or do you view them as frivolous and impractical?
If you decide to do so, thanks for taking the time to answer my question! You're a legend at what you do, and I think it's awesome that the significantly less interesting me can ask you a question like this.
Re: (Score:2)
I'm surprised there are not more programming questions.
Q: Is sizeof() *really* a function?
Also, was defining tabs as 8 spaces just an attempt to drive adoption of widescreen monitor technology?
Re: (Score:3)
This is close enough to the question I had in mind that I've decided to comment on this thread instead. My question would have been phrased as: Do you ever see yourself wanting to do kernel programming in something other than C and assembly?
Particularly I'm wondering if he has any interest in Rust or Go, since they are actually targeting themselves at lower levels. I doubt he'd want to put Haskell in the kernel; whereas he might have different opinions about it outside that domain. Of course hopefully h
Re: (Score:2)
Linux can be ported anywhere, but the complexity increases if you include other languages as part of the kernel.
Linux is self-hosting in C. There is very little to do in the way of porting, relatively speaking. And by that I mean there is a lot, but you don't have to rewrite giant chunks of the thing.
Would you want to have to implement a minimal compiler for C, or minimal compilers for Rust/Go and C?
Or maybe you mean: Include a native back-end for gcc and let the front-end do the work? I can see value in
Re: (Score:1)
Me, personally? I wouldn't want to do anything you describe. I'm wagering Linus doesn't either. The question was if he was *interested* in these new languages. Laying that aside now, what you're describing might be easier with Clang. That leads (heheh) to another question, and a quick googling seems to indicate that the kernel can't be built with Clang yet...
Re: (Score:2)
"Particularly I'm wondering if he has any interest in Rust or Go, since they are actually targeting themselves at lower levels."
Context is a thing, and it should be understood. Having Rust or Go as an option in a distro is completely go-ahead (not for me, but for distro maintainers).
I understood the "lower levels" aspect to apply to 1) Linus as a programmer 2) Linus as a kernel maintainer 3) lower levels as kind of a thing where performance, binary compatibility perchance, and 3) fuck you
Re: (Score:2)
Rust can't be used to build a kernel because you can't handle OOM reliably.
From context I'm getting that's Out Of Memory. I don't know much about Rust; but what you're describing sounds more like a problem with the current implementation rather than the language itself... unless the developers painted themselves into a corner by specifying that allocation failure must panic and can't return something like a NULL.