I want something that will bring productivity of Delphi to Web. May be I am old now, but I could have built applications in a weekend in Access or Visual Basic that will take weeks now in latest web stack.

OutSystems, but it isn't cheap.

Right? I was hoping webassembly would bring back some proper gui tools like this to avoid the whole JS/DOM but no luck so far.

Blazor is pretty cool if you are into that kind of stuff. Mind you, you still might need the slightest tiny dash of JS, but depending on your needs, you might be able to get away from JS entirely.

Somewhere its in my list of things to try one day. Maybe an ai agent can help make this happen.

ASP.Net Web Forms still exists, though it is deprecated.

Eh. I admit I just use AI now when I want to quickly build a web app like that. I built a huge content management system in a couple of hours that way.

If you're talking Windows desktop apps like Delphi used to do, then Visual Studio WinForms is still just like that in 2026 and still getting updates.

What about Lua? The language is very minimal, memory safe, and has Pascal-like syntax just like Delphi.

Lua's variables being global by default seems somewhat error-prone.

Agreed, but the recently-released v5.5 fixes that [0], and it's fairly easy to fix this in older versions with the following snippet

  setmetatable(_G, { __newindex = false, __index = false })

[0]: https://www.lua.org/manual/5.5/manual.html#2.2

verything is an off by one error in Lua.

Or conversely, everything is an off-by-one error in every other language :)

*everythin

> Rust without the crazy town complexity.

To be clear, the language has a GC then?

I suppose it could have some kind of ARC. In theory some future languages could even have some hybrid approach? A high perf default but you can fallback to a GC allocation for hard things?

I'm pretty sure that there are multiple GC crates for Rust out there. But using them mixed in with non-GC variables presumably makes things more complex.

Oberon 07?

What would you take out of C# etc?

(not OP) I would take out mostly historic stuff, that is in there for backwards compat, that has been superseeded. But this could be achieved using linters.

All non-generic container classes and nullable reference types.

> nullable reference types.

What would you suggest instead? I quite like the nullable reference types, but I do know many get annoyed. My brain is often a scurry of squirrels, so I grew to become thankful for the nullable refs overtime.

The compiler now mostly solves this now but the abstraction is a little leaky.

I heavily use nullable types but I always want them to be declared nullable.

I don't mind NRT but I hate dealing with C# projects that haven't set < Nullable>Enable</Nullable> in their csproj. It's not perfect because I know at runtime it can still be nullable but it's nice when the compiler does most of the checks for you.

Sounds like golang to me

Without the features I identified,yes, you’re right!

Considering they used Go for the native compiler he might actually agree with you.

C# is way to go then

>We need Anders to make one final language.

I do feel like there is a gap for a modern compiled, functional and garbage collected language.

Go isn't it because it lacks the functional constructs.

C# and Java aren't it because they depend on a VM.

Rust isn't it because of its difficult memory management.

Swift isn't it because it is so tied to Apple and their platforms.

What you are looking for is called F#. You get native interop with C# and access to all .NET/C# libraries as a bonus. We use it as a daily driver for a complex B2B2C cloud platform.

Does it not run in a VM?

Yes you are right, it does not properly support NativeAOT yet.

But it isn't a need for most use cases, unless you want to do mobile development and meet app store policies. But even then, mature F# frameworks like Fable transpile your F# code to React & Cie.

It can be compiled, but that’s not the use case it was originally designed around, so it’s not quite as first class an experience as with Go or Rust.

You can embed the framework into the application so it is a single distributable.

C# doesn't depend on a VM these days when it is AOT compiled. Same for Java, though C# is rather more user friendly in how it goes about it.

> C# doesn't depend on a VM these days when it is AOT compiled

Maybe I’m being pedantic, but this is an oxymoron. Also the premise is incorrect. It’s not like the VM is gone. Merely baked into the code at compile time. It compiles IL to native code. Same for IL2CPP. The VM is still there.

The term “virtual machine” is confusing. I think you meant to say JIT compiler :-)

The trouble with that level of pedantry is that you then can point to LLVM as a VM and say that Clang and other C/C++/Rust tools that AOT through LLVM are "too tied to a virtual machine". Then you can go back through the history of cross-platform optimizing C/C++ compilers and find VMs in the design in almost all of those, too. LLVM is not hiding it in its very clear name, but low-level VMs were a thing for decades before someone named LLVM.

VMs have a long history in cross-compilation, even for "low-level" languages like C/C++. The AOT versus JIT distinction is blurry, and the "VM language" versus "non-VM language" boundary is blurrier still, especially when you take into account "standard runtimes" such as glibc and vcrt and whether or not those are statically linked.

Is a C program with a compiled with Clang through the LLVM dynamically linking a glibc and statically linking a Boehm GC library "running in a VM"? There's no wrong answer, it's a lot shades of gray. I believe almost every pedantic way to answer that has an equally pedantic counter-argument.

There are plenty of languages in that niche you could be using. OCaml, Haskell, F#...

Kotlin has a LLVM backend, among others.

Roc might be that language one day. Not yet because it's pre-0.1.

C#, with default tooling, can compile without needing a VM, for windows, macOS, linux and some other platforms.

I wish that Nuget would show which packages are NativeAOT compatible.

It will probably get there one day since all BCL is annotated. Perhaps this is not done because you can have parts of the library be completely safe to use in AOT while another part not be.

That's the problem though. People want one language to be The One (tm) and that's just not possible. Your The One (tm) isn't mine.

I don't see why a VM is a problem, personally, and I like a lot of what C# has been exploring with `Span<T>` and `Memory<T>` for safe low-level memory management in a garbage-collected language. Some of it seems like a simpler Rust. Rust can still do plenty of memory lifetime things that C# can't, but the gap is smaller than ever and C# is still slowly growing its capabilities in that space. All that in a language where you don't have to start with the low level tools, you can prototype entirely in higher-level garbage collected space and use real world performance to guide optimizations towards the low-level memory management tools only when they become truly necessary.

The minimal memory-safe language is Go. Turns out it's too minimal for most.

It’s not memory safe.

Please elaborate. I've heard that you could break Go's memory safety through a race condition, but that's as far as my knowledge goes.

On the .Net VM you’re describing F#, mostly by virtue of being based on OCaml.

Contrasted with TypeScript and C#, F# is smaller, more expressive, stricter, with mature pattern matching and type resolution baked in from the ground up. F# was years ahead of the major languages on what are increasingly looking like ‘the basics’ around ADTs and immutability in modern distributed computing. OCaml and F# capture the linguistic high points of VB, Delphi, and C# with a broad spectrum of OOP(-lite) approaches, and have led those languages by decades on functional constructs that result in meaningfully tighter code. With the benefit of hindsight some approaches clearly map better to cloud computing and system verification.

F# also sits parallel to lots of living C#, objectively we see ‘less is more’. Less code per line, fewer lines per solution, terser and more LLM-efficient language. Error rates and refactoring costs are also meaningfully better IME, but harder to quantify in general terms.

It’s a great language. I just wish its compilation speed matched that of OCaml.

Yeah exactly.

Hardly, even Turbo Pascal 7 for MS-DOS is more advanced than Go's type system.

You don't have to use all the features of C#. I make my living at it and don't touch a lot of them. The issue with C# is culture. They went full in on blog driven development so there's way too many people who will yell this is the way to do things this week.

It's true. You will incur the wrath of C#'ers if your simple ToDo list app doesn't have a ToDoListItemRepositoryServiceFactory.cs and a minimum of 4 separate layers in which one must update 20 files because you added a property to one class.

Don't get me wrong, I still love C#/.NET. I use it everyday, but my god, has Swift been a breath of fresh air. The Swift community, when not whining about Swift UI, has been much less dogmatic in my experience.