4 ms·

I would love to know how you build a language that: A) is easy to write one off scripts that do a job fast, with minimal thinking and effort. I am thinking of

I would love to know how you build a language that: A) is easy to write one off scripts that do a job fast, with minimal thinking and effort. I am thinking of Python and Ruby. For me I can write code with high velocity in these languages. B) Executes loops very fast and does automatic vectorization C) Can scale toward large teams, such as that you can do drastic changes with faith that things shall not break at runtime. D) zero cost abstractions and minimal indirections. E) predictable runtime performance, no random pauses F) powerful tooling, such as package manager and IDE integration

epage 4y ago
> A) is easy to write one off scripts that do a job fast, with minimal thinking and effort. I am thinking of Python and Ruby. For me I can write code with high velocity in these languages. Once I wrap up some other projects, I plan to explore this space a little bit within Rust. imo the biggest bang for the buck is just having good `#!` support. Probably mid-year I expect to have a Pre-RFC up for single-file cargo packages. See https://github.com/epage/cargo-script-mvs/discussions/15 https://github.com/epage/cargo-script-mvs/discussions/15. A bigger effort is a batteries included, non-zero cost stdlib. I've started writing up my thoughts at https://github.com/ergo-rs/ergo https://github.com/ergo-rs/ergo. For more background on why I think these are important, see https://epage.github.io/blog/2021/09/learning-rust/ https://epage.github.io/blog/2021/09/learning-rust/. Would love feedback on these ideas and other ways to make Rust easy to use without sacrificing what makes Rust it is.
- duped 4y ago
  > imo the biggest bang for the buck is just having good `#!` support. Shebangs don't really make sense for AOT compiled languages and I don't know why you would really want one, but you can add `#!/usr/bin/env -S cargo run` to the top of a Cargo.toml file today and it will "work." I just think the premise of "why didn't you write your last script in Rust" is flawed. It's a systems programming language, if I'm writing scripts I don't really care about the same things - like static typing or meticulous error handling. It sounds like high effort and low reward imo. A REPL though (not a true one necessarily - but live-reloading of dynamic rlibs and using dynamic dispatch in place of monomorphization for REPL-builds) would be extremely useful as a workflow tool.
  - wizzwizz4 4y ago
    > Shebangs don't really make sense for AOT compiled languages Tell that to #!/usr/local/bin/tcc -run.
  - epage 4y ago
    It makes a big difference when you share a code sample, whether in a blog or on an issue, to have a single block of text to copy/paste including dependency declarations. It also lowers the barrier for experimentation. I have a directory with probably 40+ cargo-script's for one-off reproduction cases of bugs and it is much easier to work with than juggling multiple files and the overhead associated with it.
    - steveklabnik 4y ago
      > one-off reproduction cases of bugs I had never considered this case before. I'm going to start doing this!
- samsquire 4y ago
  I think this is a great idea and I really encourage you to keep going and trying things out. I'm not sure if C++ and Rust are harder to develop things fast in since I'm not experienced enough with them. it's the same with haskell, it isn't native for my mind to think from a haskell perspective.
xpe 4y ago
Good questions. Clear, organized. Please share what you find as you compare existing languages. Regarding (F) -- this is partly about (a) the language's interop story and partly about (b) building a community of people that gets along, get things done, and strikes a balance being independent enough to generate something useful and different while being open to compromising for industry adoption (which often means "slowing down" and stabilizing when the time is right). (a) There are a lot of great ways to ease editor integration. One is to build/maintain language server / analyzer. See https://rust-analyzer.github.io https://rust-analyzer.github.io. Another is to share and maintain a formal grammar. (b) I've been very pleased with my interactions in the Rust community in this regard. There are certainly many ingredients to mix in ways that make sense for a particular community. In my view, the key aspects are (i) be clear about what your language community stands for; (ii) strike a balance between fairness, transparency, and privacy in how you get there; (iii) build in accountability and feedback loops
marcosdumay 4y ago
Way to want your cake and eat it too. If you want the best possible abstraction and developer-scalability, you won't get the best possible performance. In fact, between the quickest start, largest developer-scalability, and best performance, you can only pick one.
mike_hearn 4y ago
I think Kotlin is pretty close to that albeit not satisfying (D) and only satisfying (E) if you use a pauseless GC (which you can do, it's just one command line flag). The pervasive use of type inference gives it a Pythonic feel. My company has a private tool called hshell that's completely replaced bash for my own use. It uses Kotlin Scripting to provide hashbang script-style development along with a UNIX-like API with functions like cp, cd, ls, find, tar, zip, ssh etc. You can also do things like print markdown to the console and it'll be formatted, and it understands how to draw progress bars from various sources like file copies or loop iterators. You can depend on libraries by just adding @file:DependsOn("io.ktor:ktor-server-{netty,core}-jvm:2.0.2") to the top of the file, IntelliJ can give full intellisense and refactoring support for these scripts, they're portable, you can define a CLI by annotating variables and there's a variety of other useful features. As it runs on the JVM you also get auto-vectorization, although why you'd want that for one-off scripts I'm not quite sure. It doesn't have zero cost abstractions. As you note, combining all those features together is rather hard if you want to keep a lightweight scripting feel. Overall it's pretty nice. I wouldn't want to go back to bash or python, the ergonomics of hshell are far better. I'm not sure what to do with it though, maybe release it as a product (but at what price? is there any demand?). I'm pretty sure I don't want to sign up for open source maintenance duties right now.

epage 4y ago

> A) is easy to write one off scripts that do a job fast, with minimal thinking and effort. I am thinking of Python and Ruby. For me I can write code with high velocity in these languages. Once I wrap up some other projects, I plan to explore this space a little bit within Rust. imo the biggest bang for the buck is just having good `#!` support. Probably mid-year I expect to have a Pre-RFC up for single-file cargo packages. See https://github.com/epage/cargo-script-mvs/discussions/15 https://github.com/epage/cargo-script-mvs/discussions/15. A bigger effort is a batteries included, non-zero cost stdlib. I've started writing up my thoughts at https://github.com/ergo-rs/ergo https://github.com/ergo-rs/ergo. For more background on why I think these are important, see https://epage.github.io/blog/2021/09/learning-rust/ https://epage.github.io/blog/2021/09/learning-rust/. Would love feedback on these ideas and other ways to make Rust easy to use without sacrificing what makes Rust it is.

duped 4y ago
> imo the biggest bang for the buck is just having good `#!` support. Shebangs don't really make sense for AOT compiled languages and I don't know why you would really want one, but you can add `#!/usr/bin/env -S cargo run` to the top of a Cargo.toml file today and it will "work." I just think the premise of "why didn't you write your last script in Rust" is flawed. It's a systems programming language, if I'm writing scripts I don't really care about the same things - like static typing or meticulous error handling. It sounds like high effort and low reward imo. A REPL though (not a true one necessarily - but live-reloading of dynamic rlibs and using dynamic dispatch in place of monomorphization for REPL-builds) would be extremely useful as a workflow tool.
- wizzwizz4 4y ago
  > Shebangs don't really make sense for AOT compiled languages Tell that to #!/usr/local/bin/tcc -run.
- epage 4y ago
  It makes a big difference when you share a code sample, whether in a blog or on an issue, to have a single block of text to copy/paste including dependency declarations. It also lowers the barrier for experimentation. I have a directory with probably 40+ cargo-script's for one-off reproduction cases of bugs and it is much easier to work with than juggling multiple files and the overhead associated with it.
  - steveklabnik 4y ago
    > one-off reproduction cases of bugs I had never considered this case before. I'm going to start doing this!
samsquire 4y ago
I think this is a great idea and I really encourage you to keep going and trying things out. I'm not sure if C++ and Rust are harder to develop things fast in since I'm not experienced enough with them. it's the same with haskell, it isn't native for my mind to think from a haskell perspective.

xpe 4y ago

Good questions. Clear, organized. Please share what you find as you compare existing languages. Regarding (F) -- this is partly about (a) the language's interop story and partly about (b) building a community of people that gets along, get things done, and strikes a balance being independent enough to generate something useful and different while being open to compromising for industry adoption (which often means "slowing down" and stabilizing when the time is right). (a) There are a lot of great ways to ease editor integration. One is to build/maintain language server / analyzer. See https://rust-analyzer.github.io https://rust-analyzer.github.io. Another is to share and maintain a formal grammar. (b) I've been very pleased with my interactions in the Rust community in this regard. There are certainly many ingredients to mix in ways that make sense for a particular community. In my view, the key aspects are (i) be clear about what your language community stands for; (ii) strike a balance between fairness, transparency, and privacy in how you get there; (iii) build in accountability and feedback loops

marcosdumay 4y ago

Way to want your cake and eat it too. If you want the best possible abstraction and developer-scalability, you won't get the best possible performance. In fact, between the quickest start, largest developer-scalability, and best performance, you can only pick one.

mike_hearn 4y ago

I think Kotlin is pretty close to that albeit not satisfying (D) and only satisfying (E) if you use a pauseless GC (which you can do, it's just one command line flag). The pervasive use of type inference gives it a Pythonic feel. My company has a private tool called hshell that's completely replaced bash for my own use. It uses Kotlin Scripting to provide hashbang script-style development along with a UNIX-like API with functions like cp, cd, ls, find, tar, zip, ssh etc. You can also do things like print markdown to the console and it'll be formatted, and it understands how to draw progress bars from various sources like file copies or loop iterators. You can depend on libraries by just adding @file:DependsOn("io.ktor:ktor-server-{netty,core}-jvm:2.0.2") to the top of the file, IntelliJ can give full intellisense and refactoring support for these scripts, they're portable, you can define a CLI by annotating variables and there's a variety of other useful features. As it runs on the JVM you also get auto-vectorization, although why you'd want that for one-off scripts I'm not quite sure. It doesn't have zero cost abstractions. As you note, combining all those features together is rather hard if you want to keep a lightweight scripting feel. Overall it's pretty nice. I wouldn't want to go back to bash or python, the ergonomics of hshell are far better. I'm not sure what to do with it though, maybe release it as a product (but at what price? is there any demand?). I'm pretty sure I don't want to sign up for open source maintenance duties right now.