Skip to main content

Inflight Magazine no. 2

Β· 9 min read
Elad Ben-Israel
Revital Barletz

The 2nd issue of the Wing Inflight Magazine.

Hi there!

We're excited to share with you the second issue of the Wing Inflight Magazine (here's a link to our first issue if you missed it).

The Inflight Magazine is where you can stay up to date with Wing Programming Language developments and the awesome community that is forming around it.

You received this email because we have you on our list as someone who might be interested to stay informed about the Wing Programming Language.

As always, we would love to hear what you think. Feel free to reply directly to this email, mention @winglangio on Twitter or ping us on slack.

TL;DR​

Here is a summary of the topics in today's issue:

We are hiring! Check out our two open positions:

TS;GMM (too short; give me more)​

Check out the latest Wingly Update episode​

The Wingly Update is a live show we are streaming on Twitch. We mostly make fools of ourselves, talk about the latest developments of the project, bring guests and more.

In our last show, Eyal hosted Elad, Cristian and the infamous Mark the DJ.

We talked about:

  • Immutable by default
  • Customize infrastructure using compiler plugins
  • Create composable clour abstractions
  • import and use CDK libraries
  • Realtime visualization of your cloud applications

If you didn’t get a chance to catch it live, you can tune in here and check out our next shows on Twitch.

User stories are now published to our doc site​

Our user stories are working backwards documents that tell a story about someone in the future and what they can do with Wing. They contain detailed descriptions of where we want to be at the end of each iteration of the project. Stories are part of our development process as they allow us to track our progress, provide feedback, and ensure that we are always focused on the end-to-end experience. By reviewing the stories, you can actually see the evolution of the project.

For example, we are now working on User story #15 which includes support for using JavaScript libraries in Wing, the cloud.Api resource, a Redis resource and interface declarations.

Wing Console gets a new map view​

The Wing Console is a desktop application that can be used to interact with Wing applications and its resources on the local machine. One of the biggest challenges of the console is how to visualize a complex real-world cloud applications. In the latest release, we've leveraged the ELK layout algorithm to create an interactive map of the resources generated by Wing so and visualize the resource hierarchy and their connections.

With this new map view, you can visualize both the static structure and the data flow of your cloud application at a glance. Cloud resources are connected to each other depending on usage, giving you a clear view of the dependencies and interactions between different parts of your application.

map-view

Wing Console adds support for log filtering​

We've also added a log filtering feature to help you easily filter logs by keywords or levels.

logs-filtering-level

Check out this video for more details and usage:

### Compiler errors and the "blue screen of death"

When the console compiles your Wing code in the background, if it encounters compiler errors, we now display them in a view that is a homage to the Windows Blue Screen of Death. File locations are links and will jump right into your IDE.

Here's a short video:

User-defined resources​

The most important aspect of a programming language is it's composition primitives. Wing has a special type of classes called "resources". Resources are an object-oriented representation of a cloud service that is part of the application. For example cloud.Bucket is a resource that represents an object storage. In essence, they are the cloud-oriented version of a class, but with unique capabilities that allow them to represent both infrastructure and code.

So far, resources were only available as part of the Wing SDK, but now it is possible to declare resources in Wing and create reusable building blocks. Similarly to functions and classes, resources can be used to organize your code into logical units, shared, reused and in the future also published into independent libraries.

One key aspect of user-defined resources is their ability to define an "inflight API". This is done by adding the inflight modifier to methods or fields. The inflight execution scope is essentially the runtime API of the resource, while the preflight execution scope represents the resource's configuration and initialization.

In the following example, we are declaring a resource called DoubleBucket. When an object is put() into the resource it will be replicated into two buckets.

bring cloud;

resource DoubleBucket {
a: cloud.Bucket;
b: cloud.Bucket;

init(a: cloud.Bucket, b: cloud.Bucket) {
this.a = a;
this.b = b;
}

inflight put(key: str, obj: str) {
this.a.put(key, obj);
this.b.put(key, obj);
}

inflight get(key: str): str {
return this.a.get(key);
}
}

let left = new cloud.Bucket();
let right = new cloud.Bucket();

let r = new DoubleBucket(left, right);

new cloud.Function(inflight (s: str): str => {
r.put("hello.txt", "world");
});

Within that resource, you can see the concept of an inflight modifier on both the put() and get() methods. If you need a reminder of the terms inflight and preflight, read the spec or the inflight functions section in our docs.

This example demonstrates how user-defined resources can create composable units that allow for the creation of higher-level abstractions.

There are many capabilities that user-defined resources open up, and you can read more about them in the language specification, as well as in specific issues and pull requests related to the feature. The separation of the inflight and preflight scopes is a particularly interesting aspect of this feature, and there is ongoing work to refine and optimize this separation.

If you would like to see it in action, Yoav Steinberg created a video that demonstrates how to create user resources:

Introducing new types to the language​

We are still enriching the Wing Language Specification and increasing the set of features we believe are required to build cloud applications with Wing.

We added support for for..in (#1412) as well as the duration and datetime types (#1470). There are also duration literals minutes (e.g 5m), seconds (e.g. 10s), and hours (e.g. 5h).

Let's take a look at a quick example:

let timeout = 5m;
assert(timeout.seconds == 300);

let now = Datetime.utcNow();
print("It is now ${now.month}/${now.day}/${now.year} at ${now.hours}:${now.min}:${now.sec})");
assert(now.timezone == 0); // UTC

let t1 = DateTime.fromIso("2023-02-09T06:20:17.573Z");
print("Timezone is GMT${d.timezone() / 60}"); // output: Timezone is GMT-2
print("UTC: ${t1.utc.toIso())}"); // output: 2023-02-09T06:21:03.000Z

JSON support​

JSON is the data protocol of the cloud, and every cloud application deals a lot with it. We believe that being able to work with JSON in a native and safe way is a natural part of Wing being a "cloud-oriented language". One of the ways we're achieving this is through our concept of the json type.

Wing is a statically-typed language while JSON is dynamically typed. So we need a way to safely bridge between the worlds. To support this, Wing types will have a fromJson() static method which will allow move from the unsafe world of JSON to the safe world of static typing.

Contrary to how JSON works in TypeScript or JavaScript, the fromJson() methods have built in schema validation, which means that if a call succeeded, developers can be certain that the designated type is correct.

This will also work for structs (which are still not supported):

struct Contact {
first: str;
last: str;
phone: str?;
}

let j = Json { first: "Wing", last: "Lyly" };
let myContact = Contact.fromJson(j);
assert(myContact.first == "Wing");

We want to make sure that Wing is a great application and service development programming language that prioritizes safety and static typing, without sacrificing usability.

copy and copyMut​

Our built-in collections now have copy and copyMut functions πŸ’ͺ (#1427). These functions allow you to easily convert between the mutable and immutable collections. We had an interesting discussion around what to call these functions and decided to align them with our philosophy of immutable by default. This means that when you don't specify something, it's by default immutable. Even when you copy a mutable collection using the copy function, you will get an immutable version. We believe this is a good start for these functions and look forward to seeing how they will benefit your development projects.

Thanks our contributors!​

We are thrilled to see pull requests keep popping up from:

@Kasey Abu-Rayyan, @Marcio Cruz, @Raphael Manke, @Eric Johnson,
@Joshua Dando, @Yariv Levi, @Ananthu C V, @Raywon Kari, @Salman Abid, @Vanja Oljaca, and @Perpil. From small fixes and improvements to the language, the SDK and the compilers, to proof of concepts such as a β€˜naive implementation of counting semaphore’ using wing by @EJwang.

Summary​

As usual, we're excited for anyone to join our journey to make the cloud a better place to build software. We constantly hang out on Slack, and if you haven't done so already, check out winglang.io and take Wing for a spin.

See you on our next flight!