🎉I am writing these notes in my new project — Brick, a magical mystery no-bullshit thingy. Writing goes much faster when I don't have to hit “Publish” or do
git commit. Live editing feels effortless.Try it out at Brick.do.
Rust's goals are in the first section of its FAQ.
Rust is meant to be a safe, concurrent, "practical" systems language. I'm not sure what practical means, but probably "optimized for writing production code" (as opposed to e.g. research or teaching languages).
To design and implement a safe, concurrent, practical systems language.
Rust exists because other languages at this level of abstraction and efficiency are unsatisfactory. In particular:
- There is too little attention paid to safety.
- They have poor concurrency support.
- There is a lack of practical affordances.
- They offer limited control over resources.
Rust exists as an alternative that provides both efficient code and a comfortable level of abstraction, while improving on all four of these points.
I think Rust achieves its goals well. It could do better by giving up "control over resources", but those are the goals so I won't judge.
Go's goals are trickier to find. I had to resort to Rob Pike's talk from 2012, Go at Google: Language Design in the Service of Software Engineering:
Go is a programming language designed by Google to help solve Google's problems [...]
The goals of the Go project were to eliminate the slowness and clumsiness of software development at Google, and thereby to make the process more productive and scalable. The language was designed by and for people who write—and read and debug and maintain—large software systems. Go's purpose is therefore not to do research into programming language design; it is to improve the working environment for its designers and their coworkers.
Very blunt — that's cool.
Hard to evaluate from the outside, especially since I'm not familiar with Google's culture. E.g. all of the following factors heavily influence language design:
Different answers, different designs.
Note: you might object that Google should be "thinking long-term" or whatever, and Go is not a "long-term thinking" language. This is not the point of the exercise. The goals are whatever they are. I am not trying to judge the goals here.
Swift's goals, from their about page, are vague. They want a language "built using a modern approach", and they want to cover everything: systems, mobile apps, desktop apps, and cloud services.
My guess is that Apple wants a single language for their whole ecosystem (compare this to Google, who wants a language for their internal use).
Despite saying "most importantly, Swift is designed to make [...] correct programs easier", this is only the third point in the blurb. The first two points are: "modern", and "for everything". They brag about "an innovative feature known as optionals", and "you don’t even need to type semi-colons".
They also have a "Server Work Group" as the only entry under "focus areas" on their homepage. This is why I think Apple started with "we want an Objective-C replacement for writing apps", and ended with "we want a single modern language for the entire ecosystem". This is why they start with "modern" and close with "integrate well, build quickly, excellent diagnostics, interactive experiences". Unlike with Go, attracting mindshare is one of Swift's goals.
Swift is a general-purpose programming language built using a modern approach to safety, performance, and software design patterns.
The goal of the Swift project is to create the best available language for uses ranging from systems programming, to mobile and desktop apps, scaling up to cloud services. Most importantly, Swift is designed to make writing and maintaining correct programs easier for the developer. To achieve this goal, we believe that the most obvious way to write Swift code must also be:
Safe. The most obvious way to write code should also behave in a safe manner. Undefined behavior is the enemy of safety, and developer mistakes should be caught before software is in production. Opting for safety sometimes means Swift will feel strict, but we believe that clarity saves time in the long run.
Fast. Swift is intended as a replacement for C-based languages (C, C++, and Objective-C). As such, Swift must be comparable to those languages in performance for most tasks. Performance must also be predictable and consistent, not just fast in short bursts that require clean-up later. There are lots of languages with novel features — being fast is rare.
Expressive. Swift benefits from decades of advancement in computer science to offer syntax that is a joy to use, with modern features developers expect. But Swift is never done. We will monitor language advancements and embrace what works, continually evolving to make Swift even better.
Tools are a critical part of the Swift ecosystem. We strive to integrate well within a developer’s toolset, to build quickly, to present excellent diagnostics, and to enable interactive development experiences. Tools can make programming so much more powerful, like Swift-based playgrounds do in Xcode, or a web-based REPL can when working with Linux server-side code.
TypeScript folks have had the courtesy of writing their goal on the first screen of its homepage: "JavaScript that scales." From an interview with the architect of TypeScript, Anders Hejlsberg:
For the last five years we've increasingly heard from customers and internal teams [at Microsoft] about how hard it is for them to write large JavaScript applications.
Here's also a recap of a video from Microsoft's Channel 9, along the same lines:
Lucco cited the Bing Maps team as one that has encountered difficulties in making JavaScript scale. He also mentioned that the TypeScript team has worked with the Office 365 team. (He didn't specify what that team is doing with JavaScript, but it's likely connected to the development of Office Web Apps, the Webified versions of Word, Excel, PowerPoint and OneNote.)
That's it. They wanted a more scalable JavaScript and they got it. I think this is the clearest goal so far, and the most well-executed. Bravo.
Scala is tricky. No explicit design goals, but plenty of history.
Martin Odersky wanted a better Java, see The Origins of Scala:
So after that time, when essentially the focus of my work was to make Java better, I decided that it was time to take a step back. I wanted to start with a clean sheet, and see whether I could design something that's better than Java. But at the same time I knew that I couldn't start from scratch. I had to connect to an existing infrastructure, because otherwise it's just impractical to bootstrap yourself out of nothing without any libraries, tools, and things like that.
Odersky wasn't a project manager. He was a professor at EPFL. He was also friends with Philip Wadler, and before Scala they did a language called Pizza together:
Phil told me that a wired-in assistant in his group had heard that there was a new language coming out, still in alpha stage, called Java. This assistant told Phil: "Look at this Java thing. It's portable. It has bytecode. It runs on the web. It has garbage collection. This thing is going to bury you. What are you going to do about it?" [...] The answer was that Phil Wadler and I decided take some of the ideas from functional programming and move them into the Java space. That effort became a language called Pizza, which had three features from functional programming: generics, higher-order functions, and pattern matching.
Then Odersky, Wadler, and some other folks did Generic Java, which was like Java, but with generics. And then, while still a professor at EPFL, Odersky designed Scala.
It looks like there was no specific goal, just "let's use the language as a vehicle to research solving as many integration problems between FP and OOP as possible". From The Goals of Scala's Design:
The first thing we cared about was to have as clean an integration of functional and object-oriented programming as possible. We wanted to have first-class functions in there, function literals, closures. We also wanted to have the other attributes of functional programming, such as types, generics, pattern matching. And we wanted to integrate the functional and object-oriented parts in a cleaner way than what we were able to achieve before with the Pizza language. That was something we deeply cared about from the start.
[...] So as we developed Scala, we started to discover how we could mix objects together with traits and mixin composition, how we could abstract the self types, how we could use abstract type members, and how we could let this all play together. Up to then there had been a couple of research languages that addressed a few of these aspects in specialized ways, but there wasn't much in terms of mainstream languages that covered the whole spectrum of making it all work.
Again, Odersky is not a project manager. He's a professor. Scala lets him research a ton of diverse technical issues that arise when you try to create a FP-OOP hybrid that runs on the JVM, and earn money doing that, and have fun running a community, and provide a language to a bunch of people who want an advanced Java and are capable of using Scala. I think this is a pretty cool mix.