5 ms·

But the development seems stopped. The latest commit was on Jun 8, 2019. At the time this project showed up, I gave it a try on QEMU. It was cool and I was li

But the development seems stopped. The latest commit was on Jun 8, 2019. At the time this project showed up, I gave it a try on QEMU. It was cool and I was like "I must join this!" As the result, except for one minor fix, I was not able to contribute more because the development environment was not comfortable. The patched go tree was not easy to follow. It also looks impossible for others to just rebase to later go. My take on this is that, although go provides many OS-like features, you still have to draw a clear line between the OS and the language it uses if you want it to be maintainable and evolvable. I am still obsessed to the idea of making an OS in go and somehow trying doing one in a very slow pace.

remexre 6y ago
> you still have to draw a clear line between the OS and the language it uses I'm hoping to avoid this in one of my own OS projects using Forth, actually; I think using a language with most features implemented outside of the core language implementation, but rather in libraries, helps a lot here. For example, exceptions are implemented in the OS code rather than by compiler magic (though there are some built-ins the exception system needs to call that are only really relevant if you're building an exception system). The actual Forth implementation is under 2000 lines of aarch64 assembly, after removing comments and whitespace.
- qlk1123 6y ago
  English is not native to me so I'm not sure it is me that misunderstanding you or the reverse. By "no clear line", I mean something like building the OS on top of some of the language modules. Just like what biscuit did, the runtime and some other packages were integrated as a part of the OS. Such an approach brings inevitable impact to the project, because there will be no longer any easy way to keep up with the new features/progress in the language. On the other hand, you stated > I think using a language with most features implemented outside of the core language implementation, but rather in libraries, helps a lot here. I don't see how your experience contradicts with my previous statement. Would you clarify more? Also, I don't know Forth before. Thanks for enlarging my view.
  - pjmlp 6y ago
    See Oberon, Smalltalk, Interlisp-D, Lisp Machines, Mesa/Cedar as well.
  - remexre 6y ago
    Ah, I think I was seeing a slightly different problem; the problem I saw was that when the OS and compiler start to be tied together tightly enough that changes to one make it necessary to change the other, so anyone working on them needs both skillsets. Forth helps here since the parts of the language that are "baked into" the implementation (i.e. not just standard library code) are extremely minimal; in most of the Forths I implement, even function definition is itself defined in the standard library. Needing to avoid diverging from an upstream compiler is also somewhat alleviated by (most dialects of) Forth being suitable for OS development out of the box, so patching the compiler isn't often necessary. Additionally, it's not ridiculous to implement a custom Forth for each project, depending on its needs, which makes tracking an upstream a non-issue. A Forth implementation is far less code than an implementation of C, Go, etc., so it's not very time-consuming, and the way Forth user code is typically written makes it easy to port code between implementations.
bigdict 6y ago
This is just someone's thesis, most projects like that are abandoned immediately after defense.

remexre 6y ago

> you still have to draw a clear line between the OS and the language it uses I'm hoping to avoid this in one of my own OS projects using Forth, actually; I think using a language with most features implemented outside of the core language implementation, but rather in libraries, helps a lot here. For example, exceptions are implemented in the OS code rather than by compiler magic (though there are some built-ins the exception system needs to call that are only really relevant if you're building an exception system). The actual Forth implementation is under 2000 lines of aarch64 assembly, after removing comments and whitespace.

qlk1123 6y ago
English is not native to me so I'm not sure it is me that misunderstanding you or the reverse. By "no clear line", I mean something like building the OS on top of some of the language modules. Just like what biscuit did, the runtime and some other packages were integrated as a part of the OS. Such an approach brings inevitable impact to the project, because there will be no longer any easy way to keep up with the new features/progress in the language. On the other hand, you stated > I think using a language with most features implemented outside of the core language implementation, but rather in libraries, helps a lot here. I don't see how your experience contradicts with my previous statement. Would you clarify more? Also, I don't know Forth before. Thanks for enlarging my view.
- pjmlp 6y ago
  See Oberon, Smalltalk, Interlisp-D, Lisp Machines, Mesa/Cedar as well.
- remexre 6y ago
  Ah, I think I was seeing a slightly different problem; the problem I saw was that when the OS and compiler start to be tied together tightly enough that changes to one make it necessary to change the other, so anyone working on them needs both skillsets. Forth helps here since the parts of the language that are "baked into" the implementation (i.e. not just standard library code) are extremely minimal; in most of the Forths I implement, even function definition is itself defined in the standard library. Needing to avoid diverging from an upstream compiler is also somewhat alleviated by (most dialects of) Forth being suitable for OS development out of the box, so patching the compiler isn't often necessary. Additionally, it's not ridiculous to implement a custom Forth for each project, depending on its needs, which makes tracking an upstream a non-issue. A Forth implementation is far less code than an implementation of C, Go, etc., so it's not very time-consuming, and the way Forth user code is typically written makes it easy to port code between implementations.

bigdict 6y ago

This is just someone's thesis, most projects like that are abandoned immediately after defense.