DEV Community: KentaroMorishita

What If Programs Were Mostly Just Values Flowing Through Functions?

KentaroMorishita — Sun, 16 Aug 2026 13:56:44 +0000

I've never particularly enjoyed reading code that makes me suddenly switch from following values to chasing control flow.

A variable gets assigned halfway through.

A function returns halfway through.

An if redirects the path.

Then the value gets another name.

None of this is difficult to understand.

But when I'm tired, I eventually end up asking:

"So where did this value come from, and where is it going?"

I started wondering whether it would simply be easier if the code showed how a value changes as it moves through the program.

TypeScript can already feel like this

For example, filtering, mapping, and reducing an array:

const total = [1, 2, 3, 4, 5, 6]
  .filter(even)
  .map(double)
  .reduce(add, 0)

I like this a lot.

The transformations are visible in order.

But once the value isn't an Array anymore, or ordinary functions need to enter the chain, method chaining stops being a universal model.

So we add a pipe helper or install a library.

Then there is another library-specific convention to learn.

This was one of the things I kept thinking about while I was building F-Box.

The old F-Box projects are still here:

https://github.com/KentaroMorishita/f-box-core

https://github.com/KentaroMorishita/f-box-react

In Seseragi, I wanted the value to keep flowing

The current Tour contains a sample like this:

import * as arrays from "std/array"

fn even value: Int -> Bool =
  value % 2 == 0

fn double value: Int -> Int =
  value * 2

let total =
  [1, 2, 3, 4, 5, 6]
  |> arrays.filter even
  |> map double
  |> reduce 0 (+)

pub effect fn main =
  println $ `pipeline total: ${total}`

That's basically it.

The value moves from left to right.

Filter it, map it, reduce it.

This isn't Array-specific magic.

|> is ordinary function application written in a way that makes the direction of the data easier to read. If the functions stay small, the same shape can keep going.

I like `$` for the same reason

Another operator I use constantly in Seseragi is $.

pub effect fn main =
  println $ `pipeline total: ${total}`

There isn't a grand theoretical claim hiding here. A lot of the time I simply want fewer parentheses.

Instead of:

println(foo(bar(baz(x))))

I would rather read:

println $ foo $ bar $ baz x

My eyes find that easier.

Maybe this is an age-related feature request.

But Seseragi pays a lot of attention to things that are theoretically small and practically visible every day.

I care more about making ordinary code pleasant than making unusual code impressive

When people hear "I made a programming language," it's natural to expect an exotic type system or some syntax nobody has seen before.

Seseragi does have things that sound intimidating when listed out: type classes, Effect, Signal, and so on.

But some of the parts that make me happiest are much more boring.

Write a function.

Give it a value.

Send the result to the next function.

Make ordinary processing feel ordinary and pleasant.

If that foundation is uncomfortable, adding sophisticated abstractions on top of it probably won't make the language enjoyable to use.

Play with it

https://seseragi.vercel.app/

Paste the sample above and try things like:

change even to value > 3
make double triple the value instead
add another map double
break the pipeline across lines
remove the pipeline and rewrite it as nested function application

That last one isn't a feature test.

It's a preference test.

But language design is, in the end, partly an accumulation of preferences like that.

Why Should the Language Change the Moment I Build a UI?

KentaroMorishita — Sun, 16 Aug 2026 13:56:42 +0000

In ordinary application code, I create values, pass them to functions, and distinguish between cases.

Then Web UI begins, and sometimes the whole world changes.

Component.

Hooks.

JSX.

Store.

Lifecycle.

Subscription.

All of these things exist for reasons.

I've used React and Vue for years, so this isn't an argument that they should all disappear.

But at some point I started wondering:

Why do I have to join a different programming religion the moment the thing I'm building becomes UI?

Couldn't a component just be a function?

In Seseragi's Web UI Tour, a small piece of UI can be an ordinary function:

fn status model: Model
  -> html.Html<Action> =
  html.p {
    id: "status",
    role: "status",
    children: model.status
  }

It receives model and returns Html<Action>.

That's it.

There is no special "declare a component" syntax here.

It's an ordinary function whose result happens to be Html.

I like that a lot.

Couldn't Html just be a value?

The same idea continues upward:

fn page model: Model
  -> html.Html<Action> =
  html.main {
    class: "mx-auto max-w-xl p-4",
    children: form model
  }

html.main is not a template-language escape hatch.

The props-like part is a record. children is a value. The resulting html.Html<Action> is a value too.

That means I can move it into an ordinary function, return it from match, combine it with other values, and generally keep using the language I was already using.

I think what I wanted was less "a convenient UI DSL" and more ordinary language features continuing to work all the way into UI.

Action is ordinary data too

The form in the Tour uses values such as:

DraftChanged String.

PinnedChanged Bool.

Submitted.

They aren't hidden inside a special event-system type.

They're ordinary data constructors, so ordinary match can handle them.

If you looked only at that part of the code, it would barely look like Web UI.

That's a feature to me.

I cover the state and Action code in other articles, so I won't paste the entire form sample again here. Repeating the same giant sample until every article looks identical would defeat the point.

If state changes, make it Signal

Of course a UI doesn't render once and freeze forever.

Inputs change. Buttons get clicked. State moves.

That's where Signal appears.

But I didn't want Signal to become "the UI framework's store," with a completely separate worldview attached to it.

If a value changes over time, model a value that changes over time.

Conceptually:

Model
↓
Signal<Model>
↓
map with an ordinary function
↓
Signal<Html<Action>>
↓
DOM

The responsibilities are different.

Model and Signal<Model> are not the same thing. Html and DOM are not the same thing.

But every responsibility boundary does not need to become a programming-model boundary for the user.

I'm not trying to build React again

Once Seseragi can render interactive Web UI, comparing it with React or Elm is inevitable.

Those comparisons can be useful.

But I didn't begin with "I want to build a React alternative."

Seseragi already had data types.

It had match.

It had ordinary functions.

It had Effect.

Then Signal.

Then Html as a value.

I connected those things, and eventually a Web application moved on screen.

That order matters to me.

It feels less like I placed a framework on top of the language and more like I kept using ordinary language features until the development experience started looking framework-like.

That's one of the strangest and most interesting parts of the project right now.

Try the form in the Playground

https://seseragi.vercel.app/tour/

https://seseragi.vercel.app/

Continue through the Web UI / feature-state part of the Tour and you can interact with a real form sample.

Good things to change:

add another Action
add another field to Model
change the status after submit
split form into smaller functions
switch the rendered output with match

In particular, try splitting the UI into smaller functions.

There is no extra "component mechanism" to think about while doing it.

You're just splitting functions, and the UI keeps composing.

That feels much better than I expected.

It's still experimental

Seseragi's Web UI and runtime are both still evolving, and the Playground is evolving with them.

I can't promise that the exact surface syntax will look identical six months from now.

But that is also why it's interesting to work on right now.

The question I started with was, "Why should UI make the language feel different?"

The current Seseragi answer is getting surprisingly close to something I like.

From here, I mostly need to keep using it.

And when something starts feeling ugly, change it.

That's more or less how this project works.

TypeScript Can Express Almost Anything. That's Part of the Problem.

KentaroMorishita — Sun, 16 Aug 2026 13:56:10 +0000

I like TypeScript a lot.

I've used it for a long time, and I still think it's incredibly useful.

So this is not an article about beating up TypeScript.

But after using it for years, I sometimes catch myself thinking:

It can express almost anything. Maybe it can express a little too much.

There is null.

There is undefined.

You can throw exceptions.

You have Promises.

You can make things mutable.

You can model state with as many booleans as you want.

Once React enters the picture, you can add JSX, hooks, stores, and whatever else the application needs.

All of those things exist for good reasons.

But "I can write this" and "this is how I want to write it" are not quite the same thing.

Take state, for example

This is perfectly normal TypeScript:

type State = {
  isLoading: boolean
  isLoggedIn: boolean
  hasError: boolean
  user?: User
}

It compiles.

It works.

But the type also admits something like this:

isLoading = true
isLoggedIn = true
hasError = true
user = undefined

What state are you even in?

Of course, the implementation can promise never to create that combination.

A reducer can enforce the invariant. Validation can enforce it. Tests can help enforce it.

But if the states I actually mean are only:

Loading
Guest
LoggedIn User
Failed Error

then I increasingly want to write exactly those four states from the beginning.

In Seseragi, I can start with the shape itself:

type Session =
  | Loading
  | Guest
  | LoggedIn User
  | Failed Error

Before working hard on control flow, reduce the number of states that can exist at all.

I find that much easier to reason about.

There is a whole separate article in this series about the shape of state, so I won't turn this one into the ADT article too.

Take "there might not be a value"

TypeScript has undefined and null.

Again, useful.

But they enter the world of ordinary values so naturally that it's easy to arrive somewhere later and realize, "Oh right, this was one of those values that might not exist."

Seseragi has Maybe<A>.

let name: Maybe<String> = Nothing

That one line tells me, at minimum, that name is not an ordinary String.

What I like is that "there might be no value" is visible directly in the shape of the type.

How to match it or map it is a separate question. I have another article for that.

If I paste the same Maybe example into three different articles, the articles themselves start becoming the ugly part.

Take the outside world

Sometimes I just want to make an HTTP request, but the implementation layer makes me think about Promises and async/await.

In a browser there is fetch. On Node there are other runtime details.

Those details matter somewhere.

But I started wondering whether the person writing Seseragi code should have to carry all of them every time they merely want to say, "this interacts with the outside world."

That line of thought eventually leads into Seseragi's Effect.

Maybe what I wanted wasn't restriction, but shape

While building Seseragi, I sometimes ask myself whether I'm trying to create a more restrictive language.

I don't think that's quite it.

I'm less interested in banning things than in being able to write the thing I'm thinking about in roughly the same shape that I'm thinking about it.

If there are four states, write four states.

If a value may be absent, use Maybe.

If something can fail, let the type show failure.

If it touches the outside world, make that visible as Effect.

If it changes over time, make it Signal.

If it's UI, make it Html.

I want responsibilities to be separated clearly.

What I don't want is to jump into a completely different programming worldview every time the responsibility changes.

That may be one of the parts of Seseragi I find most interesting right now.

Play with it

https://seseragi.vercel.app/

https://seseragi.vercel.app/tour/

A good path is to start with the ADT and match sections of the Tour.

Then open the Maybe examples and switch between Just and Nothing.

After that, continue into Web UI.

By then, I think you can start to see what Seseragi is trying not to hide, and what it prefers to make visible as a shape in the language.

TypeScript Is a Backend, Not the Language

KentaroMorishita — Sun, 16 Aug 2026 13:56:08 +0000

Seseragi currently uses TypeScript / JavaScript as one of its execution targets.

If that's the first thing you hear about it, a reasonable reaction is:

"So is it basically TypeScript syntax sugar?"

At one point, it almost was.

The first implementation stayed very close to TypeScript because that was by far the easiest way to get something running.

Parse a little syntax.

Transform it.

Emit TypeScript.

Done.

That worked surprisingly well for a while.

Then the language grew, and the architecture started feeling wrong.

Is this a Seseragi rule or a TypeScript workaround?

The early compiler was simple.

Then Maybe arrived.

Either arrived.

Effect arrived.

Type classes arrived.

Signal arrived.

Web UI arrived.

And the transformation code gradually started mixing three different questions:

what a Seseragi program means
how that meaning should be represented in TypeScript
what the JavaScript runtime needs in order to execute it

A small change in one place would break something surprisingly far away.

That is usually the point where my internal design detector emits its most sophisticated diagnostic:

This feels ugly.

So I rebuilt the compiler

The current Seseragi compiler is being rebuilt in Rust.

Very roughly, the path looks like this:

Source
  ↓
CST / AST
  ↓
name resolution / type checking
  ↓
Typed HIR
  ↓
Core IR
  ↓
TypeScript IR
  ↓
TypeScript + source map

Listing all those names makes this article sound much more like a compiler article than the way I originally learned the idea.

At the beginning I barely knew what IR was supposed to buy me.

The useful realization was much simpler:

I need one place for what this means in Seseragi, and another place for how TypeScript happens to implement that meaning.

There needs to be a boundary between them.

TypeScript is not the enemy

This part matters.

I am not trying to escape TypeScript because I dislike it.

I use it constantly.

The JavaScript ecosystem is enormous. Browsers run it. Servers run it. Tooling is everywhere.

I want to take advantage of that.

What I don't want is for every person writing Seseragi to carry Promise details, JavaScript ABI details, and backend-runtime decisions all the way up into their source code.

The semantics I want the language to guarantee should live on the Seseragi side.

How those semantics execute is a backend problem.

That separation is the important part.

I'm not promising every backend under the sun

Once a compiler has a Core IR and a backend boundary, the obvious questions appear immediately:

"Could you add LLVM?"

"Could it compile to native code?"

"Could you emit WASM directly?"

Architecturally, those questions are easier to ask now than they were before.

That does not make them implemented.

Memory management exists.

ABIs exist.

Async exists.

Runtime semantics exist.

Saying "another backend should be possible" is much easier than building one correctly.

So right now I want TypeScript to become a solid first backend.

Designing an architecture that leaves room for the future is not the same thing as pretending the future has already been implemented.

Codex occasionally starts dreaming ahead here too, and I have to pull it back.

Not knowing compiler architecture made the lesson more interesting

I wasn't a compiler expert when I started Seseragi.

The original plan was more or less:

"Parse this and generate TypeScript. That should be enough."

Then I got to experience exactly why it stops being enough as the system grows.

Only after that did I start understanding why the responsibilities in compiler architecture are separated the way they are.

I actually like that path.

I didn't memorize an architecture diagram and then implement it.

The changes started feeling ugly, I investigated why, and compiler architecture appeared at the bottom of the hole.

A lot of Seseragi has developed that way.

The Playground runs through the same compiler boundary

https://seseragi.vercel.app/

The compiler used in the Playground isn't intended to be a separate toy implementation.

The CLI, LSP, WASM Playground, and other surfaces are being built around the same compiler-driver boundary.

That matters to me too.

A language where one sample works in the Playground, VS Code reports different types, and the CLI behaves differently would be miserable to use.

I didn't begin this project because I wanted to study compiler internals.

I just kept finding more places where the language's meaning needed a clear owner.

The symptoms continue to progress nicely.

If There Are Four States, Why Not Write Four States?

KentaroMorishita — Sun, 16 Aug 2026 13:55:36 +0000

When you build web applications, booleans tend to multiply.

type State = {
  isLoading: boolean
  hasError: boolean
  data?: string
}

Nothing unusual about that.

I've written plenty of code like it myself.

But sometimes I look at a type like this and imagine the values it permits:

{
  isLoading: true,
  hasError: true,
  data: "already loaded"
}

What state are you even in?

Of course, you can decide that your implementation will never create that combination.

You can protect the invariant in a reducer. You can validate it. You can test it.

But if the real states are simply:

Idle
Loading
Loaded
Failed

why not write four states in the first place?

That has gradually started to feel more natural to me.

Decide the shape before managing the booleans

In Seseragi, I might write this:

type RequestState =
  | Idle
  | Loading
  | Loaded String
  | Failed String

fn label state: RequestState -> String =
  match state {
    Idle -> "Idle"
    Loading -> "Loading..."
    Loaded value -> `Loaded: ${value}`
    Failed message -> `Error: ${message}`
  }

pub effect fn main =
  Loaded "Seseragi"
  |> label
  |> println

Now RequestState has four possible shapes.

If data has arrived, it's Loaded String.

If the request failed, it's Failed String.

There is no state where Loading and Loaded are simultaneously true, because I never created such a state in the model.

I like the feeling of deciding the shape of the world before working hard on its control flow.

Branch using the same shape

Another thing I like here is that match is not a special state-management feature.

It's just a normal data type being matched by a normal expression.

If I add another constructor to the type, places that handle this value have another case to think about.

The code and the thought in my head — "how many forms can this value take?" — stay fairly close together.

TypeScript can do this too. Of course it can.

TypeScript has discriminated unions:

type RequestState =
  | { type: "idle" }
  | { type: "loading" }
  | { type: "loaded"; value: string }
  | { type: "failed"; message: string }

This is already much better.

So this is absolutely not a "Seseragi can do something TypeScript can't" argument.

Almost the opposite.

The more I wrote TypeScript this way, the more I started thinking:

Wouldn't it feel good if this sat closer to the center of the language?

In Seseragi, I wanted ADTs and pattern matching to feel less like a technique you remember to reach for and more like ordinary tools for describing data.

I want the same model to survive all the way to the UI

The reason this matters to me isn't limited to state modeling.

UI is the same story.

Take a RequestState.

match on its shape.

Return Html.

I don't want to use an ADT to model state and then throw the model away the moment UI begins.

Define the shape of the data.

Transform it with ordinary functions.

Use match when cases matter.

I want that same way of thinking to continue into Signal and Html.

That continuity has become a fairly large part of what Seseragi is trying to do.

Break it in the Playground

https://seseragi.vercel.app/

Paste the example above and first change:

Loaded "Seseragi"

to:

Loading

Then add another constructor:

  | Cancelled

Leave label unchanged and compile it.

What the compiler complains about is a pretty direct demonstration of why I prefer this model over collecting boolean flags and promising that their combinations stay sensible.

This sounds like state management, but I think it's really data design

These days, before asking which state-management library I should use, I increasingly want to ask:

"How many states does this thing actually have?"

Instead of decomposing the state into booleans and then defending the valid combinations, define the possible shapes first.

I want Seseragi to make that question easy to ask very early.

Maybe I never really wanted fewer if statements.

Maybe I wanted to organize the world before I had to write them.

Why Does State Management Suddenly Need a Whole New Programming Model?

KentaroMorishita — Sun, 16 Aug 2026 13:55:34 +0000

When I write Web UI, the code often begins with ordinary values.

There is a String.

There is a Record.

There is a function.

So far, everything makes sense.

Then the screen starts moving and suddenly the vocabulary changes.

Hook.

Store.

Subscription.

Dispatch.

Selector.

Provider.

Wait. A moment ago this was just a value.

That feeling has bothered me for a while.

I don't hate state-management libraries

I've used React, Vue, and plenty of state-management libraries.

They're useful. They solve real problems.

The part I kept wondering about was more basic:

If I want to represent a value that changes over time, why does that moment sometimes require the programming model of the whole application to change too?

What if:

simply became:

Signal<A>

when time enters the picture?

Seseragi has Signal

In Seseragi, a value that changes over time can be represented as Signal<A>.

A String is String.

A String whose current value can change over time is Signal<String>.

I wanted that to feel less like moving the value into another universe and more like adding one more dimension to the thing we already had.

The Tour contains a deliberately small example:

import * as signals from "std/signal"

fn double value: Int -> Int =
  value * 2

pub effect fn main = do {
  source <- signals.make 21
  let doubled = signals.map double source
  current <- signals.read doubled
  println `mapped: ${current}`
}

It's almost disappointingly ordinary.

I like that.

There is a value, 21.

It becomes a value that can vary over time.

An ordinary double function is mapped over it.

When I need the current value, I read it.

It doesn't feel like "state management has begun." It feels like an ordinary value gained a time axis.

That continuity is what I wanted.

I didn't want Signal to become Effect

While designing Signal, I also didn't want to throw every interesting behavior into Effect.

Making one HTTP request and representing a value that keeps changing on screen are related in the broad sense that both are more than pure arithmetic, but they are not the same responsibility.

One thing interacts with the outside world at a particular point.

Another thing has a current value that changes over time.

I want those responsibilities separated.

But I don't want separating them to force the programmer to learn two completely unrelated worldviews either.

Separate responsibilities. Keep the worldview connected.

I keep coming back to that sentence while building Seseragi.

Ordinary functions should survive in UI too

On the Web UI side, an ordinary view function sits on top of the Signal.

Conceptually, the path looks like this:

Model
↓
Signal<Model>
↓
map view
↓
Signal<Html<Action>>

The function from Model to Html<Action> is still just a function.

I don't want the existence of Signal to force that function into a component-specific spiritual dimension.

There is a separate article about the UI side of this, so I won't paste the same form sample here too.

The Playground makes this much easier to feel

https://seseragi.vercel.app/

https://seseragi.vercel.app/tour/

Paste the sample above and try:

changing 21
making double triple instead
adding another signals.map
continuing through the Tour to set and combine

Then continue into Web UI and the pieces start connecting: Model, Action, Signal, Html, DOM.

You begin with ordinary values and ordinary functions, and somehow the screen moves at the other end.

Lately, when I play with that path in the Playground, I keep having the same reaction:

"Yeah. This is enough."

It's not finished.

But I like the direction a lot.

I Can Barely Read Rust, but I'm Building a Compiler in Rust

KentaroMorishita — Sun, 16 Aug 2026 13:55:02 +0000

The Seseragi compiler is currently written in Rust.

I can barely read Rust.

Written as two sentences, this project sounds deeply questionable.

I don't think this would have worked before

If you're building your own compiler, the obvious assumption is that you should understand the implementation language very well.

That is still an advantage. A huge one.

But in the Seseragi rewrite, Codex writes a large part of the Rust implementation.

My job is not to personally type every line.

I spend much more time on questions like:

what should this mean in Seseragi?
which layer owns that responsibility?
does this syntax feel good?
are backend concerns leaking into the public surface?
will this implementation choice trap us later?

And if the result feels wrong, I make it go back.

"AI can write it, so architecture matters less" turned out to be completely wrong

At first, part of me wondered whether AI implementation meant I could be more relaxed about internal structure.

Local implementation is astonishingly fast now.

That speed is exactly what makes careless architecture dangerous.

If you put a responsibility in the wrong place, the wrong architecture can become fully implemented at incredible speed.

Sometimes it even comes with tests.

It looks polished.

It is still wrong.

That is terrifying in a very modern way.

So I spend more time writing Issues

Before handing work to Codex, I now think much harder about the shape of the task.

What is actually in scope?

What is the source of truth?

What should explicitly wait for a future Issue?

Does this change break an assumption needed by the next piece of work?

AI made code production faster, so the human side of the loop moved further toward designing the entrance to the work.

It's strange, but I think I spend more time thinking about architecture now than I did when I personally wrote more of the implementation.

This is not an argument that I never need to learn Rust

I want to be clear about this.

Understanding Rust would obviously make me stronger at this project.

It helps when debugging low-level behavior, looking at performance, reviewing ownership choices, or encountering unsafe.

When I need to understand something, I read it.

The interesting part to me is not "you don't need to know your tools anymore."

It's that I can move a language implementation forward by holding onto the semantics and architecture even when I don't completely control the implementation language.

Once AI enters the implementation loop this deeply, the question "what does the author actually do?" starts to change.

I care more about the surface syntax than thousands of lines of Rust

Codex can produce a large Rust diff and I can review it fairly calmly.

Then I look at a Seseragi sample and see:

one character that feels unnecessary

or:

an ugly line break

and suddenly I become extremely opinionated.

I think the reason is simple.

I'm not primarily trying to create a Rust compiler.

I'm trying to create Seseragi as an interface that humans use.

The compiler is the machinery that protects that meaning.

So I'm harsher on the surface than on implementation details I can delegate.

This seems logically consistent to me.

Codex may have a different opinion.

Somehow, it actually runs

https://github.com/KentaroMorishita/seseragi

The project now has a Rust compiler, CLI, LSP, formatter, and WASM Playground sharing the same compiler-driver direction.

https://seseragi.vercel.app/

I don't feel that the language stops being mine because I didn't personally write every line of Rust.

I keep ownership of questions like:

What does the language mean?

What is allowed?

What feels wrong enough to change?

An AI-assisted homemade programming language is a very strange kind of software project.

I think we're only beginning to find out how strange.

My Language Playground Somehow Turned Into a Place to Build Web Apps

KentaroMorishita — Sun, 16 Aug 2026 13:55:00 +0000

When I hear "Playground for a homemade programming language," I imagine something simple.

Write code on the left.

Press Run.

See the result on the right or underneath.

Early Seseragi felt more or less like that.

The browser could compile code written in the language I was building.

That alone made me happy.

Recently, though, things have become a little strange.

The Playground has become a place where I can casually build Web applications in my own language.

Sometimes I genuinely lose track of what I'm making.

At first, "it runs!" was enough

Hello World runs.

FizzBuzz runs.

match runs.

Maybe runs.

Those were straightforward homemade-language victories.

Paste some code into the Playground, press Run, see output.

Of course my own language should eventually be able to run its own code, but it still feels a little magical every time another piece starts working.

Then HTML Preview started working

Seseragi can construct Html as a value.

At first, merely producing server-rendered-looking Html was interesting enough.

Then the DOM runtime connected.

Events started firing.

Signals started changing.

The screen started updating.

At that point the Playground stopped feeling like a compiler test page.

It became a place where I could think, "I wonder what this UI would look like," and just write it.

Now a button can just update the screen

A cleaned-up version of the DOM sample in the Tour looks roughly like this:

import * as dom from "std/web/dom"
import * as html from "std/web/html"
import * as signals from "std/signal"
import { MutableSignal } from "std/signal"

type Action =
  | Increment

fn view count: Int -> html.Html<Action> =
  html.button {
    id: "increment",
    onClick: Increment,
    children: `Count: ${count}`
  }

fn handle state: MutableSignal<Int>
  -> action: Action
  -> Task<Unit> =
  match action {
    Increment ->
      signals.update (\value: Int -> value + 1) state
  }

fn domError error: dom.DomError -> String =
  show error

fn runtimeError error: dom.DomRuntimeError<Never>
  -> String =
  show error

pub effect fn main
  -> Unit
  with dom: dom.Dom
  fails String =
  do {
    state <- signals.make 0
    let content = signals.map view state
    let options = dom.defaultOptions ()

    target <- dom.query "#app" |> mapError domError

    dom.run options target (handle state) content
      |> mapError runtimeError
  }

Paste this into the Playground with HTML Preview enabled and the count increases every time you click the button.

Looking at this code, the Playground feels very far away from "a place where I inspect compiler output."

Forms were where it became genuinely fun

Further into the Tour, input, checkbox, submit, and other ordinary form interactions started working too.

There is a Model describing state.

There is an Action describing events.

An ordinary match updates the Model.

Signal carries change over time.

Html reacts to it.

Somewhere around here, my own use of the Playground changed.

It stopped being a place where I verify the compiler and became a place where I play with Seseragi.

I like having both Tour and Discover

The Playground has a Tour for walking through features in order and Discover for jumping directly to samples by purpose.

The Tour starts at Hello World and gradually moves forward.

Discover is where I go when I think, "Show me Maybe," "I want the Web UI sample," or "Where was that form example again?"

This is useful even while building the language.

Sometimes I forget exactly how one of my own features is currently written, open my own Playground, and let my own Tour remind me.

I built a language and then built a tutorial to teach its author how to use it.

This is all going very well.

A Playground exposes ugliness immediately

A specification document can hide awkward syntax surprisingly well.

Actually typing the language does not.

"Are there too many parentheses here?"

"Why does this line break look terrible?"

"What is this error message even trying to tell me?"

"Why is the spacing in this UI so weird?"

The moment the language becomes something I can touch, those problems surface immediately.

That's been extremely useful.

I probably spend more time complaining about the Seseragi code I see in the Playground than reading every line of Rust inside the compiler.

But the surface is what people eventually use, so I think that priority is defensible.

Please break it

https://seseragi.vercel.app/

https://seseragi.vercel.app/tour/

For the counter above, try:

change + 1 to + 10
add a Decrement Action
change the button text
split view into smaller functions
add another Action and argue with the compiler

Then open random Discover samples and break Maybe, forms, or Web UI.

I don't think you have to approach it as a carefully structured tutorial.

Breaking things and arguing with the compiler is a perfectly good way to learn it.

As the Playground grows, the language grows with it

I'm still changing the Playground itself quite a lot.

Search. Explorer. Preview. Mobile behavior. Tour. Discover.

Those can look like concerns separate from a language implementation, but in practice they feed directly back into it.

Is the language awkward, or is the Playground awkward?

Is the error bad, or is the presentation of the error bad?

Is the sample wrong, or is the syntax wrong?

Once there is a place where the language can be used every day, I keep stepping on these questions.

Then a Playground problem sends me back into the compiler.

I fix the compiler and return to the Playground.

That's more or less the current loop.

We've come a long way from "I pressed Run and Hello World appeared."

It's still unfinished, though.

Which may make this the best time to play with it.

If you find something weird, there's a decent chance I'll look at the same thing later and say, "Yeah, that's ugly."

The Best Feeling Is When Ordinary Features Compose Into Something Bigger

KentaroMorishita — Sun, 16 Aug 2026 13:54:28 +0000

There is a moment I enjoy more than adding a new feature to Seseragi.

It's when I realize:

I don't need a new special feature at all. The things already in the language compose into the thing I wanted.

That feels much better.

Adding a dedicated feature always looks easy at first

A new use case appears.

Add syntax.

Add a keyword.

Add a special runtime rule.

In the short term, this can be the fastest solution.

But every special feature also creates another thing to learn.

And if it gets its own semantics, six months later someone — probably me — looks at it and asks:

"Why is this one thing special?"

Whenever old versions of Seseragi started smelling like that, it bothered me a lot.

Web UI made this especially obvious

When I started exploring Web UI, I didn't begin by designing component syntax.

The language already had ordinary functions.

Records.

ADTs.

match.

Arrays.

So I wondered whether Html could simply be another value built from those same tools.

The component model in the Tour can be summarized like this:

Data
  ↓
function / match
  ↓
Html<Action>

No special component declaration is required for that path to go surprisingly far.

There is a separate article where I show the actual component code. Repeating the exact same sample here would make the article less focused, not more complete.

I didn't want state to become another universe either

Once UI can render, the next request is obvious: make it change.

Instead of immediately adding a whole "state-management framework," Seseragi has Signal<A> for values that change over time.

That turns:

A
↓
function
↓
Html

into:

Signal<A>
↓
map function
↓
Signal<Html>

There is a new responsibility.

But there isn't necessarily a completely new way of thinking.

That is much closer to the kind of language I want.

Effect follows the same principle

Interaction with the outside world is not the same thing as ordinary value transformation.

So it deserves a separate responsibility.

But separating it doesn't mean I want to invent a giant Effect-only worldview either.

It should still compose as a value where that makes sense and connect back to ordinary functions at clear boundaries.

Maybe and Either are different again.

Their meanings are not interchangeable.

But where they share ordinary operations — map, match, function application — I would rather reuse those language ideas than invent a separate miniature language for every type.

Separate responsibilities, not worldviews

This is probably the sentence that best captures what I've been doing lately:

Separate the responsibilities, but don't make each responsibility its own programming worldview.

Effect and Signal are not the same thing.

Html and DOM are not the same thing.

Maybe and Either are not the same thing.

I do not want to blur all of them into one abstraction just for the sake of uniformity.

But I also don't want every boundary to say:

"From here on, use another framework."

"From here on, learn another DSL."

"From here on, composition follows unrelated rules."

I want the responsibilities to stay distinct while ordinary types, values, and functions connect them.

Looking back, I think I've been trying to do that throughout Seseragi.

Fewer special features is not a moral achievement

I will add syntax when the language actually needs syntax.

Seseragi has match.

It has do.

It has effect fn.

This is not a competition to minimize the keyword count.

The question I want to ask before adding a concept is simply:

Does this introduce genuinely new meaning, or can the meaning already be expressed by composing things we have?

If the second answer works, I'm happy.

That's all.

Look for the boring parts in the Playground

https://seseragi.vercel.app/

Open one of the Web UI samples and you may notice an unexpectedly large number of ordinary functions.

A demo for a homemade programming language could probably look more impressive if every screen contained exotic syntax.

But the reaction I would most like is:

"Huh. I can just read this."

I didn't make a language because I wanted ordinary programming to look strange.

I made it because I wanted ordinary programming to feel better.

Why Does null Get to Pretend It's a Normal Value?

KentaroMorishita — Sun, 16 Aug 2026 13:54:26 +0000

If you write TypeScript, null and undefined are just part of life.

That's normal.

But I've always found them slightly uncomfortable.

A value may exist.

It may not exist.

So far, so good.

What bothers me is how naturally "not there" can walk into the same world as ordinary values and sit down like nothing happened.

const user = users.find(x => x.id === id)

user.name

TypeScript complains, correctly.

user may be undefined.

This isn't TypeScript failing to help. TypeScript is being nice here.

But if every encounter with absence turns into another branch like:

if (!user) {
  // ...
}

then the code gradually becomes more about avoiding a null-like value than about the actual fact I wanted to model:

there may be no user.

I never liked that very much.

If it may be missing, I want that to be the shape

I was already using Maybe for this kind of thing when I built F-Box.

The old implementation is still here:

https://github.com/KentaroMorishita/f-box-core

https://github.com/KentaroMorishita/f-box-react

Seseragi follows the same idea. If a value may be absent, I want that visible as Maybe<A> from the beginning.

The Tour has a small sample like this:

fn withDefault fallback: String
  -> value: Maybe<String>
  -> String =
  match value {
    Nothing -> fallback
    Just item -> item
  }

let name: Maybe<String> = Nothing

pub effect fn main =
  withDefault "Guest" name
  |> println

Nothing fancy is happening.

name is not a String.

It is a value that may contain a String.

So the code using it handles Nothing and Just item as ordinary cases.

That "ordinary" part matters to me.

I don't want a special null-checking language bolted onto the rest of the language.

There is a data shape called Maybe.

There is an ordinary expression called match.

I'd like that to be enough.

Transforming only the present value shouldn't require a new control structure either

Maybe can be mapped.

If a value exists, transform it.

If it is Nothing, keep it Nothing.

Seseragi lets you write that with map, or with <$> if you like the operator form.

There is more to say about Functor there, but I'd rather keep that in an article where Functor is actually the point.

If an article about Maybe starts pasting three nearly identical Maybe examples, the article itself becomes the problem.

I'm not trying to ban null

Discussions like this can turn into "is null evil?" very quickly.

I'm not interested in that religious war.

If the outside world contains null, then of course a boundary has to deal with it.

JSON has it. JavaScript has it.

What I don't want is to carry that external representation through the entire inner model of the program.

Accept the outside world's shape at the boundary.

Then turn it into something meaningful on the inside.

That's all.

Break it in the Playground

https://seseragi.vercel.app/

https://seseragi.vercel.app/tour/

Paste the withDefault example and first change:

Nothing

to:

Just "Kentaro"

Then try things like:

change the example to Maybe<Int>
remove the Nothing arm from the match
continue through the Tour until you reach map
nest Just inside Just and enjoy the immediate feeling that you've probably modeled the wrong thing

I think Maybe is easier to understand by touching it than by beginning with category theory.

For what it's worth, I once spent about three months of train rides thinking about this family of ideas.

Looking back, I apparently had a lot of free mental bandwidth.

Is Seseragi a Functional Programming Language? I'm Not Sure.

KentaroMorishita — Sun, 16 Aug 2026 13:53:52 +0000

Seseragi has Maybe.

It has Either.

It has Functor, Applicative, and Monad.

It has <$>, <*>, and >>=.

It has match and ADTs.

Once I list all of that, there is a very predictable response:

"So it's a functional programming language."

Fair.

Even I would probably make that assumption.

And yet I don't really think of Seseragi that way while I'm designing it.

I am not going to pretend I don't like Monad

That would be impossible to defend.

I do.

There was a period when I spent about three months of train rides talking through Monad with GPT.

Then I built F-Box.

The old implementation is still here:

https://github.com/KentaroMorishita/f-box-core

https://github.com/KentaroMorishita/f-box-react

So "I'm not really interested in this stuff" would obviously be a lie.

But I did not add Monad to Seseragi because I wanted the language to look more functionally programmed.

I wanted to connect values.

I wanted failures to stay values.

I wanted interactions with the outside world to compose.

I kept following those problems, and eventually found abstractions that already had names.

At that point, using the existing abstraction seemed better than inventing a private version of the same idea.

That's closer to how it happened.

I didn't start with a paradigm

I never wrote "Seseragi is a language in paradigm X" at the top of a document and derived the features from there.

The process tends to run in the opposite direction.

I write ordinary software and think:

"This is annoying."

"Wouldn't it be nicer if this were shaped differently?"

Then I keep digging.

If there are several possible states, I want an ADT.

If a value may be absent, I want Maybe.

If something can fail, I want Either or typed failure to make that visible.

If a value changes over time, I want Signal.

If code crosses into the outside world, I want Effect to show the boundary.

If I'm writing UI, I still want ordinary data and functions to work.

Those responsibilities are different.

What I dislike is being forced into an unrelated mental model every time the responsibility changes.

That feels much closer to the actual motivation behind Seseragi than any paradigm label.

I do care about being declarative

There is one direction I can state more confidently.

When I read code, I like what something is to appear before instructions about how to manipulate it.

I prefer seeing the shape of data, transformations of values, and explicit cases over tracing a long sequence of commands.

That preference naturally overlaps with a lot of tools associated with functional programming.

But I don't want the conclusion to become, "You must know FP etiquette before you're allowed to use the language."

Ideally, the theory can arrive later.

You use something because it reads naturally, and at some point somebody says:

"By the way, that's a Functor."

Fine by me.

You don't need to know `<$>` to use it

For example, the Tour includes code like this:

fn double value: Int -> Int = value * 2
let named: Maybe<Int> = map double (Just 21)
let operator: Maybe<Int> = double <$> Just 21
let missing: Maybe<Int> = double <$> Nothing

If <$> means nothing to you, use map.

If you already like the operator, use the operator.

I don't want Seseragi to become a language where memorizing symbols is an entrance exam.

I also don't want to take the symbols away from people who like them.

That would inconvenience me personally.

So what is Seseragi, then?

The description that currently feels closest is something like:

a language where I want useful abstractions to remain ordinary language features that can compose all the way through the program.

That is not a very useful category label.

Marketing departments would probably ask for another draft.

But the language is still evolving, and I don't see much value in narrowing its identity just to make the label cleaner.

If Seseragi ever becomes mature enough that somebody else wants to classify it, they can do that.

I'll probably still be arguing about where a line break should go.

I'm Building a Programming Language, and Somehow I Keep Obsessing Over Spacing

KentaroMorishita — Sun, 16 Aug 2026 13:53:50 +0000

Seseragi is a programming language, so naturally there is a compiler.

There is a parser.

Type inference.

Effect.

Signal.

A runtime.

And yet one of the things I say most often while building it is:

"The spacing looks wrong."

Once the Playground worked, "working" stopped being enough

At first, being able to compile and run Seseragi in a browser was exciting by itself.

That is already a ridiculous thing to see when the language is your own.

But humans adapt quickly.

Once it worked, I started looking at everything around the Run button.

The search panel feels cluttered.

The gap between Editor and Preview feels wrong.

These cards are too close together.

Those elements are too far apart.

The text feels cramped.

On mobile it feels even worse.

And eventually I say:

"Why is there no space here?"

This isn't only a UI problem

The funny part is that I do almost exactly the same thing to the language itself.

Too many parentheses.

Too many commas.

Awkward line breaks.

Function application that's harder to scan than it should be.

match arms breaking in visually strange places.

Apparently I spend a lot of time worrying about visual noise.

If two forms mean the same thing, I usually prefer the one that asks my eyes to process less accidental structure.

But removing too much structure can make meaning disappear.

So I'm constantly looking for the line between "quiet" and "ambiguous."

Even Tailwind classes become language noise in a demo

When I was writing Web UI samples in the Playground, dumping long Tailwind class strings into every element quickly made the examples unreadable.

So I started moving classes into arrays, combining them with cx, and splitting UI into smaller functions.

That has nothing to do with the compiler's semantics.

But if a demo is visually noisy, a reader doesn't think:

"This Tailwind sample could use refactoring."

They think:

"Seseragi code looks noisy."

I don't want the demo to become an accidental argument against the language.

Presentation is part of the first impression of the syntax.

The Playground keeps turning into an IDE

Originally, it was one file and a Run button.

Then search appeared.

Then I wanted an Explorer.

Then module splitting.

Then full-screen Preview.

Then a Tour.

It keeps becoming more IDE-like.

Even I sometimes ask:

"How far am I planning to take this?"

But a good Playground lowers the cost of touching a new language dramatically.

No installation.

No reading an entire README first.

Open it, paste code, press Run.

That matters a lot when an article tries to move someone from "this idea is interesting" to "let me change one value and see what happens."

Language UX is bigger than syntax

I used to think "language design" mostly meant syntax and semantics.

Those are obviously the core.

But once a human actually uses the language, the experience includes questions like:

can I understand the errors?
does the formatter produce code I want to read?
can the editor show useful type information?
can I try something immediately in the Playground?
does the interface survive on mobile?

All of that becomes part of what the language feels like.

Which is why I can spend ten minutes thinking about a compiler issue, switch tabs, and immediately become angry about padding in the search panel.

It's a busy project.

If something feels awkward, tell me

https://seseragi.vercel.app/

https://seseragi.vercel.app/tour/

Feedback doesn't need to be about deep type-system theory.

If you use the Playground and think:

"This is hard to use."

"That display looks strange."

"Why is the spacing like this?"

I consider that useful language feedback too.

There is a non-zero chance it will bother me more than a sophisticated compiler-theory observation.

And there is an even better chance that an Issue will exist by the next day.

DEV Community: KentaroMorishita

What If Programs Were Mostly Just Values Flowing Through Functions?

TypeScript can already feel like this

In Seseragi, I wanted the value to keep flowing

I like $ for the same reason

I care more about making ordinary code pleasant than making unusual code impressive

Play with it

Why Should the Language Change the Moment I Build a UI?

Couldn't a component just be a function?

Couldn't Html just be a value?

Action is ordinary data too

If state changes, make it Signal

I'm not trying to build React again

Try the form in the Playground

It's still experimental

TypeScript Can Express Almost Anything. That's Part of the Problem.

Take state, for example

Take "there might not be a value"

Take the outside world

Maybe what I wanted wasn't restriction, but shape

Play with it

TypeScript Is a Backend, Not the Language

Is this a Seseragi rule or a TypeScript workaround?

So I rebuilt the compiler

TypeScript is not the enemy

I'm not promising every backend under the sun

Not knowing compiler architecture made the lesson more interesting

The Playground runs through the same compiler boundary

If There Are Four States, Why Not Write Four States?

Decide the shape before managing the booleans

Branch using the same shape

TypeScript can do this too. Of course it can.

I want the same model to survive all the way to the UI

Break it in the Playground

This sounds like state management, but I think it's really data design

Why Does State Management Suddenly Need a Whole New Programming Model?

I don't hate state-management libraries

Seseragi has Signal

I didn't want Signal to become Effect

Ordinary functions should survive in UI too

The Playground makes this much easier to feel

I Can Barely Read Rust, but I'm Building a Compiler in Rust

I don't think this would have worked before

"AI can write it, so architecture matters less" turned out to be completely wrong

So I spend more time writing Issues

This is not an argument that I never need to learn Rust

I care more about the surface syntax than thousands of lines of Rust

Somehow, it actually runs

My Language Playground Somehow Turned Into a Place to Build Web Apps

At first, "it runs!" was enough

Then HTML Preview started working

Now a button can just update the screen

Forms were where it became genuinely fun

I like having both Tour and Discover

A Playground exposes ugliness immediately

Please break it

As the Playground grows, the language grows with it

The Best Feeling Is When Ordinary Features Compose Into Something Bigger

Adding a dedicated feature always looks easy at first

Web UI made this especially obvious

I didn't want state to become another universe either

Effect follows the same principle

Separate responsibilities, not worldviews

Fewer special features is not a moral achievement

Look for the boring parts in the Playground

Why Does null Get to Pretend It's a Normal Value?

If it may be missing, I want that to be the shape

Transforming only the present value shouldn't require a new control structure either

I'm not trying to ban null

Break it in the Playground

Is Seseragi a Functional Programming Language? I'm Not Sure.

I am not going to pretend I don't like Monad

I didn't start with a paradigm

I do care about being declarative

You don't need to know <$> to use it

So what is Seseragi, then?

I'm Building a Programming Language, and Somehow I Keep Obsessing Over Spacing

Once the Playground worked, "working" stopped being enough

This isn't only a UI problem

Even Tailwind classes become language noise in a demo

I like `$` for the same reason

You don't need to know `<$>` to use it