dsrw

23 dni temudiscuss

Enu is an MIT licensed 3D sandbox for learning to code, experimenting, and having fun. In this video we implement an out of process MCP server and teach Claude to build 3d worlds in Nim.

dsrw

3 lata temudiscuss

That's my history too. I remember spending hours in the 80's drawing LINEs and CIRCLEs in a loop, making tunnels, flowers, and whatever else I could come up with that looked cool. I didn't ever finish anything really, I mostly just played around, but it felt like I was on the cusp of something new and exciting, and that anything was possible.

That's the feeling I'm trying to capture with Enu. I'm sure it won't land for a lot of people, and that's ok, but I hope someone out there finds it and makes something really amazing, even if they're the only one who can see it.

dsrw

3 lata temudiscuss

Enu author here. I taught it to a group of 11 year olds at a community coding club a few years ago, with reasonable success. At the time Enu didn't work very well, but by the end the kids were able to code simple structures and make monsters chase them around. I just started teaching it to my 8 year old and he's picked up a few things, but so far he's mostly interested in building things with blocks. We've only been at it for a couple of hours though.

Enu was designed to be usable by non-readers and new typists. There's a shorthand version of common commands, and as long as you're happy with 90 degree angles you can specify direction without numbers. For example, a box could be:

  f 10 # forward 10
  r 10 # right 10
  b 10 # back 10
  l 10 # left 10

or:

  4.x:    # 4 times
    f 10  # forward 10
    t r   # turn right

It can also be configured to interpret both `;` and `:` as `:`, which makes it possible to type a lot of common Enu code without needing the SHIFT key.

Enu only recently got to a state that I'd consider usable, so whether or not this is enough to make it work for younger kids, I'm not sure. But I'm hopeful.

http://getenu.com

dsrw

3 lata temudiscuss

Yes. It’s so you can maintain a consistent style in your code base even if your dependencies use different styles. Nim has excellent C/C++ interop and it’s relatively common to interact with C or C++ symbols directly, and being able to do this without needing to adopt the dependency’s style or wrap everything is nice.

In python, for historical reasons the logging module uses camelCase while most other modules use snake_case, so it isn’t really possible to use the logging module and maintain a consistent style. This is a non-issue in Nim.

dsrw

3 lata temudiscuss

Enu is a multiplayer programming environment powered by Nim and Godot. It's meant to teach kids to code, make 3D game programming easier, and for experimenting and having fun. It's MIT licensed and will be usable to create standalone games.

Enu is powered by the belief that text based programming can be accessible to kids if made simple enough, and that text is more flexible than visual programming using tools like Scratch and Game Builder Garage. I still have lots of work to do to improve discoverability, but based on my experience using it to run a coding club and teaching my own children, I believe the theory mostly holds. It's inspired by Logo and Minecraft, has a terse syntax for building nested state machines (although it calls them Command Loops), and tries to make it possible to build full games using only simple concepts like loops and conditionals.

I've been working on Enu for almost 4 years now (very much part time) and have put out a few releases already, but I believe this is the first version that really captures what Enu is all about. Let me know what you think!

dsrw

3 lata temudiscuss

Hey all. Enu is my project, and it's really nice to see some interest. It looks like I'm a few days late to this thread, but I'd be very happy to answer questions if anyone is still around.

The first real MVP of Enu will be releasing before the end of the month. 1.0 is years off, but the basics are mostly there and it seems like a good time to put up a web site, write some docs, and see if people actually want to use the thing.

dsrw

3 lata temudiscuss

Thank you! I hope so. My bet is that text based code can be as easy as drag and drop (but much more flexible) if things are kept extremely simple and concise, and the commands and keywords are discoverable. I think I've made good progress on the simple and concise bit. Discoverability needs work, but I believe it's solvable.

dsrw

3 lata temudiscuss

Thanks! I suppose it's primarily, but not exclusively, aimed at kids. It has rudimentary multiplayer support now, and my hope is that it can be a place for people to build and learn together. I want schools to use it for programming classes, and for friends and families to hang out, teach each other, and build simple games together.

dsrw

3 lata temudiscuss

Initially I used Godot’s scene format to store Enu’s levels, so someone could learn and prototype in Enu, then load the project into Godot for things Enu didn’t support. That didn’t really pan out though and I’ve dropped the idea for now. I’d love to revisit some day.

Currently Enu is just a consumer of Godot. I’ll update the description soon. Thanks for the interest!

dsrw

3 lata temudiscuss

This particular example isn't actually an issue in Nim. The first letter of a nim identifier is case sensitive, so while `my_thing` and `myThing` are normalized to the same name, `my_thing` and `MyThing` are different.

dsrw

3 lata temudiscuss

Essentially nobody was a "JavaScript Developer" in 2005, 10 years after JS's release. JQuery didn't exist yet, the term "AJAX" hadn't been coined, and NodeJS was years away. Web developers were using JS to enhance pages, but it wasn't a language that was widely used to write applications. I don't know what the popularity numbers looked like so I'm not saying you're wrong, but it was definitely closer to 15 years before people started to take JS seriously.

JS aside, I think there's probably some survivorship bias going on here. I don't think there are a lot of 15 year old, relatively unpopular languages that are still under active development. Maybe it's not that languages that don't become popular in 10 years never will, but rather that languages that don't become popular in 10 years tend to be abandoned by their developers, thus sealing their fate.

dsrw

3 lata temudiscuss

It's a weird license that seems to say "you can use this as long as you don't compete with us", with an automatic switchover to Apache 2.0 in 5 years. Definitely better than closed source, but probably not Open Source by the OSI definition.

dsrw

3 lata temudiscuss

https://github.com/dsrw/enu - Enu is a 3d live programming environment for experimenting, making games, and learning to code. Kind of a Logo meets Minecraft type thing. It's written in Nim (using the Godot game engine), and also uses interpreted Nim for the in-world scripting.

I use it to teach kids to code. The released version is pretty rough and probably not fit for general consumption, but the next release (coming next month... I hope) is quite a lot better.

https://youtu.be/9e9sLsmsu_o is a demo making a simple survival game, and https://youtu.be/upg77dMBGDE is a now very outdated demo building towers and other simple structures. Thanks!

dsrw

4 lata temudiscuss

I tried Nim on a lark 3 years ago. I was writing a learn-to-code tool in Godot and was getting frustrated with some of the limitations of GDScript, so I decided to build it again in Nim. It was very much a "I don't want to do what I'm supposed to be doing right now, so instead I'll play with something shiny" moment, and I fully expected to hit a wall within a few hours and get back to doing things the normal way. But the wall didn't come, and after a few days with Nim I tossed the GDScript version.

In no particular order, things I like about Nim:

- It has most of the benefits of a scripting language, without most of the tradeoffs. Hello World is a one-liner, there isn't much syntactic noise, and it's very easy to write short, simple, useful programs that look like pseudocode, live in a single file without any dependencies, and can be kicked off with a shebang line. However, unlike scripting languages, it scales very well to large projects.

- Progressive disclosure. You can use Nim effectively while knowing very few of its features, but there's a lot of functionality available when you're ready.

- The "if it compiles, it works" factor is quite high. Not as high as Rust or Haskell, but higher than Java or Go, in my experience.

- The "it compiles on the first try" factor is also quite high. Higher than any language I've tried. "I wonder if this will work..." code usually does, the advanced features of the language mostly stay out of the way until you need them, and I rarely find myself working just to make the compiler happy. Just as an example, unless you add specific constraints, generics are "duck typed". If I pass a type to a generic proc the compiler will verify that it has the properties and functions the proc needs, but I don't have to define a specific interface up front.

- Similar to the above, the productivity vs safety balance seems right, at least for me. Code is fairly safe by default, but it's easy to work around the compiler if you need to do something it doesn't want you to do. It's also pretty easy to enforce additional safety when you need it, like ensuring a function can't throw exceptions or have side-effects.

- It's very good at building abstractions and eliminating boilerplate. Nim templates and generics are easy to use and quite powerful, and macros are there if you need something more advanced. Many features that need explicit compiler support in other languages, like async/await and string interpolation, are implemented in the Nim sdlib with macros, not the compiler.

- Nim produces standalone binaries that are both small and fast.

- The compiler is faster than most.

- The compiler can be imported as a library, making it pretty easy to write tools that understand Nim code.

- Nim programs are usually compiled, but there's also an interpreter. The compiler uses this for macro evaluation and for running build scripts, and it's easy to embed if you want your program to be scriptable.

- Nim can run on pretty much anything.

- Nim can be used to build almost anything. You can use it for systems programming, webdev (frontend and backend), games, ML, scripting, scientific computing, and basically anything else. There are definitely some domains where library support is lacking currently, but the language itself is suitable for any type of program.

- It's very flexible. Most Nim code is imperative, but it's easy to write functional, declarative, or OO style code if that's your thing.

If you prefer languages like Go that favor an abstraction-free style, where everyone's code looks more or less the same, you probably won't like Nim. However, if you want something more expressive like Ruby or Lisp, but don't want to sacrifice performance or safety, Nim is definitely worth a look.

Submissions

NimConf 2026: Extending Enu, and building 3D worlds with Claude

Enu: Learn to code and build 3D games in Nim

comments