Ask HN: Interest in a Rust-Inspired Language Compiling to JavaScript?

[taosx]

Hello HN,

I'm considering the development of a new programming language, drawing inspiration from Rust's strengths, with a focus on compiling to JavaScript. Here what I'm considering are some key features:

- Strict Typing System: no type-related bugs.

- Algebraic Data Types.

- Exhaustiveness Checks.

- 'Unsafe' Mode: Directly interact with external JavaScript/TypeScript.

- no 'null/undefined': Option/Result instead.

- Trait-Based Programming.

- Backend Development Focus.

- Compiler: dead-code elimination and partial evaluation, similar to Prepack[0] (by Facebook).

I believe this approach could bring significant benefits, especially with recent additions like TypedArray and worker threads.

Would this be of interest to the community? Looking forward to your insights and discussion.

Currently I don't feel confident to complete the project as I am so any recommended resources[1] would be extremely helpful, especially around the area of implementing types.

[0] https://github.com/facebookarchive/prepack

[1] https://github.com/taosx/axido (nothing is decided)

[jraph]

(I'm interested in programming languages, my comment is asking questions because I'm curious, I'm not questioning the project)

You mention a focus on backend development. Why suffer having to compile to JS if you are not restricted by the runtime environment? (in the backend, surely you can run anything). In my understanding, compiling to JS is only interesting when you want to run in the browser, but outside this constraint, JS seems like a less than ideal compilation target (though probably way better than before thanks to the presence of typed arrays).

Is it interoperability with the JS ecosystem? Wouldn't the no null/undefined criterion be a barrier to this? Or will you take any result from a call to a JS function as optional? Or have interfaces saying "I promise, I will never return null/undefined"?

Or you still want your language to be able to run in browsers? In this case, will you provide a standard library (with the cost of having to transfer it every time it's used), or only a thin wrapper around native JS functions?

You say Rust-inspired. For me, one of the most interesting features of Rust is the explicit management of the lifetime of objects. How do you intend to handle this aspect, with JS not having anything like this?

[taosx → jraph]

Interoperability: I believe we can do interoperability by selectively wrapping the necessary imports in 'unsafe'. From there, it's up to the implementer to decide whether to handle it as a 'Result' or an 'Option'.

Browser, Std lib: Yes, the language should still be able to run in the browser and will provide a std but will not transfer each time, the benefit of writing a compiler would be that we can do dead-code-elimination and target native javascript methods instead of something like wasm.

Lifetimes: Honestly, currently I'm only working on the simplest transpiler but I would like to explore using typed arrays as the stack, heap.

[solardev → taosx]

What does it mean to have a backend-focused compiler that can make JS for the browser?

What's an imagined use case, here?

[jraph → taosx]

Thanks for your answer :-)

Good luck in your project and have a lot of fun.

[aslpavel]

There is already - PureScript - https://www.purescript.org/ - though it is closer to Haskell - ReasonML - https://reasonml.github.io/ - essentially ocaml with nicer syntax Both are strongly typed with algebraic data types

[taosx → aslpavel]

I like reason and rescript and I'm looking at them for inspiration but I'm not a fan of their async support. Still, I'm planning to write a lot more code in them just to understand them better.

[scotty79]

I'd really love to see a language with primitives for entity-component-system paradigm and convenient syntax for hierarchical finite state machines.

Just doing types, classes, interfaces again and again isn't really interesting.

Most interesting thing in Rust is not the type system or borrow checker but value semantics.

[austin-cheney]

Most developers in JavaScript struggle with asynchronous things. Instead they hope to solve everything with classes and when that fails they need frameworks to do anything. So, I recommend solving for that first instead of jumping into innovative syntax features.

My recommendation is to create a new language that’s focused exclusively on functions and how to organize them. Organization is an advanced skill learned from experience that is not immediately benefitted from high intelligence and most developers fail in that regard. Think in terms of lexical structures, events, return types, data structures, process flow (technical and business), and call stack.

If you can really dominate concepts of organization by language design the best supporting syntax innovations will shift to more specifically meet your needs.

[taosx → austin-cheney]

Are you referring to frontend mostly? Would a language like Elm be a good fit for what you're referring to in terms of organization?

One of the additional goals I have is to be able to write type safe APIs between frontend and backend similar to trpc (elysia framework).

[austin-cheney → taosx]

That does pose an interesting question. Why is the front end so much more reliant on frameworks? Is it the environment or the people doing the work? Regardless the problem and the result are often the same. The inability to organize logical structures as necessary to complete a flow of business processes hinders which goals one aspires to achieve.

In my experience writing large applications in JavaScript the front end (in the browser) and the back end are less different than people typically consider. It could be that many people struggle with the DOM, but anyways it’s all APIs and event handling.

[solardev → austin-cheney]

I'm sure there's a billion reasons for frontend frameworks not really worth debating here, but I was curious about this:

> It could be that many people struggle with the DOM, but anyways it’s all APIs and event handling.

Without a framework, how do you usually like to handle cross-component/cross-screen state in the frontend? Like where do you keep track of logged-in state, dark mode, the shopping cart, etc? Do you just like to put that in the backend, or is there a neat way to organize such data in vanilla JS in the frontend?

[austin-cheney → solardev]

I keep state in a single object. State management is ridiculously simple but people tend to make it more challenging than it needs to be. I then send the data stored in that object out of the browser as determined by the app for storage at the server. Restoring state is as simple as embedding the state data directly into the static html so that it’s always there as fast as possible every time the page is requested.

[solardev → austin-cheney]

Sounds like using "window" as a big global variable, but cached on the backend almost like a manual cookie?

Well typed, I'd imagine the dev ex would be similar to a monolithic React context. Seems like it'd work.

[techn00]

It seems like an awesome project, I'd say go for it, check /r/ProgrammingLanguages as well. However, typescript is "good enough" for the community, so I don't think it will take off in the sense that you mean.

[tim1994]

Sounds like an interesting project, but I think it's important to find a good way to interact with browser APIs. They all work differently, like rAF, geolocation, pointer lock, camera access and so on. I think relying on the unsafe mode for all that could lead to a frustrating experience but also implementing those APIs in a different way would be weird and you have to keep up with new APIs and changes browsers introduce. I suggest having an idea on how to solve this before spending a lot of time developing the actual language. If it limits what I can do with JS I would not use this and just stick with Typescript.

[taosx → tim1994]

The browser APIs would be part of a small std library wrapper. I quite like the approach taken by Roc[0] in regards to platforms so we can have either browser apis or node apis.

[0] https://www.roc-lang.org/

[pornel]

I'd like a thin compile-to-JS language with a Rust-like syntax, only because after writing Rust/Golang/Swift for a while, I keep forgetting to write parens in `if cond` and `for … in`. Suffix .await is a nice to have too.

I'm not so sure about implementation of Rust's semantics in JS. If I want exact Rust semantics, I can use WASM.

[taosx → pornel]

That's the plan for the initial prototype. My goal is to advance beyond this stage to generate optimized JS. While it's going to be less readable than handwritten js/ts, the trade-off would be performance boost.

From recent experiences in profiling and optimizing different backend apps, I'm confident that imposing some constraints on JS we can get noteworthy improvements on the performance front better or equal to golang. Here's a subset of the constraints I'm looking at:

- Avoid out-of-bound reads in arrays and monomorphization.

- Manage memory allocations. (pools)

- Implementing inlining, also done by V8 and JSCore.

- Keep variables close to usage context.

- Being picky about standard js operations.

- Using 'new Array(n)' for creating longer arrays, and '.push()' for smaller ones but if frequently calling methods on an array, avoid preallocating.

- Avoid arrays with holes, prefer using arrays with numbers.

- Use cached prototypes for object creation.

- Avoid working with strings as much as possible, use typed array when possible.

- Partial evaluation.

ps: Thank you for all your work in the Rust ecosystem, I've used a lot of your crates over the last year.

[vinniepukh]

As another commenter has already suggested, ReasonML has a lot of what you described here.

However, modern JS-oriented toolchain for ReasonML is called ReScript and you can learn more here: https://rescript-lang.org/

[az09mugen]

I don't think it's a rust-inspired language, but since it has strong typing and compiles to javascript, did you give a look at nim [0] ?

For what it takes, it can inspire you and I find the language very expressive and flexible.

[0] : https://nim-lang.org/

[anticrymactic]

While an improvement to js is _always_ welcome. I am worried about the "debuggability". How do you plan on generating the js efficiently?

I HATE most js frameworks for this reason. Understanding/Tweaking websites is something I do extensively, and obfuscated minified recursive js makes this REALLY hard.

[eternityforest → anticrymactic]

Dart is nice because you can do your dev work in the IDE where you get a great debugger.

I don't like how low level Lit components are, but one thing I do appreciate about them is how little there is getting in the way of using a debugger, which is probably my biggest complaint with reactive frameworks.

[aristofun]

> no 'null/undefined': Option/Result instead

Another theoretical fantasy that has nothing to do with real world.

In real world we do have null and undefined values. It is artificial and redundant to pretend that there isn’t.

[continuational]

I'm working on such a language! https://www.firefly-lang.org/

It's aimed at full stack programming, not exclusively backend.

[aristofun]

> Strict Typing System

Please stop right here.

Real world is not a theorem.

We, down to earth developers, have had enough of this over engineered crap. We need flexibility.

There is already a near perfect language for JS.

It’s called Typescript.

Youd make a much more good for the world if you improve it, fix few issues etc.

[_randyr]

Gleam?