dsrw

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.

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.

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

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.

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!

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.

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.

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.

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!

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.

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.

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.

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!

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.

I haven't seen this at all, and am actually baffled that you're talking about dom. My experience of him has been the literal opposite.

He didn't cargo cult his software into the ecosystem. He made the ecosystem. Nimble is the package manager because there was no package manager until dom wrote one. Jester is the default web framework because it was first, and despite its age it's still pretty good. Same for choosenim. And asyncdispatch. And all of the other tools/libraries that he wrote.

Obviously writing some early software doesn't give him a free pass. I could understand the attitude if he was a jerk, but I've never seen him be anything but helpful.

I don't think Nim has anything that I'd call a "global namespace". By default importing a module will include its exported symbols into the local module, but that doesn't impact anything globally.

In my opinion, this is the correct default, at least for Nim. Operator overloading and UFCS (https://en.wikipedia.org/wiki/Uniform_Function_Call_Syntax) don't really work if I have to prefix everything with a module name, and the static nature of Nim means that I'll get a compiler error if there's any ambiguity. There are downsides as well, but language design is all about tradeoffs, and I think Nim got this one right.

Regarding the case insensitivity, I was initially put off by this as well, but in 2 years of using Nim as my primary language, I have never, ever, encountered a real-life issue with it. I've never seen a Nim code base that uses mixed casing, and never encountered or heard of a bug caused by this behaviour. However, it has allowed my own code bases to stay 100% consistent, regardless of the code style of my dependencies, even when those dependencies written in other languages. Contrast this with Python where the `logging` module uses different casing than everything else, so you're forced to use an inconsistent style if you want to consume it. This type of thing is a non-issue in Nim. I think a case sensitive Nim would still be a fine language, but in my experience the pros of being mostly insensitive outweigh the cons.

In the end you may still disagree with both of these decisions, which is fine. Just understand that it's a nuanced discussion, and there's some solid reasoning behind their choices.

I agree, but certain operations need to safely accept untrusted input if I'm going to handle input at all. Running a regex on user input doesn't mean I trust the input. It means I trust my regex engine. I should be able to trust my logger the same way.

With the '--debugger:native' flag, the Nim debugging experience isn't too bad. Not on the level of Java or C#, but you can set breakpoints, step in/over/out of code and inspect or watch variables without having to look at C code. There are some issues with type visualization (to see the contents of a string you have to evaluate something like '(char*)variable->data') but Nim ships with a gdb plugin that should help (I haven't actually tried it).

It could definitely be better, and hopefully some day it will be, but I use Nim in a debugger quite frequently and it usually works out pretty well.

This is cool. I'm working on something similar called enu (https://github.com/dsrw/enu), but you're further along than I am.

A few suggestions that may or may not be helpful:

- I realize that this is a big part of your esthetic, but blocky "game fonts" are hard to read. They're fine for games, but for editing code I want a normal monospace font rendered at a normal DPI.

- I feel like there should be a way to apply code changes without a full Publish. It's nice to test a change without resetting the entire world.

- Your docs are off to a good start, but it's really not clear to me how everything comes together. A more in depth example would be more helpful at this point than API docs, I think.

I'll definitely keep an eye on this. Nice work!

I have a 5 year old who's going to try it once the release is out, but he might still be a bit young to get much out of it. I'm really curious to see how it goes.

Thanks for the kind words!

Enu is 3D live coding environment with a Logo inspired API, implemented in Nim. It aspires to make 3D game development easier and more accessible, and to be a fun way to learn to code. MIT licensed.

See my demo at https://youtu.be/upg77dMBGDE. Version 0.1 will release with Mac and Windows binaries on Nov 6th.

XBox One and PS4 controllers have been supported on Mac and iOS since last year. The situation was pretty grim before then, but things are much better now.

It’s really for both. I’m paraphrasing, but during Araq’s intro talk during the conference he said something like “Nim should be suitable for every task, but maybe not every programmer”. Whatever you’re trying to do, there’s probably a pretty good way to do it in Nim. It can run on microcontrollers or supercomputers. It can compile to C, C++, JS or LLVM ir (via nlvm), and has a good interop story with all of them. You can use it’s advanced meta programming facilities to create specialized domain specific languages, or you can ignore that feature and write code that looks more or less like python. It has an advanced compiler with lots of optimization opportunities, but it also has an interpreter if performance is less important.

You can use it without GC, but the new arc collector is suitable for hard real-time, so I don’t think there are many cases where you’d need to drop to manual management.

The main downsides (in my mind) are the small community and somewhat limited debugging support. I really like the language however, and use it wherever I can.

Thanks! The repo is at https://github.com/dsrw/enu, but it's still a month or two away from what I'd consider "reveal worthy". There are no docs, and what's there barely works. However, I really wanted to be part of NimConf, so I cobbled things together as best as I could. I'm going to do a bigger PR push when it's a little farther along.

That link only refers to the MacBook Pro. The 2015 MacBook had a butterfly keyboard.

What makes you say that? I'm fairly certain the two projects are unrelated.

We're reinventing the wheel because the Java plugin didn't reach critical mass. There's never been a time that you could require Java in a web app and expect a trouble free experience for your users.

Perhaps the browser/OS vendors and Oracle could have worked together to make this happen, but they didn't, and the world moved on.