if anyones interested

code-with-sesi.netlify.app

Version: 1.9.0
Github: github.com/Misterscan/sesi
Docs: code-with-sesi.netlify.app/docs
Demo(s):

• svg-math-in-sesi.netlify.app

Install/Download:

• NPM:

npm install g @​ misterscan/sesi # <-- Remove the space between the @ and misterscan

• Direct: code-with-sesi.netlify.app/install

works on both windows and mac, not sure about linux but if you run linux and would like to help develop on the linux compatibility, lmk!

sesi studio ide now available for download on both windows and mac!

Is this vibe coded ?
Mobile site giving me bad vibes

yeah the mobile site worked perfectly before but i gotta fix it

thanks for calling it out

No worries, I’ll keep an eye on this project

New fl studio dropped

Is this jus ai prompted coding?

It’s pg lang foo

it can be

i designed it to be easier for us to understand syntax and code structure

What type of tasks is it suited for? I mainly use python and matlab for scientific work

for example something simple like creating a new file and saving it can be

let outDir = "your-directory-name"
let content = "whatever your file contains"
let filename = outDir + "/filename.extension"
try {
write_file(filename,  content)
} catch (e) {
print e}
print "File saved to:" filename

it can handle logic from complex math equations to hosting its own server

cli usage and/or script based

salut thank u grok

Isnt python alrdy similarly easy to read?

i mean if you already know python then yeah its easy to read

but my code is the entire script in sesi, not just a snippet

v1.5.9 out now

• now with built-in SVG and Audio creation functions via "std/draw", "std/audio", and "std/theory"

• new built-ins for archiving, deletion, and renaming files/folders "archive(), trash(), rename()"

• bug fixes

iirc python support is now built in

version 1.7.5 out now!

lots of new improvements, additions, and bug fixes

closer to v2 than i thought!

version 1.8.6 out now!

visit the new website for details

this is sick, very high level ambition and great execution!

The biggest problem is that it advertises itself as “clean, minimal, and highly legible,” while simultaneously trying to natively own AI calls, image generation, SVG, audio synthesis, databases, HTTP, browser automation, subprocesses, Python/JS execution, encryption, games, web servers, package management, an IDE, and more. The README itself lists all of these as language/runtime features. That is almost the opposite of minimalism.
A few concrete reasons it gives off “AI slop” vibes:
Feature accumulation without obvious design boundaries. model(), image(), web_get(), web_send(), python(), js(), exec(), spawn(), audio synthesis, drawing and a document database are all pushed into or immediately adjacent to the core runtime. A mature language normally tries to keep the core language small and moves most domain functionality into libraries.
It reinvents syntax without getting much benefit. Sesi supports normal import { ... } from ..., yet also introduces allow "math" in with { add, multiply } and allow "math" in as Math as the “preferred” import syntax. allow ... in with ... is longer, less conventional, and semantically unclear: “allow” usually suggests permissions/security, not module binding.
There are needless syntax inconsistencies. Ordinary object literals require quoted keys, while schema/config objects use unquoted keys. The guide literally warns that {"name": "Ada"} is one grammar but {key: string} is another. That increases parser complexity and cognitive load for little apparent gain.
Some “conciseness” choices damage readability. The idiomatic output syntax is show "Hello," name "version" version rather than ordinary interpolation or explicit concatenation. You save punctuation but make the grammar implicit. Once expressions become complicated, this tends to become harder to scan, not easier.
The docs contradict themselves conceptually. The guide calls it “dynamically typed with optional type annotations,” while the README advertises a “Type System” including “Static types” and “Type inference.” Those concepts can coexist in some designs, but the documentation should precisely explain whether annotations are statically verified, runtime-checked, gradual typing, or merely metadata.
It has both a bytecode VM and a tree-walking interpreter fallback. The project structure explicitly lists an AST→bytecode compiler, bytecode VM, and separate tree-walking interpreter. That isn't inherently bad—real languages sometimes do it—but in a young 0-star project with a huge surface area, it raises the question of whether two execution engines are being maintained consistently instead of first making one semantics rock-solid.
The security language is way too absolute. The README claims prototype pollution is “physically and architecturally impossible” and that tool-call restrictions “completely isolates the host from prompt-injection RCE.” Serious security engineering almost never talks in absolutes like “completely” or “impossible,” especially in a runtime that also exposes filesystem operations, networking, exec, spawn, Python, JS, ffmpeg, and model-driven tool calls. The intended mitigations may be useful; the marketing claim is much stronger than the evidence shown.
The documentation contains weird agent-oriented commandments. The language study guide ends with a “Mandatory Workflow” telling agents never to edit .sesi using sed, awk, or shell tools, including an “ABSOLUTE RULE.” That is repository-agent instruction leaking into what is presented as a language guide. It’s a classic symptom of building the repo around coding-agent prompts rather than cleanly separating developer documentation, language specification, and agent context.
The language is simultaneously trying to be conventional and “unique.” The docs emphasize that the syntax is “unique,” yet most of it is recognizably JavaScript/Python/Rust-ish: let, fn, braces, if, while, for x in, async, await, try/catch, arrays, JSON-looking objects, type annotations and pipes. Novelty isn't itself a language-design virtue.
One especially telling example is this:
allow "std/db" in with {db_open}
instead of something like:
import { db_open } from "std/db";
Sesi already supports the second conceptual model anyway. So allow ... in with mostly creates another thing a programmer has to memorize. A good new syntax construct should normally buy you a substantial capability or simplification.
Likewise, this:
let news = model("gemini-3.5-flash-lite") {search, cache: false} {"Latest AI news."}
looks impressive in a README. But it bundles model selection + provider semantics + options + prompt construction + web-search capability into language syntax. If Gemini changes its APIs or naming conventions, your language surface now carries vendor churn. In most languages that belongs in an SDK/library:
const news = await model.generate({
provider: "gemini",
search: true,
prompt: "Latest AI news."
});
That's slightly longer but vastly easier to evolve.
The part that most resembles AI-generated architecture to me is the breadth-to-maturity ratio. The repository advertises an IDE, package manager, sandbox, VM, interpreter, HTTP client/server, database, audio engine, SVG engine, game library, browser automation, AI model integration, image generation, local ONNX inference, tool calling, concurrency, encryption and installers. Meanwhile GitHub currently shows 0 stars, 0 forks, and 0 open issues. That doesn't mean the code is bad, but it does mean this enormous API surface hasn't had the ecosystem pressure that normally reveals whether these abstractions hold up.
So I’d characterize it as:

AI SLOP GARBAGE

This the problem with AI, AI slop is passed as legitimate when the AI vibe coders don’t know how the code even works.

but most important, how do I create EXE GUI’s? There’s no option for visual designer

lol thanks for your feedback and contribution to the sesi project

Wah gwan sesi

version 1.9.0 out now