4 ms·

> Clone bash in C, which (charitably) would involve writing around 80K lines of C code from scratch, given that bash is 160K lines. Or, third option, you could

> Clone bash in C, which (charitably) would involve writing around 80K lines of C code from scratch, given that bash is 160K lines. Or, third option, you could have used a language like Rust that would allow you to write using a high-level programming language, and yet still you could dip down to low-level code whenever needed for performance reasons. Don't get me wrong, I'm a big Python fan for certain types of projects. And now with Python 3 and asyncio, Python is great for writing I/O-bound code. But it's not ideal, even if you confine your use to a Python subset, for a project for which parsing is a critical part. Finally, you may prove me wrong, but even using a subset of Python, I don't think you're going to eke out the performance you're looking for using CPython's VM. I say this simply because it's not a very performance-oriented VM (partly because of the bytecode instruction set but also because it's stack- instead of register-based, and some other architectural issues). So then you're back to writing your own VM from scratch -- a significant undertaking. In any case, I wish you luck. Oil Shell's a cool project, so I hope it succeeds.

chubot 9y ago
I find Rust more interesting than I did at the start of the project, since I ended up using algebraic data types all over the place, which Rust has. And it doesn't have the runtime issues I mentioned with Go. But the compile times are a dealbreaker. As mentioned in the post, if I had a C++ compiler in my edit-run cycle, I would have never have gotten the project done. From what I understand having a Rust compiler in there would be even worse. I can understand why you think Python is not ideal, and I listed many reasons in the post why it's not. But that is why I used a name OPy -- OPy is purposefully diverging Python. See the Tex analogy. I agree it's an experiment. I didn't make any claims in the post; I specifically mentioned that I would like to prove a point. I agree that I will need to change the Python VM. The speedups can be unlimited in that case that I write an entirely new VM (which is easier than rewriting the very flexible and capable Python VM from scratch). Another thing I didn't mention: it is probably possible to make the shell VM and OPy VM converge. So Oil's runtime could be faster than any other shell, because every shell is a tree interpreter and not a bytecode VM. (The parser might still be slower, but I don't expect that to be an issue.) ---- EDIT: On the other hand, I doubt you can write bash in Rust in less than say 50K to 80K lines of code. I think Rust will still be at least 3x more verbose than Python. It inherently expresses more, so this is fundamental. So even if compile times were not an issue, I still probably wouldn't choose Rust. Also, build dependencies matter a lot for a shell, since it's used to bootstrap embedded systems. I conjecture that shells run all sorts of systems that Rust programs have never run on. Rust isn't as portable as C, or C++.
- jnbiche 9y ago
  > I conjecture that shells run all sorts of systems that Rust programs have never run on. Rust now runs on all kinds of embedded systems, including MSP, most current ARM architectures, MIPS, PowerPC, and even (via forked version of Rust soon to be merged) AVR. So it can run on most, if not all, major architectures that shells run on.

chubot 9y ago

I find Rust more interesting than I did at the start of the project, since I ended up using algebraic data types all over the place, which Rust has. And it doesn't have the runtime issues I mentioned with Go. But the compile times are a dealbreaker. As mentioned in the post, if I had a C++ compiler in my edit-run cycle, I would have never have gotten the project done. From what I understand having a Rust compiler in there would be even worse. I can understand why you think Python is not ideal, and I listed many reasons in the post why it's not. But that is why I used a name OPy -- OPy is purposefully diverging Python. See the Tex analogy. I agree it's an experiment. I didn't make any claims in the post; I specifically mentioned that I would like to prove a point. I agree that I will need to change the Python VM. The speedups can be unlimited in that case that I write an entirely new VM (which is easier than rewriting the very flexible and capable Python VM from scratch). Another thing I didn't mention: it is probably possible to make the shell VM and OPy VM converge. So Oil's runtime could be faster than any other shell, because every shell is a tree interpreter and not a bytecode VM. (The parser might still be slower, but I don't expect that to be an issue.) ---- EDIT: On the other hand, I doubt you can write bash in Rust in less than say 50K to 80K lines of code. I think Rust will still be at least 3x more verbose than Python. It inherently expresses more, so this is fundamental. So even if compile times were not an issue, I still probably wouldn't choose Rust. Also, build dependencies matter a lot for a shell, since it's used to bootstrap embedded systems. I conjecture that shells run all sorts of systems that Rust programs have never run on. Rust isn't as portable as C, or C++.

jnbiche 9y ago
> I conjecture that shells run all sorts of systems that Rust programs have never run on. Rust now runs on all kinds of embedded systems, including MSP, most current ARM architectures, MIPS, PowerPC, and even (via forked version of Rust soon to be merged) AVR. So it can run on most, if not all, major architectures that shells run on.