Hacker News new | past | comments | ask | show | jobs | submit login
Stanza: A New Optionally-Typed General Purpose Language from UC Berkeley
117 points by patricksli on May 20, 2016 | hide | past | favorite | 77 comments
Hello Hacker News!

We're happy to announce the first public release of the Stanza programming language! Stanza is a new optionally-typed general purpose programming language from the University of California, Berkeley. It was designed to help programmers tackle the complexity of architecting large programs and significantly increase the productivity of application programmers across the entire software development life cycle. You can check out the website here:


Here are three really cool things about Stanza:

1. It is both statically and dynamically typed. If you give no type annotations, Stanza behaves like a scripting language. The more type annotations you give, the more errors Stanza will catch upfront.

2. It has a class-less object system. We believe in both object oriented programming and functional programming, and designed Stanza's object system to seamlessly incorporate both styles.

3. It has a really powerful coroutine system called targetable coroutines. It's a general control flow construct that can be used for fine control over concurrency, and is useful for things like video games and webservers.

We've already been using Stanza internally for about two years now. Using Stanza, we've designed a hardware language called FIRRTL, designed a teaching language called Feeny for teaching a graduate course on virtual machines, wrote a tool for automatically generating circuit boards for robotics, and (as upstanding computer scientists) wrote the entire Stanza compiler in Stanza itself.

Now, Stanza is stable and mature enough for us to feel confident to share it with everyone. We hope you'll check it out!

   - The Stanza Team

"Stanza compiles directly to native code and runs faster than any scripting language because it does not suffer any interpretive overhead."

Show us your benchmarks.

A comprehensive benchmark suite is in the works.

L.B. Stanza stands for "Li Bai's Stanza". Li Bai was an acclaimed Chinese poet who lived from year 701 to 762. He was known particularly for his mastery of "regulated verse", the most rigorous verse form of his time. [...]

Maybe you meant "Du Fu's Stanza"? Correct me if I'm wrong, but as far as I know, Li Bai is renowned particularly for his mastery of unregulated old-style (gushi 古詩) forms instead... Du Fu, on the other hand, was an indisputable master of regulated verse.

Li Bai was no slouch in the lushi form either. And I'm just a big fan myself.


What was the problem you were trying to solve when you decided to create Stanza?

Google Go's story was that they wanted a lowest-common-denominator language for use by their mixed-skill-level development pool. C was written so that some games could be ported to minicomputer... And so on.

First and foremost, Stanza was designed for myself, to solve the problems that I repeatedly face in my own programming.

I mostly write software that is end-user-facing and interactive, with requirements that aren't known at the beginning of the project. Software that my mother would use, is how I typically describe them. e.g. Word processors, games, calendars, photo albums, spreadsheets, maps, movie players, etc.

And what I saw repeatedly, for all of my projects, was that progress comes a lot faster in the beginning than near the end. Eventually, I pinpointed the problem to one of software architecture. It is easy to see the required architecture for the start of a project, and making progress is easy. As you pile on demands and features, you realize that the architecture that you started off with is wrong, and progress slows. This is especially true if the requirements of your program are not known in advance. I expect people that mostly program well-known and stable algorithms don't have as much difficulty with this. E.g. numerical linear algebra, schedulers, image filters, etc. That is not what I write.

Once you realize that your architecture is wrong, you have two choices. You can either plow ahead with a sub-optimal architecture, and take a small but continual productivity hit. Or you can try to refactor and correct the architecture, and take a large one-time productivity hit. Neither approach is satisfactory. Small continual productivity hits eventually add up to the point that forward progress is seriously impeded. Refactoring also costs a lot of time, and eventually the cost of refactoring becomes too great to be worth it, and you're stuck with the last good enough architecture that existed.

So Stanza was designed to make it possible for me to : 1. Experiment easily without specifying upfront the class inheritance tree in the program. 2. Delay committing to a specific architecture for as long as possible. 3. Refactor the underlying architecture of a program through small local changes.

And for the programs that I write, I sincerely believe that I succeeded. I've been programming exclusively in Stanza for about three years now, and I haven't yet ran into the dreaded "refactor-or-abort" situations that arise often in Java/C++ programming. Radical changes to the underlying architecture of a program are possible by applying a series of small staged local changes. And the optional type system allows me to get a lot of features working without having to commit to an architecture, so that when I finally sit down to properly design the architecture it is much more likely to be correct.

So my ultimate goal with Stanza is to help you achieve a linear rate of progress across the project timeline. You should feel as productive near the end of the project as you did in the beginning of the project.

But I had the opposite experience - slow in the beginning of the project and productive near the end of the project. I had this pattern even back in my university assignments.

The colons are not necessary here, and not in python, either. It was blindly copied from the ABC language (designed in the 70s for complete novices), where it made a little more sense because all keywords were in all caps and thus harder to read.

Looks quite nice. Initial impression is julia + python whitespace + zero indexing. The type system seems more fleshed out than julia's.

I thought the same, although there appears to be some white-space rules that I think would quickly become a nuisance to me, I'm referring here mainly to the mandatory space before certain semicolons, after the brackets in main etc. although I suspect there are more.


  defn main () :

The only whitespace rule that users really need to know is that "f(x)" is a syntactically different thing than "f (x)". Similar to how "fg" is a syntactically different thing than "f g" in other languages.

Don't get me wrong, I see the reasoning, my comment was just me musing on how I'd have to break the habits I've learnt from other languages.

Mhm, very sensible choice. We also recently started disallowing `f (x)`, it just ends up causing way more trouble than it's worth.

It's like Dylan with infix macros and a more sophisticated type system. Or infix Common Lisp with CLOS.

Cool on it being self-hosting. I watched Chisel with cautious interest pretty closely, so FIRRTL looks pretty interesting to me. You guys mention you've taped out ~10 IC designs - does that mean a total of 10 revisions of say, 2 or 3 base designs? From the docs I've skimmed it the projects goal is purely to target Verilog, right? How extensive is the LVS (you mention "weak equivalence testing" so I presume that's not LVS-as-defined-by-graph-isomorphism and you still need to use Cadence/Mentor/whatever?). Which fab and process did y'all use and ultimately how much time do you think you saved compared to the standard 'take the building blocks that TMSC gives you' route ?

edit: This was in reference to FIRRTL's FAQ[1] which mentions the 10 tape outs, and such. Do you guys have open-source netlists or whatnot?

[1] http://www.eecs.berkeley.edu/Pubs/TechRpts/2016/EECS-2016-9....

I (and Adam Izraelevitz) designed FIRRTL together, but for questions about Chisel, the authors frequenting the Chisel GitHub page would have far better answers than us. Please check it out! They did awesome work!

It might be worth adding to the summary that this compiles into native machine code. Using its own code generator, by the looks of it --- that's hard core! But it doesn't look like there's an optimiser yet.

Plus it's fully self-hosting, too; the sign of a properly grown up language.

Self-hosting was a pretty hard choice to make early on, but it turned out to be one of the best decisions we ever made. It forced many semantic issues to the surface, gave us a gigantic test-suite for free, and, most importantly, forced us to use our own language. We ended up cutting a lot of features that turned out not to be very helpful from the experience of writing the hosted compiler.

They do say that when you go self-hosted quickly, you end up with a language that's good at writing compilers :)

We merged most of the comments from https://news.ycombinator.com/item?id=11722126 and re-upped this post, which was actually posted three days ago. We did that because (a) this one was posted by the project creator and (b) the discussion here had higher initial quality.


I'm curious if you ran into any performance issues with partiality typed programs as described in [1]?

[1] http://blog.acolyer.org/2016/02/05/is-sound-gradual-typing-d...

We're still working on a paper on comprehensive performance measurements, but we don't expect to see the same slowdown.

Very intentionally, we called Stanza an "optionally-typed" language instead of a "gradually-typed" language. The moniker "gradual typing" was coined by Jeremy Siek and implies a very specific semantics and implementation style. One of the drawbacks of gradual typing is that obtaining good performance can be tricky.

Stanza does not use the same system, and we are not seeing the same problems. But the experiments and paper are still in progress.

I am liking the look of this language. It looks very modern, and neither a retread nor outlandishly experimental or hacky.

What it would need to start feeling viable:

More documentation about implementation details, e.g. runtime environment, memory allocation model. "Ground-up" engineering info.

Some key libraries for a target application domain - web, gaming, etc. The "best option for X" approach.

Ability to deploy Stanza into other environments: Source to source, an easily implemented bytecode format, etc. The "parasitic" approach.

Thank you for taking a look. We also believe in a "batteries-included" approach and are, in order of priority, writing interfaces from Stanza to:

1) The QT gui library.

2) The GLFW OpenGL and input events library.

3) Some networking library.

4) Some regex library.

The current compiler generates x86-64 assembly code, but we're working on refactoring that and abstracting it to make it easier to write more backends. We are aiming particularly for a Javascript backend for webapps and an ARM backend for mobile apps.

There seems still a long way to go. Write some deeper documentation on language philosophy, implementation and interesting examples to show its strength in solving a particular problem. Get the language features stablized and then allow other contributors to develop libraries as Go and Nodejs went. Choose a niche market to create a community.

Get working regex and networking libraries out first, GUI/3D later.

I expect to see it first useful in scientific and engineering domain. I wish to see an example for easily solving constraint optimization such as hospital staff scheduling. If it can demonstrate easy problem solving in AI/machine learning/data science, then it would be a good start to attract followers..

> The QT gui library.


Well done, looking into it now.

Edit: holy mother of god the philosophy page is so scarily close to my thoughts, very happy to see this happen, I kept them in my head you have implemented it!

Thanks for the kind words. The philosophy statement is not just fluff, it was the driving force behind all of Stanza's design. We hope you check it out!

This looks great. I'm not sure if the optional type system is particularly novel, TypeScript[0] introduced optional typing a few years ago, although it compiles down to JavaScript.

I'm still excited to see it being a feature of a brand new language, and everything else about this language seems very exciting to me!

[0] http://www.typescriptlang.org/

TypeScript, Dart, and Stanza all started attacking optional typing at around the same time.

Our approaches differ though. Stanza believes fundamentally in nominal typing as opposed to structural typing, and also views types as contracts on its behaviour rather than on its structure.

Only time will tell which approach is the best one. But we are very happy with how our design choices have panned out.

Stanza looks very interesting. I'll have to check it out. Thanks!

Shen allows you to turn the type checker on or off:

(tc +)

(tc -)

You can leave your type signatures in the code when you turn them off, and when tc is on you only need a type in the top level of your function.

It has a fully functional Prolog engine built in, and it supports optional lazy evaluation too.

Great talk by Aditya Siram Sept 2014 Strange Loop talk introducing Shen [2]. Shen has been ported to many languages, since it only requires porting the 46 primitive instruction set, called Klambda. Shen has been ported to CL (SBCL), Ruby, JavaScript, Haskell and even Emacs Lisp.

[1] http://shenlanguage.org/ [2] https://www.youtube.com/watch?v=lMcRBdSdO_U

Thanks for clarifying the difference - I'm very excited to see where Stanza is used and where it goes.

Dylan [1] has a very similar type system to Stanza and has been around for a while. Stanza looks a lot like what a modern incarnation of Dylan would look like.

[1] http://opendylan.org/

Dylan was way ahead of its time.

Now is the time to bring many of its contributions into the light again.

Looks great. Does it support parallelism? What does the standard library provide beyond collections and built-in functions?

We have a very powerful concurrency mechanism but no support for physical parallelism yet. What this means is that it is easy to write programs containing many things that seem like they're happening simultaneously (eg. video games and multi-user web servers), but you don't get a speed boost for having multiple processors yet.

The standard library currently only provides basic IO, primitive types and collections. We will be attaching a gui library, opengl library, networking library, and regex library soon.

Under the documentation section for "Ambiguous Methods"[0], why does the example compile? I would expect it to barf at compile time, not runtime.

[0] http://lbstanza.org/chapter4.html#anchor52

In julia we switched to making method ambiguities a runtime error because you often end up with situations where even though there are ambiguous methods, you don't ever really want to call them (because they don't make much sense semantically or because they came from different packages, etc). Stanza looks a little more static than julia in this regard, so perhaps they do want to make it a compile-time error (or at least make calling it a compile-time error if types are declared).

We are planning to add a static method ambiguity check in Stanza.

There are just some theoretical hurdles to solve in order to detect them properly in the presence of parametric types. That's been recently solved (though not by us) so we'll be implementing their solution soon.

Hi Patrick, can you point to a paper / resource that describes this recent work?

Sure. The paper is called "Type Checking Modular Multiple Dispatch with Parametric Polymorphism and Multiple Inheritance" by Allen, Hilburn, et al.

I love it.

I grabbed and tested it out on OSX and Linux Mint.

Its design is eerily close to that of my own hobby language, but better developed. Maybe I should abandon the hobby and just use Stanza.

Didn't see a repl, though, or an emacs mode. I'm gonna need those.

How is this language different to these languages:

- http://nim-lang.org/

- http://crystal-lang.org/

- http://elixir-lang.org/

These other 3 are also small languages doing interesting things, and although Elixir is obviously much different (being more functional than the others), just like Stanza, these seem to be in the same/similar domain.

The immediate difference is that Stanza is optionally-typed while those three are all purely statically-typed. A dynamically-typed language behaves very differently than a statically-typed language with type inference. For example, Scheme is a very different language than OCaml, even though type annotations are not required for either. In this sense, Stanza is designed to compete against both Python/Ruby as well as Nim/Crystal/etc...

Cool, downloaded it and successfully ran the sample programs. Going through the book now, maybe it's be but might be good to also point out that indents are three spaces and if you just press tab, it doesn't compile.

Thanks for trying it out. We'll make a note to point out the restrictions on tab characters earlier.

This seems like a next gen language.


I've created an (unoffical) IRC channel #lbstanza on freenode if anyone is interested http://webchat.freenode.net/?channels=lbstanza&nick=

Now it's official. I'll add an announcement to #lbstanza on the website.

Is there any package manager / distribution system a la pypi / npm currently or in the works?

It's in the works. We recognize that it is an important part of a modern language.

Does it do word-wrap?


What is the rationale behind this?

don't use tabs. Stanza won't let you. We don't like tabs.

From our experience using Python, structure through indentation when coupled with the ability to mix tabs and spaces creates many troubles. Getting rid of tabs was a small price to pay to eliminate these issues.

Okay! Makes sense, thanks. I can't quite place it but I do feel there is something big here! Congrats guys.

I'm eagerly awaiting for someone to add Stanza to the myriad languages at https://learnxinyminutes.com/. Cheers!

Hi Patrick, this looks great! I'm glad there are more people exploring this design space. Language design is tough business, but it's also amazingly fun ;).

Thank you Keno! Congratulations on Julia Computing LLC as well. In a past life, I studied machine learning, and often wished there was a better alternative to Matlab.

Can you please make code examples show up in monotype font on the web page?

On my browser (Chrome on Ubuntu), it shows as a non-monotyped font which is much harder to parse.

Yes. We just realized that as well. We're currently using a font called Menlo that isn't on every platform. We'll be replacing it with more widely available font.

This looks very nice. Is there any editor support yet (Emacs, vim)? Or do you currently just edit Stanza files in text mode?

James Martin wrote a VIM Stanza syntax highlighter. It's not on the webpage yet, but a quick google search will give you it.

Writing modes in Emacs lisp is a little more daunting and we have yet to do it.

A link would have been nice.

We can make the post use the URL, but then the introductory text that patricksli posted would be lost.

patricksli, if you want to post your text as a comment, we can swap the URL later.

Hmm. I can't seem to get the url formatter working.

No windows support? Shame.

We're working very very hard on that right now. It'll be out in a few weeks.

Glad to hear it, if you're targeting gamedev(which I see a note about) that's where the majority of your users will be.

Congratulations Patrick, very impressive!

Thanks very much!

I would have preferred the name 'Costanza.'


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact