DEV Community: Codlook

LOOK 1'den LOOK 2'ye: neler değişti

Codlook — Mon, 12 Oct 2026 09:56:06 +0000

LOOK, web için yapılmış kendi dilimiz. LOOK 1 bugün yayında olan sürüm (1.0.x). LOOK 2v2` dalında geliştiriliyor ve henüz yayınlanmadı. Bu yazı ikisi arasındaki farkı anlatıyor: neyi, neden değiştirdik ve LOOK 1 ile yazılmış bir uygulama için bu ne anlama geliyor.

Kısa cevap şu: LOOK 2 yeni özellik yığını değil. LOOK 1'de "bazen öyle, bazen böyle" davranan yerlerin her birine tek bir cevap veriyor ve sessizce yanlış sonuç üreten davranışları ya düzeltiyor ya da hataya çeviriyor.

Neden gerekti?

LOOK 1'i gerçek uygulamalarla sınadıkça üç tür sorun tekrar tekrar karşımıza çıktı:

Paylaşılan veri. Diziler ve map'ler referansla paylaşılıyordu. Bir fonksiyona verdiğiniz dizi, o fonksiyon içinde değişince sizin elinizdeki de değişiyordu. Web sunucusunda bunun en kötü hali, bir isteğin verisinin başka bir isteğe sızmasıydı. 1.0.3, 1.0.4 ve 1.0.5 sürümlerinin üçü de bu sınıftan hataları tek tek yamadı.
İki motor, iki davranış. LOOK'ta hızlı bir sanal makine (VM) ve onun yanında bir yorumlayıcı var. Aynı kod bazı durumlarda ikisinde farklı sonuç veriyordu: fazla argümanla çağrı birinde hata, diğerinde sessizce kabul; blok içinde tanımlanan değişken birinde görünür, diğerinde değil.
Sessiz geri düşüş. VM bir şeyi çalıştıramadığında uygulama haber vermeden yorumlayıcıya geçiyordu. Sonuç doğruydu ama yavaştı ve gerçek hataları gizliyordu.

LOOK 2'nin ölçütü basit: her sorunun tek bir cevabı olsun ve hiçbir şey gizli kalmasın.

1. Diziler, map'ler ve struct'lar artık değer

En büyük değişiklik bu.

php $a = [1, 2, 3] $b = $a $b[0] = 9 # LOOK 2: $a hâlâ [1, 2, 3]. LOOK 1: $a da değişirdi.

Atama, fonksiyona verme ve fonksiyondan döndürme, alan tarafa kendi değerini verir. Bu her derinlikte geçerli.

Bunun bedeli kopyalama değil: atamada kopya yapılmaz. Değer yalnızca hâlâ paylaşılırken üzerine yazıldığında kopyalanır. Büyük bir diziyi yalnızca okuyan bir fonksiyona vermek hiçbir şeye mal olmaz.

Kırılan kalıp, parametresini değiştirip geri döndürmeyen fonksiyondur:

php function add_total($order) { $order["total"] = 42 } add_total($o) # LOOK 1: $o'da "total" var. LOOK 2: $o değişmedi.

Doğrusu, değeri döndürüp atamak:

php function add_total($order) { $order["total"] = 42 return $order } $o = add_total($o)

Bu, sessizce geçebilecek tek değişiklik olduğu için raporlanıyor: dosya yüklenirken bir uyarı satırı çıkar, lk --check aynı bulguyu hata olarak verir ve bir derlemeyi durdurabilir.

Aynı kuralın iki sonucu daha var:

== içeriği karşılaştırır. İki dizi, map ya da struct aynı şeyi tutuyorsa eşittir. LOOK 1'de diziler ve map'ler için sonuç her zaman false idi.
Paylaşmak için tutamaç kullanılır. Kanallar, WebSocket/SSE bağlantıları ve veritabanı bağlantıları değer değil tutamaçtır; kopyası aynı şeye işaret eder. İstekler arasında bilinçli paylaşımın yolu budur.

2. Closure değeri yakalar

Bir closure, yakaladığı şeyin oluşturulduğu andaki değerini alır ve onu değiştiremez.

php $n = 1 $f = fn() => $n $n = 2 $f() # LOOK 2: 1. LOOK 1: 2.

Yakalanan değişkene closure içinden yazmak (atama, +=, ++, push) artık yükleme hatasıdır; program başlamaz. Yeni değeri döndürüp dışarıda atarsınız. Sonradan dışarıda yapılan değişikliğin closure'a yansımaması ise sessiz bir farktır; lk --check bu yerleri satır numarasıyla listeler.

LOOK 1'deki istekler arası sızıntıların arkasındaki kalıp buydu: closure'ın paylaşılan bir değişkeni değiştirmesi. LOOK 2'de bu kalıp yazılamıyor.

3. Struct'lar: tipli alanlar, sabit şekil

plaintext struct User { name string age int = 18 score ?float # null olabilir tags array }

Tek yazım biçimi var: ad tip, isteğe bağlı = varsayılan. LOOK 1'in iki eski yazımı artık ayrıştırma hatası.
Tipler denetlenir, hem oluştururken hem her atamada.
Şekil sabittir. Bildirilmemiş bir alanı okumak ya da yazmak hatadır. LOOK 1 okumada null döndürür, yazmada alanı sessizce eklerdi.
Varsayılansız alan sıfır değeriyle başlar (int 0, string "", dizi boş). LOOK 1'de null idi.
Struct dizi değildir. count($s) ve array:: fonksiyonları struct üzerinde hatadır.
Bir struct bir kez, dosyanın en üst düzeyinde bildirilir.

4. Okuma, çağrı ve kapsam: tek kural

[...] ile okuma. Olmayan anahtar null verir. null'dan okumak null verir, bu yüzden $row["address"]["city"] ?? "" zinciri özel bir kurala ihtiyaç duymaz. Ama bir string'i ya da sayıyı indekslemek hatadır: bu eksik değer değil, yanlış tiptir. LOOK 1'de bu, kodun hangi motorda çalıştığına göre değişiyordu.

Çağrı. Bir fonksiyon, bildirdiği argümanlarla çağrılır. Fazla ya da eksik argüman hatadır. LOOK 1'in varsayılan motoru fazlayı atıyor, eksiği null yapıyordu.

Kapsam. Blok içinde ilk kez atanan değişken blok bitince yok olur; bu artık dosyanın en üst düzeyinde de geçerli.

Küçük eklemeler. $count["views"]++ ve ++$cart.items artık çalışıyor. ++ ya da -- ile başlayan satır kendi başına bir ifadedir.

5. Web tarafı

Rota parametreleri ada göre verilir. route("GET", "/c/{id}/{slug}", function($slug) {...}) LOOK 1'de $slug'a sessizce id'yi veriyordu. Artık her parametre aynı adlı yol parametresini alır; rotada olmayan bir ad uygulamayı başlangıçta durdurur.
Olmayan bir fonksiyonu çağıran rota uygulamayı başlangıçta durdurur. string::uper(...) gibi bir yazım hatası LOOK 1'de ilk isteğe kadar fark edilmiyordu.
İş işleyicisi true ya da false döndürür ve yeniden deneme bekler. LOOK 1'de return yazmayı unutmak "başarısız" sayılıyor ve iş hemen yeniden çalışıyordu; bir e-posta üç kez gidebiliyordu. Artık yeniden denemeler 30, 60, 120 saniye arayla yapılır.
İş işleyicileri ve zamanlayıcılar kendi isteklerinde çalışır. Bir rotanın içinden başlatılan işleyici artık o isteğin parametrelerini okuyamaz, yanıtını değiştiremez.
Varsayılan 404 düz metindir.
WebSocket/SSE bağlantılarında yerleşik sınır yok. Sınırı işletim sistemi koyar. (Bu, 1.0.15 ile LOOK 1'e de geldi.)

6. Motor: her şey VM'de

LOOK 1'de web uygulamasının bazı parçaları her zaman yorumlayıcıda çalışıyordu: WebSocket ve SSE işleyicileri, zamanlayıcılar, iş işleyicileri, kendi dosyalarını dahil eden komut satırı betikleri. LOOK 2'de bunların hepsi VM'de.

Hedef tek motor: VM bir uygulamayı derleyemiyorsa uygulama başlamaz ve nedenini söyler. Yorumlayıcı yalnızca testlerde karşılaştırma için kalır. Bu iş sürüyor; bugün lk --vm-report çekirdek modüllerdeki 228 fonksiyonun hepsinin VM'de bulunduğunu doğruluyor.

Ölçtüklerimiz

Aşağıdaki rakamlar bu bilgisayarda, Docker içinde ölçüldü. Her biri tek bir senaryo içindir; genel bir "şu kadar kat hızlı" iddiası değildir.

Ölçüm	LOOK 1	LOOK 2
Açık WebSocket bağlantısı başına sunucu belleği	yaklaşık 38 KB	0,89 KB
700 bin açık WebSocket	400 binde 11 GB, belleği yetmedi	618 MB, hepsi açık
Döngü ağırlıklı bir iş işleyicisi	4,2 sn	0,08 sn
Dosya dahil eden, döngü ağırlıklı komut satırı betiği	3,7 sn	0,07 sn
Şablon ağırlıklı sayfa, uçtan uca	2,7 bin istek/sn	12 bin istek/sn

Bağlantı ölçümü yalnızca boşta duran bağlantıları kapsıyor ve tek koşudur; mesaj trafiği altında ölçülmedi.

LOOK 1 uygulamanız için ne anlama geliyor?

LOOK 2, LOOK 1 ile uyumlu değil; bu bilinçli bir karar. Ama değişikliklerin çoğu kendini belli eder:

Yükleme hatası: program başlamaz, mesaj satırı söyler. (Eski struct yazımı, closure içinden yazma, rotada olmayan parametre adı.)
Çalışma zamanı hatası: ifade hata verir, mesaj nedeni söyler. (Yanlış argüman sayısı, bildirilmemiş alan, string'i indeksleme.)
Sessiz: program çalışır ama farklı sonuç verir. Dikkatle okunması gerekenler bunlar: değer semantiği, closure'ın değeri yakalaması, ==, varsayılansız alanların sıfır değeri, rota parametrelerinin ada göre verilmesi.

Geçişte ilk adım, uygulamanın her dosyasında lk --check çalıştırmak. Parametresini değiştirip döndürmeyen fonksiyonları, sonradan değişen yakalanmış değişkenleri ve yanlış argüman sayılarını satır numarasıyla listeler.

Her değişikliğin tam listesi, ne göreceğiniz ve yerine ne yazacağınızla birlikte docs/migrating-to-look-2.md dosyasında. O dosya her değişiklikle aynı commit'te güncelleniyor.

Şu an neredeyiz?

LOOK 1 yayında ve güvenlik düzeltmeleri almaya devam ediyor; son sürüm 1.0.15.
LOOK 2 v2 dalında. Yukarıdaki dil kuralları yerinde ve her biri iki motorda testli. Yayın için kalan iş, kurulumun da tamamen VM'de çalışması, yani tek motor hedefinin tamamlanması.
LOOK 2, uygulama tamamen VM'de çalıştığında yayınlanacak. `

LOOK: A Web Programming Language Built Around the Web

Codlook — Sun, 13 Sep 2026 19:10:40 +0000

LOOK: A Web Programming Language Built Around the Web

Modern web development has become incredibly capable — but it has also become increasingly layered.

A typical application may involve a programming language, a web framework, a package manager, database drivers, middleware libraries, authentication libraries, a process manager, a reverse proxy, build tools, configuration files, and a large dependency tree.

LOOK takes a different approach.

LOOK is a web scripting language written in C++23, designed specifically around web application development.

Instead of being a general-purpose language with web capabilities added later, LOOK puts the web at the center of the language.

Routing, databases, sessions, JWT, validation, caching, WebSockets, SSE, concurrency, testing and other web-oriented capabilities are integrated into the LOOK runtime.

The goal is simple:

Make building and deploying web applications simpler without giving up performance, security or control.

What is LOOK?

LOOK is not a web framework for another language.

It is a programming language and runtime designed for web applications.

A minimal LOOK application can look like this:

use jwt

app::set("db", db::connect("mysql://root:@127.0.0.1/mydb"))

route("GET", "/products", function() {
    $rows = db::query(app::db(), "SELECT * FROM products", [])
    response::json(["ok" => true, "data" => $rows])
})

route("GET", "/ping", fn() => response::json(["ok" => true]))

route("POST", "/login", function() {
    $body = request::json()
    $token = jwt_sign(["id" => $body.id], env("JWT_SECRET"))

    response::json(["token" => $token])
})

The syntax is deliberately compact.

LOOK supports:

fn() => ... arrow functions
optional semicolons
$row.col property access
modules with use
route groups
middleware
path parameters
JSON APIs
HTML templates
database access
authentication
WebSockets
SSE

For example:

route("GET", "/ping", fn() => response::json(["ok" => true]))

is enough to expose an HTTP endpoint.

Not Just a One-File Language

One important misconception about LOOK is that it is designed only for tiny one-file applications.

It is not.

A .lk file can run independently, which makes scripts and CLI tools convenient.

But real applications are structured into multiple files.

A typical project can look like:

myapp/
├── index.lk
├── config/
│   └── app.json
├── views/
│   ├── layout.html
│   └── product.html
└── ~/.look/modules/
    ├── model/
    │   └── model.lk
    └── util/
        └── util.lk

The entry file wires the application together.

Configuration, templates and reusable modules can remain separate.

This makes LOOK suitable for applications that grow beyond a prototype.

A Language Designed Around the Web

Many programming languages started as general-purpose languages and later developed large web ecosystems.

LOOK starts from the opposite direction.

The web is one of its primary design targets.

That means common web requirements are treated as language/runtime capabilities rather than a collection of unrelated framework components.

For example:

route("GET", "/users/{id}", function($id) {
    $user = db::query(
        app::db(),
        "SELECT * FROM users WHERE id = ?",
        [$id]
    )

    response::json([
        "ok" => true,
        "data" => $user
    ])
})

The route, database interaction and HTTP response are all part of the same environment.

Databases Without a Traditional Driver Stack

LOOK supports:

MySQL
MariaDB
PostgreSQL
SQLite

The relational database protocols are implemented inside the LOOK core rather than depending on separate external database drivers.

The project's CI tests database compatibility against multiple real database versions.

The current documented matrix includes MySQL 5.7 through 9.x, MariaDB 10.11 through 12.x, PostgreSQL 14 and 18, and SQLite 3.47.2.

For example:

app::set("db", db::connect(env("DB_DSN")))

route("GET", "/products", function() {
    $products = db::query(
        app::db(),
        "SELECT id, name, price FROM products ORDER BY id DESC",
        []
    )

    response::json([
        "ok" => true,
        "data" => $products
    ])
})

Parameterized queries are part of the normal database API.

This reduces the amount of infrastructure an application needs to assemble before it can start serving requests.

Authentication and Web APIs

LOOK includes functionality for common API applications such as:

JWT
sessions
cookies
request validation
middleware
rate limiting
JSON responses

A route group can share authentication middleware:

$auth = function() {
    if (request::header("X-Api-Key") != env("API_KEY")) {
        response::json(["error" => "forbidden"], 403)
        stop()
    }
}

route::group("/admin", [$auth], function() {
    route("GET", "/users", function() {
        response::json(["ok" => true])
    })

    route("DELETE", "/users/{id}", function($id) {
        response::json(["deleted" => $id])
    })
})

The objective is to make common API patterns part of the language's natural development model.

WebSockets and Server-Sent Events

Modern applications are not limited to request/response APIs.

Real-time functionality is increasingly common:

dashboards
chat systems
notifications
monitoring
live status pages
collaborative interfaces

LOOK includes WebSocket and Server-Sent Events support.

This means applications can use the same runtime for conventional HTTP endpoints and real-time communication instead of introducing an entirely separate service for every communication model.

Concurrency

LOOK also provides concurrency primitives including:

parallel()
channels
FastCGI multi-worker execution

The runtime is designed around a persistent process model rather than starting a completely fresh interpreter for every request.

That design has an important performance benefit, but it also creates responsibilities for developers.

Global state must be handled carefully, and code must be thread-safe where concurrency is involved.

LOOK documents this trade-off explicitly rather than hiding it.

Performance

Performance is one of the reasons LOOK was created.

The project includes its own benchmarks.

According to the current repository benchmark:

direct-port HTTP throughput is around 9,800 requests/second in the documented test
a database-heavy QR-menu JOIN benchmark over 50,000 rows reached 2,837 req/s
the comparison was against PHP 8.3 + JIT + FPM at 2,184 req/s
LOOK used approximately 9–29 MB RAM
PHP used approximately 43–47 MB RAM

The database benchmark used the same host, schema and query, with controlled CPU and memory limits and equal pool sizes. The repository also explicitly notes that individual runs can be noisy, so these numbers should be treated as project benchmark results rather than universal performance guarantees.

That distinction matters.

A benchmark number without methodology is not particularly useful.

The more interesting question is:

Can a web language maintain low overhead while performing realistic application work?

LOOK is attempting to answer that question through repeatable project benchmarks.

Runtime Architecture

LOOK is implemented in C++23.

Its architecture includes:

Source (.lk)
      │
      ▼
    Lexer
      │
      ▼
    Parser
      │
      ▼
     AST
      │
      ▼
Bytecode / Execution Engine
      │
      ▼
   LOOK Runtime
      │
      ├── HTTP
      ├── WebSocket
      ├── SSE
      ├── Database
      ├── Sessions
      ├── JWT
      ├── Cache
      ├── Concurrency
      └── Other Web Services

The project contains both execution paths and supporting infrastructure for its runtime and test systems.

The persistent runtime model is an important architectural decision.

It avoids treating every HTTP request as an entirely new process/interpreter lifecycle.

But this also means that LOOK applications need to be written with persistent state and concurrency in mind.

Single-Binary Deployment

One of the strongest ideas behind LOOK is deployment simplicity.

A LOOK application can be deployed as a binary rather than requiring a large runtime installation and dependency tree.

The official repository documents deployment through:

Linux
Windows
Docker
CGI
FastCGI
Plesk

A Docker installation can start a LOOK server with:

docker run -p 8080:7400 codlook/look

And an application can be mounted into /app.

This creates a particularly simple deployment model:

Application
    │
    ▼
 LOOK binary
    │
    ├── HTTP
    ├── Database
    ├── WebSocket
    ├── Sessions
    └── Runtime

Instead of:

Application
   +
Framework
   +
Runtime
   +
Package manager
   +
Database drivers
   +
Multiple libraries
   +
Process configuration

the goal is to make the runtime itself provide the common foundation.

Security Is Part of the Runtime

Performance without security is not useful.

LOOK includes security-oriented functionality such as:

parameterized SQL
request body limits
secure session token generation
HttpOnly/SameSite cookie defaults
PBKDF2-SHA256
upload magic-byte validation
SHA-256
HMAC
secure random generation
WebSocket masking enforcement
rate limiting
file sandboxing
parser depth protection

The project also reports using:

AddressSanitizer
UndefinedBehaviorSanitizer
ThreadSanitizer
fuzzing
regression testing

The protocol parsers are implemented in the project itself and kept in a centralized area to make the attack surface easier to inspect.

This is particularly important for a language whose runtime handles networking protocols directly.

The Trade-Offs

LOOK is still an evolving language.

It is important to talk about what it does not solve yet.

The current project documentation explicitly identifies several limitations.

For example, the module system currently uses the LOOK module directory rather than arbitrary relative imports such as:

include "./lib/foo.lk"

The persistent-process architecture also means that global state and thread safety require more discipline than in a request-reset model such as traditional PHP-FPM.

The embedded mail server is still an evolving part of the project.

SMTP has substantially more functionality, while the current IMAP implementation is explicitly a Milestone 1 implementation and does not yet provide the persistent UID behavior required by common desktop and mobile mail clients.

These are not hidden limitations.

They are documented engineering constraints.

That is important for an emerging programming language.

Compatibility and the 1.x Line

LOOK also has a compatibility policy for its 1.x series.

The documented mod::fn API is intended to remain stable throughout 1.x.

Breaking changes are intended for a future major version rather than being silently introduced into a 1.x release.

At the same time, the project distinguishes between true breaking changes and bug fixes.

Security-default hardening can also be introduced within the 1.x line when the previous default is considered unsafe, with an explicit opt-out documented where appropriate.

This is a practical approach for a young language that is still defining some semantic edge cases.

Real Applications

LOOK is not limited to benchmark examples.

The project currently demonstrates several applications running through a single LOOK process, including:

Blog

Posts, administration, categories and cover image uploads.

QR Menu

A restaurant menu with a REST API and route listing.

Chat

Nickname, emoji and near-real-time messaging.

Products

Products, categories, brands, variants and additional attributes.

AI

An API integration with in-memory conversation state.

These examples demonstrate an important aspect of the project:

LOOK is intended to be used for complete web applications, not only isolated API benchmarks.

The Ecosystem

The LOOK core is intentionally kept separate from optional integrations.

The project maintains separate repositories for modules and packages.

The current package ecosystem includes integrations such as:

Firebase
iyzico
PayTR
Stripe
S3
Sentry
Netgsm
QR
PDF
image processing
monitoring
TCMB

This allows the core language to remain focused while application-specific integrations can evolve independently.

Why Build Another Programming Language?

This is probably the most important question.

Why not simply use PHP, Go, Node.js, Python, Rust or another established language?

Because the goal is not simply to create another syntax.

The goal is to explore a different architecture for web development.

LOOK asks:

What happens if the web is treated as a first-class environment of the programming language instead of a collection of frameworks and libraries around it?

That question affects everything:

syntax
runtime
deployment
database access
HTTP
concurrency
security
testing
package architecture
application structure

The result is intentionally different from simply adding another web framework.

LOOK vs. Traditional Web Stacks

A conventional stack might look like:

Language
   +
Web Framework
   +
ORM / DB Driver
   +
Authentication Library
   +
HTTP Library
   +
WebSocket Library
   +
Cache Library
   +
Package Manager
   +
Process Manager

LOOK attempts to move much of that foundation into the language/runtime itself:

                LOOK
                  │
       ┌──────────┼──────────┐
       │          │          │
      HTTP       DB       Security
       │          │          │
   WebSocket   Sessions     JWT
       │          │          │
      SSE       Cache     Validation
       │          │          │
       └──────────┼──────────┘
                  │
              Runtime

This does not mean external libraries disappear.

It means the foundation becomes smaller and more integrated.

Where LOOK Could Fit

LOOK is particularly interesting for applications such as:

REST APIs
SaaS backends
admin panels
dashboards
internal systems
CRUD applications
real-time applications
lightweight web services
API gateways
database-driven applications
small and medium business applications
self-hosted applications
applications where deployment simplicity matters

It can also be interesting for developers who want a language that feels closer to application-level web development than traditional systems programming.

What Makes the Project Interesting

The most interesting aspect of LOOK is not any single feature.

It is the combination.

A language implemented in C++23.

A persistent runtime.

Native HTTP functionality.

Built-in database protocols.

WebSocket and SSE support.

Built-in authentication primitives.

Low deployment overhead.

A relatively compact syntax.

A single-binary deployment model.

And an explicit focus on security and testing.

Those decisions reinforce each other.

LOOK Is Still an R&D Project

LOOK should not be presented as a finished replacement for every existing programming language.

That would be neither accurate nor useful.

It is an evolving programming language and runtime.

There are still areas that require development:

language semantics
ecosystem growth
module ergonomics
tooling
IDE support
documentation
platform maturity
deeper database functionality
mail protocol maturity
broader independent benchmarking
larger-scale production adoption

That is exactly what makes the project interesting from an engineering perspective.

The important question is not:

"Has LOOK already replaced everything?"

It clearly has not.

The better question is:

"Can a web-focused language reduce the complexity of modern web development while maintaining strong performance and control?"

LOOK is an attempt to explore that question seriously.

Getting Started

The fastest way to try LOOK is Docker:

docker run -p 8080:7400 codlook/look

Then:

curl localhost:8080

For a local source build, LOOK currently requires:

C++23
CMake 3.20+

The project provides CLI, CGI and FastCGI binaries.

The official repository also provides documentation for Linux, Windows, Docker and Plesk deployment.

Final Thoughts

The web development ecosystem has spent decades adding layers around programming languages.

Frameworks became larger.

Dependency trees became larger.

Build systems became more complicated.

Deployment became increasingly dependent on infrastructure knowledge.

LOOK explores the opposite direction:

What if the language itself provided more of the web stack?

Not through magic.

Not through an enormous framework.

But through a runtime designed specifically for web applications.

LOOK is still evolving, and its limitations should be taken seriously.

But the architecture is interesting enough to experiment with.

If the project continues to mature, the most valuable result may not be another framework.

It may be a different way of thinking about what a web programming language should provide by default.

Explore LOOK

GitHub:
https://github.com/codlook/look

Official website:
https://look.codlook.com

Documentation:
https://look.codlook.com/docs.html

Package ecosystem:
https://github.com/Codlook/look-packages

If you are interested in programming languages, web runtimes, C++ systems programming or alternative approaches to web development, LOOK is an interesting project to watch.