7 ms·

If you were trying to build the world's next major operating system, would you go with Clojure as one of the core languages, specifically the one that developer

If you were trying to build the world's next major operating system, would you go with Clojure as one of the core languages, specifically the one that developer-created apps are written in? And could Clojure be fast enough to power the actual OS itself too? With all the new excitement around Clojure, I'm just trying to understand the theoretical and practical limits of the language.

runevault 14y ago
Personally not sure I would try an OS until Clojure has a compile to target like C, unless you'd try writing an OS in Java.
- ConstantineXVI 14y ago
  There is this[0] that gets Clojure[Script] to C via Gambit Scheme, still doesn't seem like something to build an OS on top of. [0] https://github.com/takeoutweight/clojure-scheme https://github.com/takeoutweight/clojure-scheme
praptak 14y ago
> would you go with Clojure as one of the core languages, specifically the one that developer-created apps are written in? Only after detaching it from the JVM. Forcing all apps to run on JVM would obviously be too limiting. > And could Clojure be fast enough to power the actual OS itself too? It is definitely possible to get C-grade control over machine code with a Lisp, as evidenced by GOAL/GOOL. Not sure though if it is worth it.
- masklinn 14y ago
  > It is definitely possible to get C-grade control over machine code with a Lisp Well you could also have machine code be a lisp (as did many lisp machines, which used lisps from the microcode up).
  - DeepDuh 14y ago
    While it's an interesting idea, you would need one or even two of the big three players (MS, Apple, Google) to push this onto the market, otherwise you'd have a complete driver desert. I'd go one level above: make a HIL bridge between standard x86 drivers and your lisp machine code.
monkeyfacebag 14y ago
Well, it's hosted on the JVM, so, no, it probably would not be a good language to write an operating system in. That said, Clojure is quite fast compared to Python, Ruby et al, but this is primarily a side effect of running on the JVM. FWIW, Java is even faster.
dons 14y ago
It would be a controversial step to write an OS without a type system.
- aphyr 14y ago
  Luckily, Clojure has a type system. Actually, several of them, which work together: http://clojure.org/protocols http://clojure.org/protocols http://clojure.org/datatypes http://clojure.org/datatypes http://clojure.org/multimethods http://clojure.org/multimethods http://clojure.org/java_interop#Java%20Interop-Type%20Hints http://clojure.org/java_interop#Java%20Interop-Type%20Hints
  - cynicalkane 14y ago
    I think the GP is talking about something like C, which has a static type system at compile time. But at runtime, it's all ones and zeroes. In Clojure a symbol is a symbol and the (strong) types of the objects they point to are resolved at runtime. So Clojure's type system is, in a precise sense, the opposite of what the GP was talking about!
    - aphyr 14y ago
      It depends, really. Clojure's compiler actually does perform static, compile-time type analysis in certain cases, notably on primitives. For a more traditional form of static type analysis, I imagine you'd use the macro system to provide something like http://en.wikipedia.org/wiki/Qi_(programming_language)#Type_checking http://en.wikipedia.org/wiki/Qi_(programming_language)#Type_... That said, I'm personally of the opinion that compile-time static type verification isn't quite as powerful as is oft conjectured, in terms of safety and performance. Sufficiently expressive type systems pay some of the same costs as run-time verified types in terms of indirection, and in practice the difference rarely seems significant. To be more explicit: I assert that C (and, for that matter, Java) do not have strong type systems, in the sense of power, not rigidity. There are huge classes of bugs in kernel code that could be caught by static type verification and can't, because the C type system simply isn't powerful enough to express the invariants required. Yet, somehow, people write successful operating systems in C, and they work not because of the type system but because of careful thought and thorough testing. Even more to the point: We have written operating systems in dynamically-typed Lisp before, even down to the microcode level. The Symbolics Lisp machines should illustrate that it is perfectly possible to do what the parent asserts is infeasible. All this said, I certainly wouldn't write an OS in Clojure; though I love the language, the JVM just wouldn't be an appropriate substrate. The instant someone announces an LLVM Clojure compiler, though... ;-)
Cosman246 14y ago
Much of the excitement around Clojure seems rather buzzwordy. You should check out some of its criticism, such as http://jng.imagine27.com/index.php/2009-08-19-011225_clojure_the_false_lisp.html http://jng.imagine27.com/index.php/2009-08-19-011225_clojure... and http://www.loper-os.org/?p=42 http://www.loper-os.org/?p=42
- gauravk92 14y ago
  These language enthusiasts forget that the best language is the best one for the task at hand. They'll get it eventually IMHO.
- dkersten 14y ago
  The loper os guy hates all languages that aren't the Symbolics flavour of common lisp and all systems that aren't Symbolics' Genera. His criticism of clojure is based only on those two facts and not on actual real problems or gripes with the language. He doesn't back up any claims and seems to hate clojure because its not Symbolics lisp. If I hate all food but pancakes, then my opinion on steak is hardly relevant.
  - asciilifeform 14y ago
    Author of linked article speaking. I dislike Clojure because it is a cheap knock-off of Common Lisp, with no upsides that I'm aware of - besides trendiness. The article mentions one serious flaw - Clojure barfs Java stack traces, instead of serious debug information (the way Common Lisp does - with restarts, etc.) Another flaw is the lack of reader macros. But what is the point of listing said flaws? I could go on and on, and no one will care a whit. Why? Because Clojure is a product of immature minds who piss on the past work of serious people (the Common Lisp community) simply for the sake of faux-novelty. In this, it resembles Newlisp and other backwards steps disguised as progress. It is, in fact, best understood as yet another product of the idiotic language-of-the-day mentality which gave us Dylan, Python, Ruby, and the many other shoddy "infix Lisps." > hates all languages that aren't the Symbolics flavour of common lisp This is patently untrue, as anyone who actually bothers to read my articles knows well. Symbolics (or rather, the MIT Lisp machine architecture their products were based on) was simply an example of a Lisp system done well. Clojure, a thin veneer on the Java cesspool, is not. To run with your analogy, I am a lover of steak, who is upset by tofu peddlers' success in passing off their cheap trash as real meat.
dmpk2k 14y ago
Clojure's memory consumption is extreme, which excludes it from many realms of software development. It's primarily useful for sovereign applications (e.g. precludes utilities) which do not require high memory density (e.g. precludes databases). I'm quite fond of Clojure's model, but some tradeoffs had to be made.
- canttestthis 14y ago
  > Clojure's memory consumption is extreme, which excludes it from many realms of software development. Is this solely because it runs on the JVM? Because per the alioth comparison tests, Java 7 uses much less memory than Clojure too.
  - tibbe 14y ago
    Dynamic languages typically also have to pay a price for carrying around type tags and having everything be heap allocated.
    - rabidsnail 14y ago
      Those costs are the same as Java's in Clojure's case.
fshen 14y ago
Why write an OS with clojure. It's not designed to do that. Clojure is better suited to write application, low level system software does not fit.

runevault 14y ago

Personally not sure I would try an OS until Clojure has a compile to target like C, unless you'd try writing an OS in Java.

ConstantineXVI 14y ago
There is this[0] that gets Clojure[Script] to C via Gambit Scheme, still doesn't seem like something to build an OS on top of. [0] https://github.com/takeoutweight/clojure-scheme https://github.com/takeoutweight/clojure-scheme

praptak 14y ago

> would you go with Clojure as one of the core languages, specifically the one that developer-created apps are written in? Only after detaching it from the JVM. Forcing all apps to run on JVM would obviously be too limiting. > And could Clojure be fast enough to power the actual OS itself too? It is definitely possible to get C-grade control over machine code with a Lisp, as evidenced by GOAL/GOOL. Not sure though if it is worth it.

masklinn 14y ago
> It is definitely possible to get C-grade control over machine code with a Lisp Well you could also have machine code be a lisp (as did many lisp machines, which used lisps from the microcode up).
- DeepDuh 14y ago
  While it's an interesting idea, you would need one or even two of the big three players (MS, Apple, Google) to push this onto the market, otherwise you'd have a complete driver desert. I'd go one level above: make a HIL bridge between standard x86 drivers and your lisp machine code.

monkeyfacebag 14y ago

Well, it's hosted on the JVM, so, no, it probably would not be a good language to write an operating system in. That said, Clojure is quite fast compared to Python, Ruby et al, but this is primarily a side effect of running on the JVM. FWIW, Java is even faster.

dons 14y ago

It would be a controversial step to write an OS without a type system.

aphyr 14y ago
Luckily, Clojure has a type system. Actually, several of them, which work together: http://clojure.org/protocols http://clojure.org/protocols http://clojure.org/datatypes http://clojure.org/datatypes http://clojure.org/multimethods http://clojure.org/multimethods http://clojure.org/java_interop#Java%20Interop-Type%20Hints http://clojure.org/java_interop#Java%20Interop-Type%20Hints
- cynicalkane 14y ago
  I think the GP is talking about something like C, which has a static type system at compile time. But at runtime, it's all ones and zeroes. In Clojure a symbol is a symbol and the (strong) types of the objects they point to are resolved at runtime. So Clojure's type system is, in a precise sense, the opposite of what the GP was talking about!
  - aphyr 14y ago
    It depends, really. Clojure's compiler actually does perform static, compile-time type analysis in certain cases, notably on primitives. For a more traditional form of static type analysis, I imagine you'd use the macro system to provide something like http://en.wikipedia.org/wiki/Qi_(programming_language)#Type_checking http://en.wikipedia.org/wiki/Qi_(programming_language)#Type_... That said, I'm personally of the opinion that compile-time static type verification isn't quite as powerful as is oft conjectured, in terms of safety and performance. Sufficiently expressive type systems pay some of the same costs as run-time verified types in terms of indirection, and in practice the difference rarely seems significant. To be more explicit: I assert that C (and, for that matter, Java) do not have strong type systems, in the sense of power, not rigidity. There are huge classes of bugs in kernel code that could be caught by static type verification and can't, because the C type system simply isn't powerful enough to express the invariants required. Yet, somehow, people write successful operating systems in C, and they work not because of the type system but because of careful thought and thorough testing. Even more to the point: We have written operating systems in dynamically-typed Lisp before, even down to the microcode level. The Symbolics Lisp machines should illustrate that it is perfectly possible to do what the parent asserts is infeasible. All this said, I certainly wouldn't write an OS in Clojure; though I love the language, the JVM just wouldn't be an appropriate substrate. The instant someone announces an LLVM Clojure compiler, though... ;-)

Cosman246 14y ago

Much of the excitement around Clojure seems rather buzzwordy. You should check out some of its criticism, such as http://jng.imagine27.com/index.php/2009-08-19-011225_clojure_the_false_lisp.html http://jng.imagine27.com/index.php/2009-08-19-011225_clojure... and http://www.loper-os.org/?p=42 http://www.loper-os.org/?p=42

gauravk92 14y ago
These language enthusiasts forget that the best language is the best one for the task at hand. They'll get it eventually IMHO.
dkersten 14y ago
The loper os guy hates all languages that aren't the Symbolics flavour of common lisp and all systems that aren't Symbolics' Genera. His criticism of clojure is based only on those two facts and not on actual real problems or gripes with the language. He doesn't back up any claims and seems to hate clojure because its not Symbolics lisp. If I hate all food but pancakes, then my opinion on steak is hardly relevant.
- asciilifeform 14y ago
  Author of linked article speaking. I dislike Clojure because it is a cheap knock-off of Common Lisp, with no upsides that I'm aware of - besides trendiness. The article mentions one serious flaw - Clojure barfs Java stack traces, instead of serious debug information (the way Common Lisp does - with restarts, etc.) Another flaw is the lack of reader macros. But what is the point of listing said flaws? I could go on and on, and no one will care a whit. Why? Because Clojure is a product of immature minds who piss on the past work of serious people (the Common Lisp community) simply for the sake of faux-novelty. In this, it resembles Newlisp and other backwards steps disguised as progress. It is, in fact, best understood as yet another product of the idiotic language-of-the-day mentality which gave us Dylan, Python, Ruby, and the many other shoddy "infix Lisps." > hates all languages that aren't the Symbolics flavour of common lisp This is patently untrue, as anyone who actually bothers to read my articles knows well. Symbolics (or rather, the MIT Lisp machine architecture their products were based on) was simply an example of a Lisp system done well. Clojure, a thin veneer on the Java cesspool, is not. To run with your analogy, I am a lover of steak, who is upset by tofu peddlers' success in passing off their cheap trash as real meat.

dmpk2k 14y ago

Clojure's memory consumption is extreme, which excludes it from many realms of software development. It's primarily useful for sovereign applications (e.g. precludes utilities) which do not require high memory density (e.g. precludes databases). I'm quite fond of Clojure's model, but some tradeoffs had to be made.

canttestthis 14y ago
> Clojure's memory consumption is extreme, which excludes it from many realms of software development. Is this solely because it runs on the JVM? Because per the alioth comparison tests, Java 7 uses much less memory than Clojure too.
- tibbe 14y ago
  Dynamic languages typically also have to pay a price for carrying around type tags and having everything be heap allocated.
  - rabidsnail 14y ago
    Those costs are the same as Java's in Clojure's case.

fshen 14y ago

Why write an OS with clojure. It's not designed to do that. Clojure is better suited to write application, low level system software does not fit.