You don't need a JS bootloader to write an OS in JS. The bootloader just drops the machine into some memory address for it to start executing your OS init script. that bit could be a Javascript interpreter. You can't do much with the architecture in Javascript though, because it doesn't allow you to map memory directly to your types (unless there's some ungodly nonesense I'm not aware of) so you'll have to drop into C/asm to e.g. interact with the ports/registers/tables to set up userspace.
It's pretty easy to wrap the typescript compiler however I've not seem many people use pure TS like that. Mostly people want to use webpack and TS together. Unfortunately webpack doesn't expose anything that would allow us to incrementally build a webpack bundle.
Please takes sandboxing a bit further using kernel name-spacing to isolate builds and tests. It's an opt-in feature but you can bind to port 8080 in your tests and run them in parallel if you do ;)
I recently added a config option so plz test will run tests in the package directory rather than the repo root (just like go test). Should make things a little easier.
Hey guys! Thanks for checking Please out! I see a lot of recurring themes in the comments so I thought I would clear some things up.
What is Please?
Please is a multi-language build system designed for huge mono-repos. It was created by a couple frustrated ex-googlers who were familiar with Blaze (which was later open sourced as Bazel). We found the "real world" alternatives to be somewhat lacking and so Please was born!
Please draws inspiration on the Blaze paradigm. If you're familiar with Bazel, the biggest difference is Please aims to be simpler and have far less magic in the binary. We push the implementation of the build rules into the build language, dog feeding them to ensure Please is flexible enough for any task. Also Please is written in Go so doesn't require a JVM ;)
If you're not familiar with Blaze/Bazel, here's what all the fuss is about:
1) Hermetic builds: builds are run in their own tightly controlled environment. Each step of the build runs in their own temp directory isolating them from other steps and only having access to the files and environment variables they've declared as their inputs. Please also has sandboxing built in taking advantage of the linux kernel to further isolate tests.
2) Scalability through incrementallity: if you've used Make, you're probably familiar with caching problems. Make uses last modified timestamps on files to determine if they need to rebuild each step, which turns out is fallible. Please uses a hash based approach which is far more robust. Most of our developers don't even know how to clean the cache. As a result, we can incrementality build our entire repository locally and on our CI workers no matter how big our repo gets.
3) Flexibility: the build language is a dialect of python. This can be used to write "build definitions" which define a unit of work i.e. compiling a Go package. There's nothing special about the built in definitions; it's totally possible to write your own to automate nearly any part of your development process. You could generate code, template kubernetes .yamls and beyond!
4) Unified developer experience: The please command line provides a unified experience across your codebase. Want to test all the tests under a branch of your repo? `plz test //some/part/of/the/repo/...`. It doesn't matter what language you're using, what those tests depend on etc. etc. Please can always run them for you.
PS: Apologies for the website. We're a small team of build system engineers, not front end types. If you want to offer your skills, I'd be happy to point you in the right direction: https://github.com/thought-machine/please.
Hey, Please maintainer here! One of the big differences to the other Blaze like build systems is Please actually doesn't treat any of the built in languages any differently to other languages. They are implemented entirely in the build language which is totally open to you as a consumer of Please.
Another big difference is Please is written in Go so there's no dependency on VMs or runtimes.
Please excels in a mono-repo situation. We built Please because we struggled to get Buck to handle Python, Javasript, and Java while having protobuf code generation for all these languages.
Fast forward 5 years, now we're using Please to build all our code, generate hashes for docker images, template those hashes into our k8s .yamls, generate the documentation website from the docstrings in the proto files etc. etc.
With a language specific build system, you would have a lot of trouble handling things like this.
Yup fair enough. Migrating build systems is hard. I've put some work into making migrating from a `go build` project to Please a bit easier. Banzai cloud recently migrated their [Pipeline](https://github.com/banzaicloud/pipeline) project over to use Please but admittedly it was quite a lot of work for them.
Hey! Glad you liked it :D Please is owned by Thought Machine. They’ve recently (8 months) brought me on the project full time. We’re planning on putting together a dedicated IDE team together but no promises.
Hey, I maintain please and will be the first one to admit we’re not the best at marketing it. We’ve mostly been focused on getting it up to scratch and only recently have we been trying to publicise it.
With that being said I have put a good amount of work into the QuickStart.
The code labs are designed to get you up and started in an inviting way. If you have any specific feedback about your QuickStart experience I’d love to hear it.