Show HN: W++ – A Python-style scripting language for .NET with NuGet support

59 comments

·May 30, 2025

Hey HN

I’ve been building *W++*, a scripting language that looks like Python but runs on the .NET runtime. It started as a fun side project, but it evolved into something surprisingly powerful — and potentially useful:

Key Features:

- Python-style syntax with semicolon-based simplicity

- Compiles to .NET IL with experimental JIT support

- Can run interpreted or compiled

- Built-in CLI for managing projects, running, and building

- Supports importing NuGet packages and converts them to .ingot modules automatically - MIT licensed and fully open-source

You can even do things like:

    wpp
    import Newtonsoft.Json

    let person = new JObject()
    person["name"] = "Alice"
    print person["name"];

 Use Cases:

Game scripting (Unity, OpenTK support in progress)

Education (gentle intro to .NET without C# syntax)

Blazor scripting

Embeddable scripting engine for .NET apps

GitHub: https://github.com/sinisterMage/WPlusPlus

I’d love feedback, ideas, and thoughts. Thanks for reading — and if you’ve ever said “I wish Python ran on .NET,” this might be for you.

Visit

bob1029

I think this is fun stuff. I always enjoyed building things like this.

That said, in 2025 if I was already willing to utilize C#/.NET, I would probably prefer an "internal" DSL approach [0] - i.e., one that leverages the host language directly and builds the abstractions on top.

Examples of this would be fluent interfaces and methods like ConfigureDomainServices(Action<DomainServiceBuilder>). I know some developers frown on this approach, but I've embraced it as the least terrible way to go about handling things like AspNetCore web server configuration and setting up complicated data transformation pipelines. If these techniques are good enough for configuring a modern, production grade web server, they are probably good enough for configuring your domain too.

I spent a solid 3 years building & supporting an IronPython stack on the old 4.x .NET Framework and I learned a lot of lessons about how bad things can get when you begin coloring outside the lines. Memory leaks were probably the most difficult thing to reason about. Object lifecycles are already pretty tricky without the hosted language on top.

[0]: https://martinfowler.com/dsl.html

giancarlostoro

> I spent a solid 3 years building & supporting an IronPython stack on the old 4.x .NET Framework and I learned a lot of lessons about how bad things can get when you begin coloring outside the lines. Memory leaks were probably the most difficult thing to reason about. Object lifecycles are already pretty tricky without the hosted language on top.

I'm a little jealous ;) As someone who codes in both Python and C# mainly, never had to touch IronPython for an employer yet.

waldrews

It's sad that IronPython is effectively dead, but PythonNet is now very stable, complete, and friendly to recent Pythons.

e-master

pythonnet works, we use it in a pretty large (Python) codebase, but I’m much more excited about https://github.com/tonybaloney/CSnakes, which allows using Python in a proper statically typed language - C#.

sinisterMage

Thanks! I really appreciate you taking the time to write this up — super insightful.

I definitely get the appeal of internal DSLs, especially with how powerful C#’s fluent APIs have become. W++ takes a bit of a different path: more like “what if .NET had a native scripting layer that felt expressive and lightweight,” even if that means giving up some safety or flexibility of the host language.

And wow — 3 years with IronPython is no joke. Totally agree on how tricky it can get once you step outside the intended boundaries. I’m keeping W++ focused more on smaller, experimental scripting for now, but your point about memory and lifecycle management is a great reminder for anything that gets more ambitious.

Cheers for the link to Fowler’s DSL article too — gold.

sorezore

[flagged]

90s_dev

> Memory leaks were probably the most difficult thing to reason about. Object lifecycles are already pretty tricky without the hosted language on top.

I thought the whole point of these high level langs was that you don't have to worry about that?

sinisterMage

Totally fair question — most high-level languages do take care of memory for you, especially with garbage collection.

But in hosted scenarios like IronPython or W++ (where the language is layered on top of .NET), things can get trickier:

You're managing your own object model inside a host runtime.

If you're not careful, it's easy to create long-lived references (like global caches or circular structures) that the GC won’t clean up.

In IronPython's case, hosting decisions (like how objects interop with .NET classes) can leak unintentionally if lifecycle logic isn't airtight.

So yeah — you usually don't think about memory... unless you're writing the language

make3

Are you saying that IronPython in general has memory leak issues? or just because you were trying to add support for an old .NET framework

e-master

A bit of off topic, but recently I started learning F# because my new team at work uses it heavily, and even though I love writing in C# and even though the latest C# features are really nice (especially love patter matching), I wish now C# didn’t have the curly braces and semicolons at all, and used instead indentation based grouping like F# and Python does. That is practically all I wish I had in C#… and discriminated unions, but let’s be honest, what are the chances of that happening? ;)

pjerem

F# is an hidden gem, iteration 5 278.

I think it stays niche because it’s targeted at people knowing the dotnet ecosystem but most of those people reason a lot in OOP/imperative because well, they work with C#.

But it’s amazing to me that F# is still evolving and cutting edge after more than two decades of being extremely niche. You’d think Microsoft would abandon it or let it rot but no. Though I think F# is in fact the laboratory for new language features for C#.

csto12

All the comments from op are LLM generated and the project has some hallmarks of being LLM generated. This feels bizarre.

actuallyalys

I’m not sure all of them are LLM generated, but many are. Bizarre indeed.

zerkten

Does this start up quickly on the first execution? IronPython and other languages have problems with JIT resulting in minor delays to execution which are frustrating for quick scripts. There was a change in IronPython to interpret and not JIT on the first run to avoid this delay. Anything you use to remove JIT delays for quick scripts will increase the likelihood of adoption. Running JIT on repeat runs is a beneficial feature so you don't want to kill it entirely.

As others have stated, the use of semicolons while stating this is "like Python" is weird. Use language which avoids the direct Python comparison. It seems like your language is intended to be succinct. Just state that because it'll avoid negative reactions. I'm a C# and Python dev, so I'd rather you avoided this in-between state.

Killing semicolons and braces to embrace indentation would be my preference for a scripting language that is intended to appeal to my Python-side. If the intention is to appeal purely to C# devs, then don't mention Python at all because they often jump to "indentation, ugh" without considering your language.

sinisterMage

Thanks for the thoughtful feedback — you raised a few great points I hadn’t fully considered.

You're absolutely right about JIT startup time. Currently, W++ doesn't do any caching or ahead-of-time work, so there’s a delay on the first run. I’ll explore ways to keep it snappy for quick scripts — maybe a pure interpreter fallback for single-run use cases would help.

Also appreciate the insight on the Python comparison. That “in-between state” you described is exactly where I’m at — trying to blend Python’s simplicity with .NET’s power. But you’re right, the messaging could be cleaner. I’ll adjust the README to better reflect that W++ is its own thing and not a direct clone or pitch to Python devs.

This kind of comment is gold, seriously. Thanks for taking the time.

actuallyalys

I’m a little confused; it “looks like Python” but basically every snippet has elements that don’t look like Python. Ignoring the semicolons, which you do call out as a difference, I see let for introducing variables, new for creating objects, and a completely different lambda syntax.

Maybe the “looks like Python” means it uses significant whitespace? In that case I think the README should have an example demonstrating that.

To be clear, you can diverge from Python syntax all you want. I think you just need to be clearer about what you mean by “looks like Python,” maybe by providing an example that highlights the features that particularly resemble Python.

sinisterMage

You're totally right to ask — W++ borrows Python’s general feel (like significant indentation and dynamic typing), but its core is rooted in a C-style heritage due to the .NET foundation. So while let and semicolons aren’t Pythonic, the language avoids boilerplate, supports clean control flow, and aims for the readability people love about Python.

I’ll make the README clearer with a side-by-side W++ vs Python snippet to highlight the similarities better. Thanks a lot for pointing it out!

umanwizard

.NET by no means requires languages to be C-like, certainly not in trivial ways like having semicolons. F# for example (or for that matter, IronPython) is very unlike C. So whatever you’re trying to say here is still confusing.

Honestly I think you’re leaning too hard into the “Python” marketing. Python is not just a byword for “easy-to-learn dynamically typed language”. It is its own, specific thing, and your language is not the same. You could say something like “inspired by Python” (in certain ways), but claiming to target people who “wish they could write Python on .NET” strikes me as an exaggeration (especially since you can already do that).

sinisterMage

Totally fair point — W++ isn’t meant to be a direct Python clone, just inspired by its simplicity and clean syntax (like indentation and dynamic typing). The goal was to make scripting on .NET feel lighter and more approachable.

I’ll tweak the README to make that clearer. Appreciate the honest feedback!

smt88

I think this project is incredibly cool and lots of people will use this, but...

> significant indentation and dynamic typing

are absolutely the worst parts of Python. I can understand dynamic typing for scripting purposes, no real qualms there, but significant whitespace is on its face absolutely insane (significant characters that are literally invisible).

dontlaugh

I have the opposite opinion, having written Python for many years. Dynamic typing is almost never better or necessary, but significant whitespace makes for excellent syntax with no downsides.

sinisterMage

Thanks! Totally fair — I know significant indentation and dynamic typing aren’t for everyone.

W++ leans that way just to reduce boilerplate and keep the syntax clean for smaller scripts, but it’s not trying to be the “one true way” to write .NET code. Honestly, it’s all about exploring what a lightweight .NET scripting layer could feel like.

Appreciate you checking it out

null

[deleted]

hoistbypetard

> This repo contains the full source code of W++ after it reached over 33,000 downloads on the VSCode Marketplace — and was mysteriously flagged and removed.

Any insight into why that is?

sinisterMage

Yeah, so here’s the full story: when I first uploaded the W++ VSCode extension to the Marketplace, it took off faster than I expected — over 33,000 downloads in under 2 hours. A few days later, it was suddenly removed.

Only later did I find out it had been labeled as malware by Microsoft — no details, no warning. I emailed their support to clarify what triggered the flag, but I never got a response.

Since then, I’ve made the entire source public here, including the VSCode extension, so folks can inspect and use it freely. If anyone has experience navigating these kinds of takedowns, I’d definitely appreciate insights.

hoistbypetard

I hope it catches the attention of someone who might be able to find out.

osigurdson

One random / recurring thought that I have had recently is: realistically, how far off are we from being able to jot down some ideas about how a given language should look (or use Yacc / Antlr), then have the LLM generate the compiler, LSP as well as an entire set of common libraries in the new language?

gabrielsroka

It looks more like JavaScript than Python. Why isn't this linked to from the readme?

https://github.com/sinisterMage/WPlusPlus/blob/master/SYNTAX...

sinisterMage

Yeah, I totally get that! W++ isn’t meant to copy Python’s syntax exactly — instead, the inspiration from Python is in its simplicity and low barrier to entry.

I drew from multiple languages — Python, JavaScript, even a little C-style flavor — to make something that’s readable, expressive, and beginner-friendly, especially for quick scripting in .NET.

Appreciate the suggestion! I’ll make sure the SYNTAX.md is linked more clearly from the README.

noworriesnate

This is very cool! Do you have data flow analysis implemented anywhere? I’ve been thinking about building my own Python interpreter to help understand how info flows around inside a script generated by an LLM and data flow analysis would probably be a good place to start. I’m very familiar with the dotnet ecosystem so this could be something I’d be interested in contributing to.

sinisterMage

Thanks! That means a lot

W++ doesn’t have full-blown data flow analysis (yet!) — the current interpreter walks the AST in a fairly straightforward way, and the JIT just compiles expression trees without SSA or optimization passes. But your idea of analyzing LLM-generated scripts is super interesting. I'd love to explore basic flow inference or a visualizer in the future.

Feel free to open an issue or discussion if you’re curious — would be awesome to collaborate!

pansa2

Why does this post say “Python-style syntax”, but “SYNTAX.md” shows a “clean syntax inspired by JavaScript and C-like languages”?

sinisterMage

You're totally right to catch that — I’ll update it for clarity!

The idea was: W++ aims for a syntax that feels lightweight like Python (minimal boilerplate, indentation structure), but it also borrows C-style flow and expression flexibility. So technically it’s a bit of a hybrid:

Block structure + minimalism = inspired by Python

let, const, switch, and lambdas = more JS/C-style

I’ll clean up SYNTAX.md and the description to better reflect that. Appreciate you pointing it out!

frabert

https://boo-language.github.io/ The Boo language comes to mind as something similar

sinisterMage

Oh wow, I actually hadn’t heard of Boo until now — thanks for sharing it! Just took a quick look and yeah, I can definitely see some parallels. W++ wasn’t directly inspired by it, but I guess we both arrived at similar goals: a Python-style language that plays well with .NET.

debugnik

This was by the same author as UnityScript, wasn't it? IIRC the latter was mostly just Boo in a JS trenchcoat, which is why both were supported along with C#.

null

[deleted]

jarrell_mark

Semi colon is a non starter for me personally.

All the best and I’m sure many others will find this useful.

sinisterMage

Totally fair! I know semicolons aren’t for everyone — W++ leans into a mix of familiar C-style syntax with some Python-style simplicity, but it’s definitely not a perfect fit for all tastes.

Appreciate the kind words regardless — and who knows, maybe I’ll experiment with optional semicolons in a future version.

eddythompson80

For me, having semi colon be a non-configurable default is a non starter. Languages like Go or C take it too far. I prefer a typescript like language where semi colons are configurable through a config file or tool.

Typescript itself is a non starter because of non-configurable "brackets around if conditions" behavior. I pretty much write any language I wanna use these days depending on the task. Use the right tool for the right job. I do generally target perl 5.8 as a backend though. Seemed simpler and most widely supported backend across all systems I came across. Has been super stable since '02.