Haha, I read it as rechargeable. I hoped that meant that it would somehow inject new functionality to avoid the ravages of time and not eventually be looked at like Cobol is.
The introduction mentions "view propagation", which does borrow checking without annotations. Is this documented anywhere?
Also, I wish more languages had homepages like the Go one[0]. It takes a lot of reading to get to the point where you can see some non-trivial code[1], which is frustrating.
I was thinking the same, the pages need redesign. The best way to make people try out a language is to give an example on the first page (without scrolling). It should be more than "hello world", e.g. 99 bottles of beer or Fibonacci numbers, anything that shows me how the language looks & "feels".
That being said, this looks like a really interesting and promising language. If the borrow-checker is unobtrusive and doesn't require ridiculous boilerplate, then you can count me in! Good work!
There's no technical reason the Rust borrow checker couldn't run without annotations either- that's a design choice, similar to the way Rust requires function types even though it could infer them. It makes inter-function contracts clearer, which improves error messages, and avoid the need for whole-program analysis.
I couldn't find anything more about "view propagation" either but I strongly suspect it's no more powerful. Probably less and/or buggier at this point, given its relative maturity.
Thanks, so lifetimes can definitely be inferred for safe code (although just like type inference, they can lead to leaky abstractions). But aren't lifetime annotations necessary for unsafe code? How could you cast a pointer into a struct into a raw pointer and back, while preserving the lifetime, without them?
What I would be very interested in seeing in an introduction to a new language is an explanation of why the authors think other languages that intend to support a similar combination of features have failed to achieve that or have failed to get traction.
These kinds of introductions always read like "we're going to combine these and these and these awesome features from all your favorite languages" and well, what's not to like? Wouldn't everyone want this? So I can't help but wonder: why didn't anyone previously succeed at creating such a language? What are you going to do differently?
This answer will not satisfy you, but I can answer this as someone who worked on design and implementation of multiple programming languages: Q. why didn't anyone previously succeed? A. Nobody tried.
There are a LOT of decisions that go into design and implementation of programming languages. Due to combinatorial explosion, vast majority of combination was never tried. This is still true even after you group "similar" combinations. But usual standard of similarity used by many people is "How is Rust different from Go?", which is too laughable to answer. To me, Scopes seems different enough that the author should not feel any need to answer questions like yours.
I'll add to your answer that a lot of them aren't production-worthy either. That might be the packaging, lacking a standard library, not integrating with whatever is dominant in that space, no docs on basic usage, and so on. This happens with verification tools in CompSci, too.
So, they need to get a combination of features to whatever is the minimum of usability the target audience expects. I also push for it to integrate well with legacy libraries with no overhead. Scope author is doing that for C libraries. As a side effect, it's a big boost on productivity since people can always lean on whatever libraries are already there.
I was gonna say - I already have a language with the expressivity of Scheme, the convenience of Python, and the performance of C - it's called "Chez Scheme". Why isn't it popular? Because A) the performant implementation was proprietary until relatively recently, and B) it's less "batteries included" and more "that drawer in your house full of batteries, most of which are dead". There's a great language in there, but it lacks the tooling and social structures for popularity.
Racket is being ported to Chez Scheme. That might solve the batteries included problem at least at the Racket level. However, if you don't like Racket, then I don't know if it will do anything since using Racket's libraries in Chez might be too kludgy to attempt.
Since you're a Chez fan, I'll also throw in its historical overview in case you missed it. That they had Scheme on 8-bitters really tripped me out. Talented team.
The bar for a new programming language is higher than ten years ago.
Introducing a language should now include "What are the cool new things in this language?" The short list where this shines, e.g., "Go - compiles really fast and no classes". "Rust - deep safety and a novel macro system". "Python - Batteries included and easy to write."
A language also needs to include some design philosophies. Sometimes its simple: "DRY"; sometimes its the tradeoffs ordered in Zen of Python. You need to say something.
With no direct disrespect intended towards these authors in particular, I'll believe "expressivity of Scheme with the convenience of Python, Lua or Javascript and the performance of C" when I see it. Goals aren't results. I've seen that goal a lot. Given how often I've seen it, and how I'm yet to see a result that matches it, I'm coming around to the assumption that that set of goals is probably just not possible. (I suspect Python, Javascript, etc. are fundamentally, in their very core, based on some operations and conveniences that are just fundamentally going to be slow on modern processors. The only way around it is to drop some of the conveniences. That I have seen be successful.)
On the "goals aren't results" front, the second one is also one that I'd want to see how it plays out a bit more before getting too excited; it's also possible that it may not be possible at it currently exists in the author's heads.
Out of curiosity, the docs state that closures are supported as zero-cost abstractions. That seems to imply that the language can store environments at zero cost. How is that possible?
It does not imply that. Closures are usually implemented with environments, but this is unnecessary. You can compile so that everything that would be in the environment is passed as arguments. It seems to me Scopes is implemented this way.
> C/C++ requires programs to be built and linked before they can be executed. For this, a build system is typically employed.
> In contrast, Scopes’ primary execution mode is live, which means that the compiler remains on-line while the program is running, permitting to compile additional functions on demand, and to use other services provided by the Scopes runtime library.
> However, Scopes can also build object files compatible with GCC and Clang at runtime using compile-object, which makes it both suitable for classic offline compilation and as foundation for a build system.
