4 ms·

Okay, I understand developers can spend their time doing whatever they want. Nobody can (or even should) tell other people how they're going to spend their spa

Okay, I understand developers can spend their time doing whatever they want. Nobody can (or even should) tell other people how they're going to spend their spare time. But... wouldn't the effort be better spent improving the existing interpreter? The vague description makes it sound like they're trying to run Erlang without an OS "getting in the way". Looking at the language shootout benchmarks [1], it seems like there's still a lot of room for improvement before the OS would be slowing them down. Operating system services aren't causing Erlang to take 3-25x as long as the C code. [1] http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=hipe&lang2=gcc http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...

mrmekon 14y ago
We are completely surrounded by embedded devices, and their numbers are growing exponentially. Everything has a computer in it. You might be shocked to know the power that's in some of these devices... your cable box might be a quad-core 1.2GHz ARM. Currently, your common options for embedded software are: * bare-metal with C, C++, or ASM * load a full OS (i.e. Linux) and run an interpreter to get access to higher-level languages There are a lot of domains where the problem being solved doesn't require particularly high hardware resources, but requires quite advanced software design. Implementing something like a modern Blu-Ray player's UI and high-bandwidth/low-latency AV in C is rough. You spend a LOT up front on software development costs, and pay more in the maintenance phase. Alternatively, you can save on development and maintenance by running an OS and using high-level languages and existing libraries... but then your board price per unit skyrockets because of the extra processing power, RAM, and flash that you need to support the OS and interpreters. Access to a modern programming language at a "bare-metal" environment is the holy grain for embedded. It would change the world. Unfortunately, it has always been practically impossible. And likely still is.
- kabdib 14y ago
  Other options: FORTH. Icky, but I thought I'd mention it; very fast bringup time . . . but then it's FORTH. A commercial RTOS. There are lots of these, some of them are even pretty good. We went the C-and-ASM route and ported over some USB drivers from another in-house OS. Worked okay. USB is horrible to work with, and that was actually the hardest part to get right on our system.
stiff 14y ago
Erlang is as much of a platform as it is a (pretty peculiar) language and its functionality does overlaps with the operating system, for example thread management (and in Erlang you tend to have thousands of threads as far as I understand) and things like being able to boot up Erlang on ten computers and have them behave like one big Erlang instance. In other words, considering what Erlang does, it seems plausible this is a very reasonable thing to try, I don't think this has to do with "operating system services" in the windowish sense of the word "service", it's more about conflicting approaches to same problems between the OS and Erlang.
- pi18n 14y ago
  I was thinking this also! The difference between Erlang and an OS seems like little more than device drivers. Moving BEAM into kernel-space would improve the speed of the thread switching and IPC. So Erlang is a particularly good language to try this with. Also I think this is a good idea in general. With cloud hosting, why run a full Linux OS if you are only going to run a webserver or database shard on it? If the OS could be replaced by a file manager and the runtime code of a single application (with some significant speedup), there are probably a bunch of companies that would be interested.
rdtsc 14y ago
> it seems like there's still a lot of room for improvement before Room for improvement to do what? Compute n-body simulations. Permutations, or searching a FASTA file, spectral norm? You can't be serious. The only one of consequence maybe the thread ring Erlang comes 3rd then after Go and Haskell.

mrmekon 14y ago

We are completely surrounded by embedded devices, and their numbers are growing exponentially. Everything has a computer in it. You might be shocked to know the power that's in some of these devices... your cable box might be a quad-core 1.2GHz ARM. Currently, your common options for embedded software are: * bare-metal with C, C++, or ASM * load a full OS (i.e. Linux) and run an interpreter to get access to higher-level languages There are a lot of domains where the problem being solved doesn't require particularly high hardware resources, but requires quite advanced software design. Implementing something like a modern Blu-Ray player's UI and high-bandwidth/low-latency AV in C is rough. You spend a LOT up front on software development costs, and pay more in the maintenance phase. Alternatively, you can save on development and maintenance by running an OS and using high-level languages and existing libraries... but then your board price per unit skyrockets because of the extra processing power, RAM, and flash that you need to support the OS and interpreters. Access to a modern programming language at a "bare-metal" environment is the holy grain for embedded. It would change the world. Unfortunately, it has always been practically impossible. And likely still is.

kabdib 14y ago
Other options: FORTH. Icky, but I thought I'd mention it; very fast bringup time . . . but then it's FORTH. A commercial RTOS. There are lots of these, some of them are even pretty good. We went the C-and-ASM route and ported over some USB drivers from another in-house OS. Worked okay. USB is horrible to work with, and that was actually the hardest part to get right on our system.

stiff 14y ago

Erlang is as much of a platform as it is a (pretty peculiar) language and its functionality does overlaps with the operating system, for example thread management (and in Erlang you tend to have thousands of threads as far as I understand) and things like being able to boot up Erlang on ten computers and have them behave like one big Erlang instance. In other words, considering what Erlang does, it seems plausible this is a very reasonable thing to try, I don't think this has to do with "operating system services" in the windowish sense of the word "service", it's more about conflicting approaches to same problems between the OS and Erlang.

pi18n 14y ago
I was thinking this also! The difference between Erlang and an OS seems like little more than device drivers. Moving BEAM into kernel-space would improve the speed of the thread switching and IPC. So Erlang is a particularly good language to try this with. Also I think this is a good idea in general. With cloud hosting, why run a full Linux OS if you are only going to run a webserver or database shard on it? If the OS could be replaced by a file manager and the runtime code of a single application (with some significant speedup), there are probably a bunch of companies that would be interested.

rdtsc 14y ago

> it seems like there's still a lot of room for improvement before Room for improvement to do what? Compute n-body simulations. Permutations, or searching a FASTA file, spectral norm? You can't be serious. The only one of consequence maybe the thread ring Erlang comes 3rd then after Go and Haskell.