Project abandoned?

[danawoodman]

Just heard about BorrowScript today and read the readme and got really excited. Always wanted a language that combined the ease of use of TypeScript with the performance and safety guarantees of Rust.

But then I realized there's been no activity for a good amount of months. Is it safe to assume that this idea has been abandoned?

[maxiim3]

It's indeed a cool project

[alshdavid]

Hey all, it's definitely not abandoned!

There are aspects of the language I'd like to refine further (like lifetimes, interior mutability, async, macros) and I feel I need to spend more time with Rust to understand why Rust made the language design decisions in the way that it did.

As you can imagine, it's a big undertaking to write a programming language. That said, I genuinely believe that a language which offers the core benefits of Rust through a familiar, simple, expressive syntax will be a productive environment for user-space applications - like desktop gui apps, wasm gui apps, web servers/APIs, perhaps even bundlers.

I'm happy for more experienced language designers to contribute their thoughts and raise PRs in the interim!

The basic mission statement is "what are the minimum changes required to TypeScript to have it support a borrow checker". Along the way we'd need to pull out some of JavaScript's quirks, leaning out TypeScript in the process - so on the other hand, what are the features from TypeScript to keep?

=== unimportant brain dump below

For instance, when you import a module in TS, it's allowed to run code on the top level at the time of importing. This complicates the handling of modules - particularly during build optimization - and can actually introduce performance overhead associated with importing modules - so that will have to go.

What about the window/global/globalThis variable? Probably incompatible with ownership so it'll have to go too - but perhaps we can have a global variable but put it behind a Mutex? Might be needed for wasm applications

Structural types and algebraic types (like type Foo = string | number) in TS are fantastic and they stack really well with the compiler analyzing your control flow to discern the current type as you eliminate options.

function foo(bar: string | undefined) {
  if (bar === undefined) return
  console.log(bar) // compiler knows this is now string
}

However that implies a more imperative style of programming that is in contrast with Rust's preference for using match

fn foo(bar: Option<i32>) {
  match bar {
    None => {},
    Some(value) => { print!("{}", value) },
  }
}

Then if you think about it, Rust's enum is trying to solve the same problem that TypeScript solves with structural types and type elimination - so do we need enums in the same form we see in Rust? A switch statement against an algebraic type is largely analogous in the instance of pattern matching - so maybe not?

It's quite interesting finding the intersection between the two languages, but again, I am trying to learn more about

[danawoodman]

Excited to hear it's not abandoned.

I'd be all for Result/Option types replacing algebraic types in the situations you mentioned; I already use libs like neverthrow/ts-results to emulate this in JS. That said not sure all the ramifications of this design decision.

[alshdavid]

I totally share your sentiment about Result and Option types. Having typed errors during error handling is fantastic.

Unlike TypeScript, BorrowScript will not have the ability to weaken the type checker through compilerOptions - so algebraic types will have teeth, allowing the compiler to prevent impossible situations.

Given we will need to have algebraic types out of the box with BorrowScript, I think there is a roadmap to Result and Option classes which build on top of type unions.

For instance, a primitive Result could start off as:

// Can be one of the following type signatures:
type BaseResult<Value, Error> = { value: Value } | { error: Error }

function foo(shouldError: boolean): BaseResult<string, string> {
  if (shouldError) {
    return { error: "my error message" }
  }
  return { value: "my value" }
}

let result = foo(true)

if ('error' in result) {
  console.log(result.error) // Compiler knows that result.error must be a string
                            // Trying to access result.value here will result in a compiler error
  process.exit(1)
}

console.log(result.value)   // Compiler knows that result.value must be a string
console.log("success")

Which would be trivial to wrap up in a Result class. A cool thing about TypeScript type elimination is that it allows us to use optional types without needing to .unwrap() them.

Though there's also the discussion on classes.

I personally virtually never use class extension. To me, classes are just structs with methods and I'd lean towards implementing non-extendible classes into BorrowScript - though using the word "class" implies the behaviours expected in classes.

So perhaps we can just call them a struct with some kind of weird hybrid declaration syntax

export struct Foo {
  public value: string
  
  static new(value) {
    return Foo{ value }
  }

  public read printValue() {
    console.log(read self.value)
  }

  public write updateValue(value: move string) {
    self.value = value
  }
}

But then, you don't want to stray too far from TypeScript because that would go against the objective of making a compilable TypeScript with a borrow checker - so perhaps just calling them classes and slapping up a warning about not using extends is better 😆

[danawoodman]

Will BS (great acronym 🤣) have a concept like Rust's Traits? Could also consider Go's approach to extending a struct with methods without needing a class keyword:

type MyType struct {}

func (s *MyType) MyFunc() {}

If you could have that while explicitly implementing an interface (something Go got wrong imo), or some hybrid of this with Rust's traits I feel you'd have a winning combo.

Will it have colored functions? I feel Go gets this right here and does not require a caller to know if a func is async or not. Changing from sync to async causes cascading contract changes which make big refactors very painful.

If you had the follow I feel like you'd have the "perfect" language:

• A friendly, intuitive JavaScript/TypeScript-like syntax
• Statically compiled to efficient cross platform binaries (at least as fast as Go on average)
• Rust's Option/Result types or a similar way to explicitly type error responses and handle match-type scenarios of undefined/defined values
• "Colorless" functions: Don't require a caller to know if a func is async, Go is a good inspiration here.
• Rust Traits/Go struct funcs type ability to make class-like structs with methods
• Remove all the "wats"/foot-guns from JavaScript
• Excellent standard library (Go kills Rust in this regard)
• Ability to run code at compile time like Zig
• (and move to snake_case for the love of all that is holy, cameCase was a mistake 😅)

I feel that Vlang gets a lot of these right, but without the controversy/over-selling. Perhaps their language docs could be a good inspiration.

Anyways, just some thoughts as I too have wanted a TypeScript-like language that takes some inspiration 😄

[alshdavid]

Hey all, update.

I've been working with Rust professionally for the last year and it's really helped me get an understanding for how its ideas could be applied to a simplified language.

I still think there is a need for a language like Rust with a simplified syntax - particularly when it comes to async code.

Simplifying the language would come at a performance cost as it would rely more heavily on dynamic data structures.

Things I have been thinking about:

Lifetimes

Lifetimes are particularly difficult to translate and I think it would be wise to exclude them. I can use compiler magic to automatically wrap values in smart pointers when the compiler detects they are needed.

Essentially, automatically converting values to be reference counted when the compiler detects they need to be - like this:

async function main() {
  const foo = "hi"

 const p1 = (async [clone foo]() => {
    console.log(foo)
  })()

 const p2 = (async [clone foo]() => {
    console.log(foo)
  })()

  await Promise.all([p1, p2])
}

Where the compiler automatically makes foo an Arc<String>. An interesting consideration is what to do when foo is declared as mutable (via let).

Async

This is such a tricky problem to solve. Rust is very picky with its Futures and I'd like to avoid Pin<Box<dyn Future>> hell. Another thing I'd like to improve on is the interoperability of async code.

Having the async runtime built into the standard library makes sense for this, making that configurable is an interesting challenge.

Go uses environment variables to control the behaviour of it's async runtime - but that requires shipping the entire runtime even if you only use a single threaded event loop.

There are also cases where you might want to have the application explicitly define a single threaded event loop as the behaviour may depend on that. Other cases where you might want multiple/separate runtimes, and cases where you might explicitly want OS threads.

Send Sync FnOnce Fn

Rust has support in its type system for types that can be sent across threads, run once in a callback, run multiple times - etc.

I find this concept to be super powerful and have yet to determine how that fits into the vision of our language.

FFI

Super important for me is a quality FFI to ensure interoperability with C libraries. What that looks like is still up for grabs.

Closing thoughts

My day job has been to work on a Rust JavaScript bundler so I have been learning a lot about compilers. I'm feeling pretty confident that I could write a basic compiler for BorrowScript that could build some basic examples. I'm not sure how to target LLVM, though I could certainly output C and compile that with gcc (at least in the initial stages)

[mindplay-dk]

Regarding async, just a thought I've had kicking around in my head for a while but...

Why aren't there any languages where await is optional? 🤔

So like, if you wanted to fetch something, you would just write const body = fetch(url).body, and it just implicitly awaits by default - if the language is statically typed, that shouldn't really be a problem.

In cases where you would normally await Promise.all(...) as an optimization, this could even just be done implicitly:

function readFiles() {
  const a = readFile("a.txt")
  const b = readFile("b.txt")

  return "{a}\n{b}"
}

Since there are no blocking dependencies here, these calls could execute in parallel, and the return statement implicitly awaits both a and b before evaluating the expression in the return statement.

There are of course cases where you might need more control - if it's important to read those files one at a time, you could explicitly await:

function readFiles() {
  const a = await readFile("a.txt")
  const b = await readFile("b.txt")

  return "{a}\n{b}"
}

Add something like a run keyword, which you can optionally place before a call, so if you want to opt out of implicit await, and actually get a generic promise/future, you can. but why is this the default in every language?

I'm sure there are other cases of control and optimizations you would need to consider, but, two points:

1. Why should all this extra and thinking be required for the majority use-case, where you just want to await if it's necessary, and you just want things to run as soon as they can? Most of the time, you don't need very granular control - it's just mind numbing ceremony and noise.

2. Eliminate the red/black problem! Never again worry about having to refactor your entire codebase because you discover that some function, deep in your call graph, now needs to read a file. (as well as avoiding the ugly Node approach, where every IO function comes in two flavors, one of which implicitly awaits.)

I don't have a complete solution, it's just something I've been thinking about many times over the years, and I don't think it's out of reach in a fully statically-typed language. 😄

[danawoodman]

IMO colored functions (async function()) are terrible.

A single change in one function causes a cascade in every single dependency of that function.

I'd argue that Go gets this right.

Just my $0.02 on this topic.

[alshdavid]

A single change in one function causes a cascade in every single dependency of that function.

Yeah propagating async code is pretty rough.

I'd argue that Go gets this right.

Likewise. I think an intersection is possible but it really depends on how the async runtime is configured.

Consider the following example - looks very async-like but without requiring the parent function to annotate itself with async:

package main

import "fmt"

func main() {
	value := <-foo()
	fmt.Println(value)
}

func foo() chan int {
	messages := make(chan int)
	go (func() {
		messages <- 42
	})()
	return messages
}

But upon closer inspection, you can actually do exactly this in Rust with channels via Receiver.recv().

use std::sync::mpsc::channel;
use std::sync::mpsc::Receiver;
use std::thread;

fn main() {
    let value = foo().recv().unwrap();
    println!("Hello {}", value);
}

fn foo() -> Receiver<usize> {
    let (tx, rx) = channel();
    
    thread::spawn(move || {
        tx.send(42)
    });
    
    rx
}

So in a way, Go skips the need for async entirely by using a built-in concurrency runtime with channels. This also limits the interoperability of the language in FFI cases.

In my use cases, having control of the async runtime has been essential. There are cases where I want a single threaded async runtime that interoperates with an multithreaded one.

For example:

• In native desktop GUI applications, GUI SDKs will often have their own async runtime built in and you need to create a bridge to make them work with Rust.
• In wasm GUIs, you might want to have a single threaded async runtime for the UI thread while using a multi-threaded async runtime for working code.

Ultimately, some kind of intersection is probably possible here. It's an area I'd like to explore.

Perhaps starting off without async and using OS threads and channels to have Go-like syntax will suffice

[mindplay-dk]

Perhaps starting off without async and using OS threads and channels to have Go-like syntax will suffice

For things like web/socket servers with many clients, you probably need at least a basic implementation of fibers - but yeah, it doesn't need to be anything super advanced. (in fact, simpler is often better, if it helps people actually understand what they're working with - assuming you give them sane defaults, and enough optional controls to handle advanced use cases.)

We might be having two different discussions here though? I wasn't even thinking about multithreading. 🙂

Even if the first version of the language was single-threaded, you still need non-blocking IO primitives of some sort, and avoiding the red/black problem could be a game changer in terms of ergonomics, even just for a basic event loop or a simple microtask queue, or whatever is enough to get the language bootstrapped to do something useful. 🙂

[alshdavid]

Update

tl;dr: I'm working on a compiler!

Async

I've been digging into Rust's approach to async and wrote my own async runtime to better understand it.

I'm feeling that it's vital the async runtime for BorrowScript is substitutable at runtime (like Rust) but default implementations and common interfaces (like AsyncRead and AsyncWrite) are supplied by the standard library (unlike Rust).

This means you have flexibility in the choice of runtime (helpful when targeting wasm or napi) but also don't need to juggle third party libraries to get started. It also means the first version of the language can include the interface for async without an implementation that satisfies it.

I'll also make it a priority to integrate third party async runtime projects into the standard library (like if someone makes a wasm runtime, napi runtime) to minimize fragmentation and ensure that the language is as "batteries included" as possible.

Another thing is that I want to make async easier to work with compared to Rust - avoiding wild return types like Pin<Box<dyn Future<Output = Result<String, Error>>> - though this might be tricky given lifetimes are a thing and need a way to be expressed.

Macros

Macros are one of the most incredible features of Rust and are 100% going to be in BorrowScript. I will steal the runtime decorator syntax from TypeScript for this but it will largely remain the same to Rust.

function main() {
  println!("macros are awesome")
}

Specific to web frameworks; a limitation I have found with TypeScript is that web frameworks (Angular, Svelte, Vue) have had to ship their own external custom made compilers that each need their own way to integrate into bundlers.

My hope is that GUI frameworks can be implemented as macros, and further, I hope that the cross platform nature of BorrowScript will allow framework vendors to have different renderer targets using roughly the same syntax. For instance React browser can also be compiled to React native.

// React
function MyComponent() {
  return react!(<div>Hello World</div>)
}

// Vue, Svelte, etc
function MyComponent() {
  return vue!(
    <script>
      const foo = 'hello world'
    </script>
    <div>{ foo }</div>
  )
}

// Angular could use a proc macro
@component!({
  template: <>
    <div>Hello World</div>
  </>
})
class MyComponent {}

Structs, classes, objects?

This is interesting and something to think about. I want to feature quality FFI capabilities. structs are required to interop with C so they need to exist.

Ignoring inheritance, the value of classes (for me) is the ability to assign methods to an object within the same code block.

class Foo {
  foo(): void {}
}

Which I find ergonomic. While structs in Go and Rust both use the receiver model on top of structs

struct Foo {}

impl Foo {
  foo(&self) {}
}

From an ergonomics standpoint, I find the approach that Rust and Go use to be a little annoying at times due to them visually breaking the object up into multiple blocks and that can sometimes make it difficult to understand what methods belong to what object - particularly when one source file contains many struct definitions with many receiver blocks and in whatever order the developer decides on.

struct Foo {}
struct Bar {}

impl Foo {}
impl Bar {}

impl Debug for Foo {}
impl Debug for Bar {}

But on the other hand, classes need constructors which makes the ergonomics of zero value initialization challenging

example:

@derive!(Default)
class Foo {
  foo: string
}

Should this expand into the following?

class Foo {
  foo: string

  static default(options: Partial<KeysOf<Foo>>) {
    const foo = new Foo() // what if Foo has an existing constructor?
    foo = options.foo || ''
    return foo
  }
}

And there are issues with the receiver target. In Rust you can specify self, &mut self &self

impl Foo {
  fooRef(&self) {}
  fooMutable(&mut self) {}
  fooOwned(self) {}
  staticFoo() {}
}

Applying that to classe methods is a bit tricky.

For the first version of the language, I will use structs because I know I need them for FFI use cases but I will exclude methods until I have spent more time thinking about how I want to represent them. Maybe classes are not the right choice here.

One thing I like about structs in Go is the ability to compose them

type Foo struct {
   foo string
}

type Bar struct {
   bar string
}

type FooBar struct {
  Foo,
  Bar
}

So I think the final state will drop classes land somewhere between Rust and Go structs.

Version 1

So I am starting to write a compiler for BorrowScript. This first version of the compiler will compile to C which will then be compiled with GCC (might work with clang too). It will eventually target LLVM but at this stage, I'm more familiar with C and I feel I can move faster on a POC that way.

I have no idea how to write a language server so this first version will ugly looking text files, haha.