enu VS nimskull

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!

In this video I put together a simple 3D survival game staring Inky, the blue ghost from Pac-Man, using the just released Enu 0.1.99.

Less of a global sales pitch for Nim (I'm a shoo-in from Pascal), but I found this today and thought it was neat:

"Enu lets you build and explore worlds using a familiar block-building interface and a Logo inspired API."

https://www.youtube.com/watch?v=ECJsq7BeZ8w

https://github.com/dsrw/enu

I work on Enu and am invested pretty heavily into Godot + Nim. I’m hoping someone else beats me to it, but I’m going to create a Godot 4 binding if no one else does. I’ll probably start 6 or so months after 4.0 releases. Assuming I don’t get hit by a bus or something, there will be a migration path eventually.

Nothing here is untrue, but from my perspective it's overstated. I don't use discord, but I visit the forum daily, follow most of the RFCs, and spend a lot of time coding in Nim (https://github.com/dsrw/enu). I really like Nim, mostly like its community, and think many more people should be using it.

I'm sure fusion could have been handled better, and for 2021 the roadmap was a bit hazy, but I can't think of any other big missteps. Araq, dom, PMunch, and other senior folks are in the forms helping people and answering questions every day, and my interactions with all of them has been very positive. The big post 1.0 feature was arc/orc, and that was very well communicated. Bugs are being fixed, useful new features are being added, and future plans are being discussed in the open.

And Nim itself is great. The "if it compiles, it works" factor is high, yet I almost never feel like the compiler is fighting me. Simple things are simple (I'm teaching it to a group of 12 year olds), it's incredibly flexible, it's fast, and it's suitable for almost any sort of problem. There's nothing else like it, and I expect I'd continue using it for at least a decade even if it switched into maintenance mode tomorrow. I think it will take at least that long for something better to come along.

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

A few suggestions that may or may not be helpful:

- 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 also thought godot + nim would be great together. So mid year, I just got started. I hacked together this https://github.com/geekrelief/gdnim which allows for gdnative library hot reloading, the first of its kind for gdnative. I was inspired by https://github.com/dsrw/enu which uses nimscript.

> Unfortunately there seems to be a big "civil war" happening right now in Nim land

I believe the war is already over, the other side forked the language and seems to move in their own direction to create something new - https://github.com/nim-works/nimskull . That's probably for the better.

I've been around Nim communtiy around a year and I haven't seen any major conflicts break out since these people left. Nim is still actively developed and a jou to use.

FYI, some members of the Nim community are working on a fork, for apparently similar reasons as OpenD (community-led development). https://github.com/nim-works/nimskull under active development and not ready for general consumption though, from my understanding.

There's a looming feeling that C++17 is really going to be the last version of C++ (practically, in production). The Vasa is now half-sunk [0][1], but the alternatives are yet to be truly born. The current issues surrounding the language standards:

- The important but half-baked features of C++20 that has never really been polished enough for actual production usage (modules, coroutines)

- Unnecessary "hyper-modern" C++ features which are dead on arrival (ranges)

- The dramatic increase in build times due to the STL library (which are accelerated by those hyper-modern C++ features) [2]

- The fleeing of LLVM/Clang engineers to other projects (as you've said, Apple engineers shifting work to Swift, and Google abandoning Clang and moving to Carbon).

- Implosions in the ISO committee (notably the controversy surrounding the rape convict)

It's really not looking good, but there aren't that much alternatives so I think people will just stick to C++17 for the moment. Listing the worthwhile competitors:

- Rust is a bit too awkward to use in many cases where C++ is used (particularly with unsafe Rust), and inherits some of the hyper-modern complexities/insanities of C++.

- Zig is still too unstable, they just finished reworking the compiler

- Jai is not even released to the public

- D might be a candidate but IMO they should really commit 100% fully for GC-less betterC mode...

- Nim still has many warts and unbaked features, and also the dev community was split into half recently [3]

[0] https://www.aristeia.com/TalkNotes/C++vstheVasa2-ups.pdf

[1] https://www.stroustrup.com/P0977-remember-the-vasa.pdf

[2] https://old.reddit.com/r/cpp/comments/o94gvz/what_happened_w...

[3] https://github.com/nim-works/nimskull

I started programming in Nim around 2015 and still write code in it from time to time. At this point I would have a tough time suggesting the language to anyone for much. While you can certainly accomplish almost any programming task with Nim, how much frustration you will encounter fighting the compiler and broken / under-specified language features and semantics might be a turn-off. There are other major warts with Nim, which I'll outline briefly below.

1) Nim's leadership is awful and has always been historically. Those in charge of managing the community are more interested in their personal reputation's and resumes than they are actually contributing working software to the language's ecosystem. Even the BDFL treats Nim like their own personal compiler R&D playground. There are so many broken features in Nim which never see the light of day or never get removed.

2) Continuing to expand on the point above, the Nim compiler has become insanely difficult to work on. As more and more half-baked features have been added to the language, the situation has only worsened. There are many would-be contributors who have come into the community only to leave completely frustrated or appalled by the lack of interest in improving the situation from those leading the community.

3) The development path is driven by leadership and not the community, and leadership has no plan. This was extremely evident last year when Araq and others were asked for a roadmap for Nim and they admitted to not having one, and basically wrote one up in a forum thread. Araq and dom96 and a few others, especially those who have been brave enough to actually deploy Nim code in production (looking at you status.im) tend to dictate what gets worked on or fixed. There is no coordination amongst folks working on initiatives. You can look at the `fusion` project, which was started by Nim's leadership, drew contributors in, and then was abandoned by leadership while maintainers were left on the hook to keep things afloat until they too dumped the project.

Things have gotten so bad, that a hard fork has been in development since last year, and many of the more senior community members or those who have been around for a bit have migrated there: https://github.com/nim-works/nimskull

Nim's community now consists of mostly new members or folks who weren't really active in it before, but maybe used Nim. Of course, the leadership remains in place, but there are only a handful of folks remaining that have been around for more than a year or two. Mostly those who bit the bullet on using Nim in production or built large projects with Nim and are stuck maintaining them.

My advice would be to look elsewhere.

A lot of previous contributors to Nim are currently working on an experimental fork due to disagreements with the development of the official compiler: https://github.com/nim-works/nimskull