If you could write an OS from scratch...

Okay, so most every OS out there is C-based.  If you could magically write a complete hardware-controlling OS all the way up to the UI and applications using a different language, which would you choose?

Though I like Lisp, I think I'd have to choose Erlang, maybe NewSqueak for embedded/smaller systems.

Well if it's all magically written for me, I see no reason not to do it in assembly.

Not written for you, I meant if you magically had the time and follow-through to do it all.

Java because the system would be crash proof

Python based so you could edit any aspect of the system super easy.

Haskell. I always wanted to use polyvariadic combinatory logic somewhere in an operating system.

Java is the obvious choice.

Befunge is the more amusing choice.

Ruby is the clear choice here.

One more vote for Erlang. Intel and friends have made it quite clear that many-core processors are on the way in the not-too-distant future (next Sunday AD), and it would be nice to have an OS designed for that future from the ground up.

Sing#

Please go search for other OSes and how they are implemented. LISP OS, done.
OCaml OS, done.
F# OS, done.
Haskell OS, probably done a few time.

The issue is the lack of adoption and lack of apps. So shut the fuck up, get your OS done and then make compatibility layers to let the unclean in.

>>12
my os is already done.
Mozilla/4.08 (Charon; Inferno)

Coco rocks

>>12
Links? Google gives:

OCaml OS - one single blurb (pointing to a dead page from 2005), saying it's "only a prototype"

F# OS - no hits about an OS

Haskell OS - "well, I got the boot floppy image going inside a VM, albeit briefly before the guest hung."  At least he's got something.

But, Mr. >>12 Faggot, my original post is clearly one of utopian fantasy, not an actual development effort so fuck you.

_{(and the issue is NOT "the lack of adoption and lack of apps", it's that the OSes you reference never got far past the drawing board)}

>>4
>>7
Would you put everything in the VM?  There'd be no way to kill or clean up processes!  And if there were multiple VMs, then it's not really a Java OS.

Lisp OS was definitely done (and is still used is a lesser form called emacs).

>>17
emacs isn't a hardware-controlling OS as OP specified, but yeah there were obviously LISP machines, which is why I suspect it wasn't listed in >>15 .

17 = 15 = samefag

Haskell OS - "well, I got the boot floppy image going inside a VM, albeit briefly before the guest hung."  At least he's got something.
how about just running hugs without an OS under it?
http://blog.closuretohome.com/2007/12/hugs-for-nintendo-ds.html

I'd write one in Visual BASIC .NET

So bye, bye Mr. Satori guy
Readin' SICP, writing sexps till the day that I die.
And world4ch /prog/ can't write Scheme code on the fly,
Satori's only for those who try, Satori's for those who try.

in b4 Anonix

Assembler. It's currently in the planning stages.

I'd study and follow the concept of a Lisp Machine, providing an OS that will be mostly written in a high-level dynamic language which you can stop, modify and understand anytime.

Just like Dennis Ritchie created his own programming language to write UNIX, I'd create my own programming language to create a more dynamic operating system.

My language would be based on Python, but contain no stupid statements, some quirks removed, tail-call elimination, functional parameters, and a new virtual machine which would have to be faster, GIL-less, and able to save state and reload them like many Lisps.

The OS would be clearly divided in four parts:
1. The kernel and core, which can load the hardware drivers.
2. The high-level API, resource broker, services and artificial intelligence services.
3. The globally unified virtual filesystem, made up from plugins that will allow you to mount absolutely anything and mount on-the-fly based on functional directories, URI parameters and everything I can possibly think of.
4. The API compatibility layer, which would include a POSIX API and a port of Wine.
5. The core applications, which would include the GNU system and a grammar-based editor which can serve as a text editor and a specialized editor for any kind of text or binary file provided with a grammar.

I wouldn't dare to write a GUI at first; I'd settle for applications using any number of full-screen graphical consoles (which would be far more capable than a UNIX terminal; think something like Windows console, only gone right), full-screen framebuffers and a full-screen OpenGL context.

>>24
lrn2innovate

Sounds like a rehash of the same old shit we've been using since the 60s.

>>25
How's having an OS mostly based on a high-level language, Lisp Machine-like functionality in today's hardware, built-in artificial intelligence services, a virtual filesystem more ambitious than Plan 9, and a grammar-based editor not innovative?

an OS mostly based on a high-level language,
Inferno, colorForth, Singularity, SharpOS, JX, JNode, JavaOS, etc.

Lisp Machine-like functionality in today's hardware,
Modern computers can run Lisp programs a lot faster than Lisp machines.

built-in artificial intelligence services,
Artificial intelligence isn't really useful for very many things. Having it in the core of the operating system seems a little silly to me when most people wouldn't use it, and for those who would it wouldn't be portable to other operating systems.

a virtual filesystem more ambitious than Plan 9
Sure, fuse (http://fuse.sourceforge.net/) + the Plan 9 filesystem is a lot more ambitions than the Plan 9 filesystem by itself.

a grammar-based editor
You can do that on any operating system.

Bitches don't know about my Erlang.

well, two of you seem to

Forth on a Forth chip.

Assembly with a touch of Perl 6/Parrot.

c++
making sure not to have any boundry checking or buffer management

>>31
You must be new here.

>>27
Inferno, colorForth, Singularity, SharpOS, JX, JNode, JavaOS, etc.
I don't know all of these, but the ones I know are either not serious, or not based on a truly high-level language.

Modern computers can run Lisp programs a lot faster than Lisp machines.
I know, that's why I say this. I want it to work like they wanted Lisp Machine OSes to work. The only barely used OS like that I know at the moment is Sugar for the OLPC.

Artificial intelligence isn't really useful for very many things.
Several AI techniques provided as a core API or used by the operating system functionality would improve the user experience in things such as dialog default action prediction, UI object placement, rule-based scripting, etc.

Sure, fuse (http://fuse.sourceforge.net/) + the Plan 9 filesystem is a lot more ambitions than the Plan 9 filesystem by itself.
What I'd implement includes functional directories that you could define on the fly as a function (think of an executable file that acts like a directory and gets loaded and daemonized when you reference it), such as an HTTP directory to browse the web or a directory exposing a lazily-evaluated fibonacci sequence in subdirectories. I'd also like to have globally and locally indexed metadata, a reverse link of hard links, transactions for transactional filesystem controllers, and other features supported by the filesystem API.

You can do that on any operating system.
But it's not done. If I had magic time to work on an OS, I'd have to provide it with the basic tools and applications for its use, and while I'd import/adapt much of the GNU system, the standard editor would be this.

>>33
assembly is high level. if you don't believe me, try coding in machine code. i've done it, and it makes you really appreciate having an assembler.

Super Logo :3

Forth on a Lisp Machine.

>>36
Lisp on a Forth processor.

Lisp on a Smalltalk machine.

Hax on My Anus.

>>32
I take it you haven't seen the new release, huh? Amateurs on this board always amuse me.