DEV Community: Emil Valeev

🎉 Happy New Year, Neva Community! 🎉

Emil Valeev — Wed, 31 Dec 2025 14:26:51 +0000

Hi everyone! Emil Valeev here — the creator of the Neva programming language. As the year draws to a close, I want to extend a heartfelt thank you to all of you who took part in this journey. Your feedback, contributions, and curiosity power this project forward — even when the road gets tough, or when Neva isn’t making headlines (or money!).

For a slightly bigger-picture take on why I believe Neva (and dataflow programming) matters, check out my recent article: How Programming Will Look In the Future?.

2025: A Big Year for Neva

Personal recap:

This year was a rollercoaster. I stepped outside open source and tried building a SaaS — learned a lot, but it didn’t pay the bills. That sent me back to job searching…but deep down, it was clear that I just couldn’t quit Neva. In March, the project officially went on “freeze,” but by September, I was hacking away again. The result? 2025 turned out to be huge for Neva.

What Actually Changed in 2025?

Core Language:

Introduced tagged unions (replacing enums!)
Rewrote overloading for clarity and flexibility
Prototyped Go interoperability: Go code can call Neva, and the compiler is starting to use this already (parts of the Go codebase even got rewritten in Neva)

These are foundational steps — unblocking Neva’s evolution as a language.

Toolchain:

IR visualization in threejs and mermaid formats
neva doc: Easily look up standard library docs (third-party support coming!)
neva run --watch: Live reloading for development
Richer trace.log diagnostics
--emit-ir flag for builds and runs
New cross-compilation support: loongarch arch, plus target-os/target-arch flags and a handy osarch command

Stdlib:

New errors package: errors.New, errors.Must, errors.Lift
Support for .env files (os.LoadEnv)
Powerful new stream combinators: streams.ZipMany, streams.Wait, strings.Join

Internal/Infra:

Refactored and optimized all over—deadlocks/races fixed, code restructured, new tests (unit, integration, e2e, and smoke tests!)

People:

🎉 Welcome new contributors:
- k1ngmang
- mike
- WoodyAtHome
- 敖律风
- Ikko Eltociear Ashimine
- Zen
- hardliner66
And thanks to everyone (big or small!) whose issues, code, or thoughts made Neva better.

Donations:

Set up Open Collective — and got the very first donation! It might seem small, but for me, it’s a symbolic “we exist” moment (equals my first SaaS dollar… Feels real!).

What’s Ahead for 2026?

Language Philosophy

After a lot of reflection, I realized: Neva’s biggest struggles often came from trying to blend a pure, parallel dataflow and visual-node philosophy with text syntax features inspired by control-flow languages. That tension led to confusion — and extra complexity.

For 2026, I’m doubling down on Neva’s strengths: minimalism, explicit components and nodes, ports, and message passing. This is what makes Neva different — and valuable! (I wrote a bit more on this in this GitHub issue.)

Technical Roadmap:

[ ] Visual Node Editor: The “WOW!” feature that will let everyone see the dataflow
[ ] Debugger Prototype: Even a concept or POC would be a breakthrough
[ ] Documentation Generator: Live/local docs to make onboarding & learning easier
[ ] Call Go from Neva: Finish cross-language interop, more compiler logic in Neva itself
[ ] Finalize language core: numeric types, bytes, pattern matching, dataflow primitives, type assertions. Aim: “the language core is stable and won’t break”!
[ ] Grow the stdlib: IO, stream abstractions, error handling for stream processors, JSON, HTTP servers, state & context APIs, iterators/generators, and more.
[ ] Absolute reliability: The compiler should never crash (all fatal bugs fixed by EOY). Compiler errors should always be actionable and clear.
[ ] Code Quality: Elevate maintainability across the board—compiler (especially type system, analyzer, desugarer) and runtime alike

Community & Growth

Neva’s big ambition is only possible if you join in! There’s no other language combining strong static typing, dataflow, and built-in parallelism in quite this way. In 2026, I want to focus more on:

Community (website, Discord, Reddit, Twitter, Hacker News, donation platforms, maybe investors)
Listening: Why did you get interested in Neva? What do you want to build?
Showcasing your stories and creations!

If you want more context about dataflow and why I see Neva as pioneering “the future of programming,” check out this dev.to post.

Thank you for a wild, emotional, progress-filled year. Here’s to bigger, bolder things for Neva in 2026, together!

—Emil

HTMX, AlpineJS, SSR v1/2/3 and SPA | Easy missing guide.

Emil Valeev — Wed, 06 Aug 2025 08:50:12 +0000

Preface

HTMX and AlpineJS are two JS libraries that extend HTML with special attributes and allow you to build frontend interfaces without SPA frameworks.

They are alternatives to React/Vue/Angular and the like. Their emergence is a response to fatigue from the complex JS ecosystem and nostalgia for the times when problems were solved with PHP and jQuery.

All my life I’ve written JSON APIs and SPA interfaces, and my brain struggled to understand why these libraries are needed and how to use them. That's why I wrote this article.

HTMX vs AlpineJS — What Do They Handle?

These two libraries have some overlap in functionality, but each generally solves its own problem.

HTMX: For making AJAX requests to the server, receiving HTML, and dynamically updating parts of the page.
AlpineJS: For logic tied to local client state. All sorts of isVisible flags, conditional rendering, etc. In short, anything that exists only on the client. Another way to think about it — HTMX connects the frontend with the database (through the server API), and AlpineJS is a convenient way to have state on the frontend and render the UI dynamically from it.

Server Side Rendering vs SPA

Disclaimer: Terms v1 and v2 are my own.

SSR v1 (Web 2.0, PHP era)

Classic server-side rendering existed before the term itself became popular, simply because there was no other kind of rendering.

This is when the client makes a request to the server, the server returns an HTML document, and the client (browser) fully redraws the entire page. The user experiences a "reload".

This was typical for Web 2.0 era sites, and such UX is no longer considered high quality because:

It's not responsive enough.
It doesn't support local state — all state is stored on the server. Anything you entered in a form, any menus you opened, all will be reset after a page reload.

SPA (Single Page Applications, ReactJS era)

As a response to the problems of SSR v1 and Web 2.0, SPAs (Single Page Apps) appeared.

This is a confusing name because, from the user's perspective, a site/app can have as many pages as needed.

"Single page" here is in a purely technical sense. It means that now we have a single HTML document (page) and the entire UI is rendered dynamically via JavaScript.

This solved the two problems above but created a bunch of new ones. There was now a lot more logic on the client, but the technologies for this were not ready. JavaScript was designed for writing small scripts and didn’t scale well as codebases grew.

In response, other technologies started to appear, such as TypeScript and bundlers like Webpack (and modern alternatives), linters, test runners, package managers, etc. All of this infrastructure was fragmented, with no official support from language authors (unlike Go), requiring developers to maintain it themselves.

This led to the situation where the person responsible for the frontend also had to handle “build” tooling. There are a lot of tools to master and configure, and some of them periodically break backwards compatibility.

In short, frontend became very complex. And this complexity wasn’t from the tasks themselves, but from the low quality of the tools, which developers had to fight endlessly instead of just solving business problems.

Add to this the fact that in the JS world, every weekend a new framework pops up, and the ecosystem is constantly shifting and changing.

All this led to “JS fatigue” (c).

SSR v2 (NextJS era)

I won’t call it Web 3.0 since that term is more about decentralization.

Server-side rendering v2 wasn’t about JS fatigue, but about solving a technical problem — search engine indexing.

When SPAs appeared, search crawlers weren’t adapted for such sites. They still expected the server to return static HTML, but instead got HTML with nothing in it, requiring JavaScript execution to render content.

Modern crawlers can handle this, but server-side rendering is still preferred for SEO. Search indexing is complex, with many nuances. Let’s just accept the fact that:

SEO <3 SSR

So, on one hand, we want dynamic SPA interfaces, on the other we want static HTMX for SEO, as if we had SSR. What to do?

The industry made a full circle back to server-side rendering, but now using different technologies.

Previously, a PHP server would query the database, generate HTML via a templater, and return it to the client. Now, a NodeJS server runs JS inside the HTML page to generate static HTML and send it to the client. This way, we could keep using SPA frameworks like React and have lots of client-side logic, but the initial HTML received by the browser wasn't empty — it had meaningful content for indexing.

HTMX and AlpineJS as a Cure for JS Fatigue

Technically, the latest evolution solved all problems except one — there’s still too much JavaScript, and it’s still unpleasant and complex to write. “Unpleasant and complex,” by the way, isn’t just a vibe, it’s direct business damage. As your codebase grows, it becomes harder to change, so development gets more expensive. Fatigue converts directly into money because both are about energy.

HTMX as SSR v3

Disclaimer: SSR v3 is my own term.

HTMX philosophy:

Modern frontend is often unjustifiably complex. We should try to return to the origins of server-side rendering.
In the early web, there was the idea of Hypermedia — linking documents via hyperlinks, and the browser as the engine loading them. Think tags like <a>, <form>, <script>, <style>, <img> that could make requests without JavaScript. Unfortunately, the modern web moved away from this and became JS-heavy.
Returning to pure SSR v1 is impossible, because the modern world really does require more responsive interfaces. The compromise invented was fragments — let the server return HTML as before, but not the whole page, just its “fragment,” which JavaScript can insert/replace in-place. As a result, only part of the UI is rerendered for the user, as if it were an SPA. At the same time, it’s true server-side rendering, with all its advantages.
This led to a JS library that extends (HTMX = HTML eXtended) standard HTML with a small set of extra attributes, making any tags hypermedia, not just forms and links.

HTMX vs SPA — A Paradigm Shift

By now, it should be clear, but I’ll spell it out, as my SPA-optimized brain didn’t grasp it at first.

HTMX and SPA (React and others) imply different approaches to application architecture.

SPA: The server returns structured data (usually JSON), and the client renders HTML based on that data.
HTMX: The server returns HTML, and the client just inserts/replaces this HTML on the current page.

That is, rendering logic moves from client to server.

Technically, we have a set of HTTP endpoints returning HTML snippets and our client, which calls these endpoints in response to browser events (scroll to element, button click, etc.).

Important: There is no client state! Only server state.

We move away from client SPA libraries like React, with their branching, loops, etc. All this logic goes back to the templater, just like the good old days!

And we don’t write any JavaScript at all — only HTML with a few extra attributes.

Important: HTMX is not a silver bullet. I’ll repeat — there’s no silver bullet. This approach has downsides and may not suit you. More on that later.

AlpineJS as the Missing Piece

HTMX does nothing to help with client-side state. If you need some purely frontend logic (even something as simple as disabling a button under a custom condition), you’ll need to write JavaScript.

You have three choices:

Go back to SPA (and maybe SSR v2), with all that entails.
Write vanilla JavaScript, no libraries.
Add a library — but not a full-blown SPA framework with build step, just something simpler.

AlpineJS fits exactly this niche. It brings back client-side state and lets you code frontend logic. Now you can disable that button under your custom condition, with branching, loops, etc., like you’re used to in React.

It looks more like Vue than React, though. Alpine extends HTML with a few extra attributes, like HTMX, but with Alpine, you do write a little JavaScript (a lot less than going vanilla).

Yes, native JavaScript is actually very low-level, as odd as that sounds. Its DOM API is imperative and verbose, and for many basic things needed in every project, you’d have to hand-code from scratch. It’s not like Go’s standard library, where the devs sat down and thought about the real-wo

HTMX + AlpineJS vs SPA. Downsides of SSR v3

If you compare this approach to classic SPA (or SPA + SSR on something like Next), it might seem like this approach is all pros. You get the best of both worlds and don’t pull Node into your project. Of course, that’s not the case. There are situations where this stack isn’t suitable, and you’re better off with React or Next.

If you have a lot of complex client-side logic that can’t be moved to the server. A grotesque example is Figma. That’s way more of an “application” than a website. Extremely high interactivity and a need for low latency.
Also, HTMX and AlpineJS don’t provide static typing like TypeScript does. If you want full type coverage between client and server, this stack isn’t for you. You may have typing at the template level (e.g., Templ if you code in Go), but from HTMX you can, for example, make requests to non-existent endpoints, reference non-existent DOM nodes, etc. Maybe there’s a solution in the community, but it’s not out of the box, so it won’t be as minimalist. Why you might want full typing is another question; it’s usually about codebase/team size. With AlpineJS, it’s exactly the same.

If you like this article, support my open-source projects:

The Ultimate Guide to Parallel Testing in Go: -p, -parallel, and t.Parallel() Demystified

Emil Valeev — Thu, 13 Feb 2025 12:05:00 +0000

Go has three ways to tweak parallelism in tests:

-p flag
-parallel flag
t.Parallel() function call

How many of you know what they do? Why do we need all three? :slight_smile:

It turns out -p controls "how many test packages can run in parallel," -parallel determines "how many test functions inside a single test package can run in parallel," and finally, t.Parallel() marks a test function, telling Go that it can be run in parallel with other functions in the same package.

Example 1

Example: Let's say we have 999 packages with 999 test functions each, but not a single test function uses t.Parallel(). What will happen?

Answer: N test packages will run in parallel (where N equals the number of CPU cores), but each package will run its test functions sequentially. So, N test functions will run in parallel.

Example 2

Another example: same scenario, but we add -p 1. What will happen?

Answer: completely sequential execution.

Example 3

One more example: same as before, but this time we add t.Parallel(). Well, t.Parallel() combined with -p 1 results in "only one package runs at a time, but N test functions run in parallel," where N is again the number of CPU cores.

Conclusion

The most fine-grained control is achieved using all three: -p X -parallel Y and t.Parallel().

We need to be careful with stateful tests (as usual, state is the root of all evil, but it's impossible to avoid).

The Neva Programming Language

Go developer? Check out Nevalang - it's a work-in-progress programming language built on top of Go, that fixes some of Go's issues such as data-races, nil pointer-dereference, etc. In 2025 it will have visual editor, Rust-like enums and much more. Eventually you will be able to call it from Go and vice-versa.

Interested? Give us a star and join our community. We need developers (not just gophers!) to contribute and test the language. Let's change programming together - Go is awesome but we can do even better:

How Programming Will Look In the Future?

Emil Valeev — Tue, 21 Jan 2025 21:52:12 +0000

Programming hasn't fundamentally changed since the 1940s. Most languages still follow the von Neumann paradigm: write sequential instructions and modify data in memory. Let's look at a simple example:

total = 0
for number in range(1, 6):
    total += number
print(total)  # Outputs: 15

Simple and familiar, right? But there's a problem. Modern computers aren't getting faster like they used to. Instead, they're getting more cores, and our traditional programming model isn't great at handling multiple cores efficiently.

The Multi-Core Challenge

We've tried to adapt with tools for concurrent programming. Take Go's goroutines:

package main

import (
    "fmt"
    "sync"
)

func main() {
    var wg sync.WaitGroup
    numbers := []int{1, 2, 3, 4, 5}

    for _, n := range numbers {
        wg.Add(1)
        go func(x int) {
            defer wg.Done()
            fmt.Printf("Processing %d\n", x)
        }(n)
    }

    wg.Wait()
    fmt.Println("All done!")
}

These solutions help, but they introduce problems like race conditions, deadlocks, and complex state management. We're building on top of a paradigm that wasn't designed for parallel execution, and control-flow languages are inherently hard to visualize.

A Different Approach: Data Flow Programming

What if we could write programs differently? Imagine describing your program as a network of independent nodes that pass data to each other - no shared state, just data flowing through a system:

Everything runs in parallel by default
Data is immutable, preventing race conditions
Program structure mirrors data flow
Natural scaling across multiple cores

Enter Nevalang

Nevalang does exactly that. It's a modern language built around dataflow that treats programs as message-passing graphs rather than sequences of instructions:

import { fmt }

def Main(start any) (stop any) {
    for_print For{Print}
    wait Wait
    ---
    :start -> 1..5 -> for_print -> wait -> :stop
}

Here we define a component Main that receives a start signal and sends a stop signal. It has two nodes: for_print (a For with Print inside) and wait. When started, it creates a stream of numbers 1-5, prints each through for_print, waits for completion, and sends the stop signal.

Visualized:

Nevalang represents a fundamental shift in programming, embracing a paradigm naturally suited for parallelism and visualization rather than fighting traditional programming limitations.

Try Nevalang on GitHub

The future of programming might not look like the past. As our hardware continues to evolve, our programming models need to evolve too. Nevalang shows us one exciting possibility for that future.

WARNING: Nevalang is currently in development and not yet production-ready. We're looking for contributors and early-adopters. Join!

This is an ambitious project maintained by a small group of enthusiasts. Your support by joining us will show interest and motivate us to continue.

Please give us a star ⭐️ to increase our chances of getting into GitHub trends - the more attention Nevalang gets, the higher our chances of actually making a difference.

🕵 Agency: The Go Way to AI. Part 1

Emil Valeev — Sat, 25 Nov 2023 19:55:48 +0000

Making AI Easy for Go Developers

The growth of generative AI like the OpenAI API and local LLMs is reshaping app development. Python and JavaScript have plenty of tools for this, with LangChain being popular. However, Go developers have fewer options. LangChainGo, a Go version of LangChain, doesn't fit well with Go's style, and some also find LangChain itself to be too complex.

Recognizing the need for a Go-friendly tool that’s simple yet powerful, we developed Agency. This Go library, designed with a clean approach, matches Go's strengths in a static type system and high performance. It's our answer to bringing easy-to-use, efficient AI capabilities to Go developers.

Example - Continue Text

Let's start from the simplest possible example - chat completion. For simplicity, we'll break it down piece by piece and then combine it into a single, cohesive example.

First, we need to create provider:

provider := openai.New(
    openai.Params{Key: "YOUR_OPENAI_API_KEY"},
)

Provider is a set of operations implemented by some external service. In this case, it's OpenAI.

Note that we passed this Params struct. In case of local LLM (must have OpenAI-compatible API) we can pass openai.Params{BaseURL: "YOUR_SERVICE_URL_HERE"}.

Now that we have a provider, it's time to create an operation:

operation := provider.
    TextToText(openai.TextToTextParams{Model: "gpt-3.5-turbo"}).
    SetPrompt("You are a helpful assistant that translates English to French")

This TextToText method that we call is an operation-builder - a function that takes some params and returns an operation, a value of type agency.Operation.

Operations are basic building blocks.

This one operation-builder has this signature:

func (p Provider) TextToText(params TextToTextParams) *agency.Operation

This TextToTextParams struct is specific to concrete provider and operation-builder. It depends on what external service provider uses and what functionality (modality) it implements. Almost any provider/builder allows to specify Model but we'll see differences later on.

For example, Anthropic provider could have different params than OpenAI and openai.SpeechToText operation-builder will also have different params because of using different models under the hood than text to text (whisper instead of GPT).

Now see this SetPrompt("You are a helpful assistant that translates English to French") line? This is how we configure operations. In this case we configure prompt that will be used.

Okay, it looks like it's time to talk about what operations really are. Let's dig into the library source code:

// Operation is basic building block.
type Operation struct {
    handler OperationHandler
    config  *OperationConfig
}

// OperationHandler is a function that implements the actual logic.
// It could be thought of as an interface that providers must implement.
type OperationHandler func(context.Context, Message, *OperationConfig) (Message, error)

// OperationConfig represents abstract operation configuration.
// It contains fields for all possible modalities but nothing specific to concrete model implementations.
type OperationConfig struct {
    Prompt   string
    Messages []Message
}

At the time of writing, the library has version v0.1.0 and is under active development, so implementation details may change, but the main idea should remain - operation consist of handler and config.

Handler is a function implements actual logic. It's signature (just like commentary says) could be "thought of as an interface that providers must implement".

Now let's look at what this SetPrompt("...") method does:

func (p *Operation) SetPrompt(prompt string, args ...any) *Operation {
    p.config.Prompt = fmt.Sprintf(prompt, args...)
    return p
}

That's it. It simply configures the operation and implements templating via fmt.Sprintf.

Are you still here with me? We're almost finished! The scariest stuff is behind.

Actually, our operation is ready to use! Now we need to use something as an input for our operation, right? Let's create a message:

input := agency.UserMessage("I love programming.")

We aren't scared of digging into the source code, are we? Here's the UserMessage implementation:

func UserMessage(content string, args ...any) Message {
    s := fmt.Sprintf(content, args...)
    return Message{Role: UserRole, Content: []byte(s)}
}

That's right, it's just a tiny helper for Message. What's that? It's an abstract message that represents any possible message that operations operates on:

type Message struct {
    Role    Role
    Content []byte
}

We already saw this message before, in operation's definition:

func(context.Context, Message, *OperationConfig) (Message, error)

That is - operation is a function that takes message as an input and returns message as an output.

Finally, let's execute our operation and see what happens!

output, err := operation.Execute(context.Background(), input)
if err != nil {
    panic(err)
}

Now let's put it all together!

provider := openai.New(
    openai.Params{Key: os.Getenv("OPENAI_API_KEY")},
)

operation := provider.
    TextToText(openai.TextToTextParams{Model: "gpt-3.5-turbo"}).
    SetPrompt("You are a helpful assistant that translates English to French")

input := agency.UserMessage("I love programming.")
output, err := operation.Execute(context.Background(), input)
if err != nil {
    panic(err)
}

fmt.Println(string(output.Content))

Don't forget to insert your OpenAI API key. Here's my output:

J'adore la programmation.

Looks like it works! You can of course rewrite this in a tighter manner if you want.

openai.New(openai.Params{Key: "YOUR_OPENAI_API_KEY"}).
    TextToText(openai.TextToTextParams{Model: "gpt-3.5-turbo"}).
    SetPrompt("You are a helpful assistant that translates English to French").
    Execute(context.Background(), agency.UserMessage("I love programming."))

That's all for now! Thank you very much for reading this. If you find any mistakes, please leave a comment. Link to this and many more working examples as well as link to the library itself gonna be below.

We want to create the best library in the field and we need help. Feature-requests, bug-reports and of course pull-requests are more than welcome. We'll try to provide feedback as soon as possible.

In the next series, we will explore topics such as:

How to create ChatGPT-like application in 40 lines of code
How to combine operations in chains to execute them sequentially
How to create custom operations
How to use interceptors to observe operation-chains
How to use prompt-templating
How to use different modalities (speech, images, etc)
How to implement RAG (using vector databases)
... And many more!

Links: