3 ms·

One thing not mentioned is the massive amount of complexity and difficulty involved in Starlark rules. In the next generation of build tools, I really wish Star

One thing not mentioned is the massive amount of complexity and difficulty involved in Starlark rules. In the next generation of build tools, I really wish Starlark could be replaced with some subset of TypeScript, which would have drastically better IDE support. And I wish the typing would be done in such a way that it's harder to do things that are bad for performance. Starlark is super difficult to read, navigate, and write, and there are a lot of performance gotchas. I know there are efforts like starpls (language server for Starlark) but in my experience it really falls short. I think buck2 has type annotations but I kind of hate Python-style types, so I wish we could just use TypeScript :P TypeScript is even better positioned to fill this role now that tsc is being re-written in Go.

foota 1y ago
I'm curious, how did you run into performance issues with starlark?
gaogao 1y ago
> Starlark is intended to be simple. There are no user-defined types, no inheritance, no reflection, no exceptions, no explicit memory management. Execution is finite. The language does not allow recursion or unbounded loops. That has some pretty useful properties for a config language that I'm not sure TypeScript helps much on. That said, Lean also has these properties too as an alternate language with good IDE support, and it would be pretty fun to write proofs of your build scripts.
tetromino_ 1y ago
You'll be happy to know that the Starlark team has recently started working on adding static typing! See https://github.com/orgs/bazelbuild/projects/21 https://github.com/orgs/bazelbuild/projects/21 and https://bazel.build/rules/language#StarlarkTypes https://bazel.build/rules/language#StarlarkTypes > a lot of performance gotchas Can you list some examples?
mook 1y ago
I worked on a project that used Bazel for a bit (but ended up not being a great fit). I think the part I hated most about Bazel was the fact that there were in fact two dialects; one for BUILD files and one for .bzl files. The things you do in them are different but the documentation is always vague on what goes where.

foota 1y ago

I'm curious, how did you run into performance issues with starlark?

gaogao 1y ago

> Starlark is intended to be simple. There are no user-defined types, no inheritance, no reflection, no exceptions, no explicit memory management. Execution is finite. The language does not allow recursion or unbounded loops. That has some pretty useful properties for a config language that I'm not sure TypeScript helps much on. That said, Lean also has these properties too as an alternate language with good IDE support, and it would be pretty fun to write proofs of your build scripts.

tetromino_ 1y ago

You'll be happy to know that the Starlark team has recently started working on adding static typing! See https://github.com/orgs/bazelbuild/projects/21 https://github.com/orgs/bazelbuild/projects/21 and https://bazel.build/rules/language#StarlarkTypes https://bazel.build/rules/language#StarlarkTypes > a lot of performance gotchas Can you list some examples?

mook 1y ago

I worked on a project that used Bazel for a bit (but ended up not being a great fit). I think the part I hated most about Bazel was the fact that there were in fact two dialects; one for BUILD files and one for .bzl files. The things you do in them are different but the documentation is always vague on what goes where.