Project abandoned?

[mindplay-dk]

It's been a year since the last commit, and a year-and-a-half since @evanw last replied on gitter.

I have been thinking about forking the project and starting development myself, but I'd really like to know if this project has any official status, or what the plan is? I don't want to start working on it, possibly taking it in a completely different direction than what was intended by @evanw, and then have all my work go to waste if activity on this project does resume.

Since there's no roadmap, I can't really know the intentions of @evanw and would really prefer that, if I were to work on this project, that my efforts wouldn't be potentially wasted.

@evanw if you intend to work on the project again eventually, but don't know whether or when that will actually happen, would you consider adding a roadmap please? If you would open (smaller) issues for others to work on, you might encourage people to actually help out, maybe get the ball rolling again.

I think it's really sad for this language to just sit on a shelf and collect dust.

The simplicity and elegance of this language, the fact that it's bootstrapped, it's web-oriented design, the potential for wasm support, the excellent IDE support - I look at every new language I can find, and don't feel like I find this exact combination of qualities in any other language.

I remain baffled at the fact that so few people took notice of this language. From the chatter on Gitter, GitHub and Reddit, I got the impression that a lot of people felt as I do, that this could be the simple, pragmatic web language they've been waiting for - but I'm guessing a lot of people dismiss it based on either "too young" or "no activity", or both. Well, one of those is fixing itself, but... ;-)

I'd really like to see this language take off.

Well, it's MIT licensed, so I guess I could just fork it and run away with it - it would be really nice to know which direction the original author was intending to go though...

[evanw]

Sorry for the lack of communication. I'd really like to see this project take off too! A few things happened. I've got a really involved job as a co-founder of Figma and over the past year I've been using my spare time to do R&D for Figma on some exciting new performance-related initiatives. I also have gotten into a wonderful long-term relationship that has reduced the amount of time I spend on side-projects.

For what it's worth, Skew is alive and well at Figma and new Skew code is written every day. There just hasn't been any development on the compiler because it's been working perfectly for us without needing any changes.

I've always envisioned the end goal for Skew as a self-hosted language that can compile to efficient native code (WASM included). I'd like for Skew's toolchain to be light-weight and completely self contained. Unlike LLVM, that means it would be trivial to cross-compile binaries for all supported platforms from a single platform. This is probably most similar to Go's toolchain. My primary driver towards this is my personal desire to have an awesome cross-platform toolchain like this exist with a good language on top.

Once Skew got to the stable state it's currently in, I started exploring several different aspects of native code generation that needed design. Memory management was one factor. The current C++ code generator uses a garbage collector, but it didn't feel right for a few reasons. Another factor was that I had added exceptions to the language and those make a native back-end harder. Yet another thing is that debugging the resulting native code would be really hard as the language currently stands. I was unsure how to resolve these issues so I paused development.

I've now got some time to work on this again and it feels like it's coming together. Here's my current thinking:

• Do memory management with automatic reference-counting and weak pointers. This should be able to work everywhere (the current GC relies on the "fork" syscall, which doesn't work on Windows) and won't get slower as the heap grows larger. This would be most similar to Swift's approach.

• Use an SSA-based IR instead of an AST-based IR. This will make optimizations easier, especially reducing redundant reference counting operations.

• Remove null as it currently exists. Null dereferences are a well-known language misfeature. In addition to the standard issues it causes, null would make it really hard to debug native code since you wouldn't be able to break into the debugger and inspect local state until I implement debugging. Right now I'm thinking of either using an "optional" type or adding nullable types to the type system. Union types are another possible solution. The high-level change would be that the compiler requires you to check for null somehow before accessing nullable types.

• Add modules and imports to the language. I feel like this is necessary to make the language scale to larger projects. It should also make it easier to build a community-contributed package system on. Adding modules and packages might mean that namespaces make less sense, so those may be removed.

• This will require a rewrite. Complex features such as lambdas and exceptions will start off not being present. I'd like to work up to lambdas but still have to think through what that means with reference counting. I'm not sure what to do about exceptions at the moment although I have some interesting ideas.

• I've also been wondering if it makes sense to keep the OOP-based design or to use something more like type classes for polymorphism. It is a very elegant solution and has worked out really well in Rust, for example.

• XML literals are cool as they are now, but I feel like they would be a lot more helpful for people if they just did exactly what React did. I'd like to think through that design space so I'll likely pull them for now.

• There are some really cool opportunities for Skew around multiprocessing and concurrent computation. My hunch is that there's a clean and safe design for this using an actor model and compiler support for message passing using immutable/unique values. This would be something to explore after the native code part is solid.

I got a prototype with reference counting and a simple SSA-based IR working over this past break and am pursuing that to see where it leads.

Given the scale of these changes, I'm not sure what to do about the current state of this project. The compiler has been developed so far by pretty much always introducing backwards-compatible changes. But this change as it's currently stated won't be backwards-compatible by any means. I always intended to get to native code generation before Skew 1.0 (that's why it's only at 0.7.42). This definitely requires a major version bump but would of course greatly hinder people using the current language (Figma included) so just saying "Skew 1.0 is here!" feels wrong. I could potentially spin off the old project as "Skew Legacy" or something.

What do you think? Both about the overall direction proposed here and the potential paths forward.

[mindplay-dk]

XML literals are cool as they are now, but I feel like they would be a lot more helpful for people if they just did exactly what React did.

Typescript adopted a React-specific approach - at the time when that arrived, I was already not liking the fact that a purported language feature was actually, in truth, just language-level support for a single, specific framework, with a very specific approach. At the time, I actually tried to convince Typescript maintainers that they should do something more generic along the lines of Skew - please read my feature request / rant which actually mentions Skew.

Since then, other frameworks have emerged, and the JSX syntax has proliferated to many other (more lightweight) frameworks besides React, and I'm not as opposed to it as I used to be - or perhaps, rather, I've had to get used to it, since it's the only real option in Typescript, which I use daily.

While popular, the approach is pretty solidly geared towards the React way of doing things - as a generic language feature, I find it pretty constrained. It works well for the virtual DOM diff/patch model, but it works poorly for just about any other approach - far too many React-like frameworks require a custom build-time Babel transform, implementing a different interpretation of the JSX syntax.

I would have much rather we had a language feature that was flexible enough to satisfy more than just the React approach. Since so many are implementing their own JSX transforms, perhaps something macro-like?

(Nim might be interesting for inspiration on that subject - it has really powerful macros, and a versatile core language syntax that enables you to practically extend the language with custom features and in-language transforms, while still maintaining IDE support for everything emitted by the first pass of the compiler.)

I got a prototype with reference counting and a simple SSA-based IR working over this past break and am pursuing that to see where it leads.

😍

What do you think? Both about the overall direction proposed here and the potential paths forward.

I think I have two concerns.

First, will it still be simple? It sounds like you're building a new systems programming language, and those have a tendency to turn out anything but simple. I love that Skew has a reasonably small codebase that I can actually read. Presumably this new language will also be bootstrapped?

My other concern is it sounds like this language may not be "web first", but more "machine first"? You mention Rust and Swift - definitely both of those are "machine first" and "web second".

Since you first created Skew, I think "web first" could have take on a somewhat of a new meaning thanks to WASM - one of my great hopes for WASM, is the potential to unite the server-side and client-side of web-applications. Apart from being cross-platform with close-to-native performance, WASM means we can compile once, deploy and run the same binaries on the client and server, which could change the meaning of "web development" entirely.

I think, now more than ever, a web-first language makes sense - I personally would be more than happy with a language that targets JS and WASM, and nothing else, even with the current constraint of being single-threaded. It would be great to plan for multi-threading, of course, but for the majority of web apps right now (perhaps 95%) multi-threading isn't critical - servers can simply run a thread pool equal to the number of CPUs, and single-threaded projects are much easier to reason about. For real-time (game/video/audio) applications on the client-side, eventually a web language will need to deal with threading, but I don't think most people will expect it before it arrives in WASM?

Targeting WASM rather than native should lead to a much simpler language back-end too? The simplicity of Skew is a big part of the attraction for me - not just the simplicity of the language, but the implementation of the language. Almost no PHP/JS/Ruby/Python (etc.) developers are able to contribute to the monster-size, super complex codebases in languages that aren't accessible (or are otherwise uninteresting) to them.

The idea of a language that it's users can actually contribute to, is so powerful.

Anyways, I'm stoked to see where this goes next :-)

[mindplay-dk]

@evanw have you see the V language?

The first and only other language that comes close to approaching some of your ideas, I think - with a native compiler target for machine code, even, which is really interesting and gives incredibly compile speed.

You had such a beautiful vision for this language. I really hope to see it revived some day 😢