NimForUE VS RFCs

Glad to see that the windows executables are working again.

I had tried a little while ago to test things out on my windows machine after seeing the NimForUE project (https://github.com/jmgomez/NimForUE) and was sad to see that my computer would auto-mark any nim binaries as malware and delete them. I wasn't too invested so I just shrugged rather than looking for too many workarounds.

For people scared off by C++ and who want faster recompile times, check out the Nim bindings [0]. Check out his Twitter/X account [1] for plenty of cool things it brings to the table.

[0]: https://github.com/jmgomez/NimForUE

[1]: https://twitter.com/_jmgomez_

I started using Nim because i wanted to port some of machine learning models written in python with the idea of making them more portable. It was a lot of work as community is relatively small and a new user would end up writing a lot of code.

But Nim has a pretty solid standard library with clearly written code and an awesome community to help with problems. I generally read a lot of standard library code to expand my knowledge of language and discover common patterns which repeat themselves in a lot of real world problems.

C inter-op is really first class, and as far as i know it has one of best C++ inter-op as well, you can take a look at: https://github.com/jmgomez/NimForUE for a real world example.

I use Nim for my work in both professional and personal capacity and also have written about some of it at https://ramanlabs.in/static/blog/index.html

I've switched over to Unreal and helped out with NimForUE early on. If you have any interest in Unreal, you should check it out since it's in a really good state. It does assume knowledge of Nim, Unreal, and C++ to really get the most out of it.

In NimForUE, we ran into issues with nimble early on, so we resorted to using nim for the build scripts because we needed to do code generation gymnastics to work with Unreal's build system and Nim's C++ codegen. The Nim compiler has had some patches since we first worked on the build system, so maybe if we had to do things over again we could go back to NimScript.

They would be better off just paying the guy developing NimForUE some money and making it first-party.

NimForUE is an Unreal Engine plugin that aims to replace the verbose and tedious C++ with the concise and clean Nim language, supporting blueprints too and giving hot reloading and native speed performance. https://github.com/jmgomez/NimForUE

(https://github.com/jmgomez/NimForUE)

compiler support for object construction shorthand

Well, maybe not writing. Occasionally low-level C libraries - especially those that deal with keyboard input - decide to provide identifiers differing only in case... There's a WIP RFC for providing a way to deal with identifiers that need to be verbatium by surrounding them with backticks, though.

https://github.com/nim-lang/RFCs/issues/477

Following The Roadmap 2023 for community building , you could join us in the matrix space where we discuss how to build a community. We appreciate doable suggestions and helps, such as improving the workflow, implementing the roadmap, suggesting doable tasks, reviewing code from contributors. United we stand. We shall work together to make the community thrive.

First of all, the Nim development follows The Roadmap 2023, which specifies what features might be implemented or removed in 2023. As we can see, completing incremental compilation and recursive module dependencies might be the most important tasks to be done in 2023. You might subscribe to the roadmap and write down your expectations of Nim in 2023 there.