NimForUE VS vos

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)

The creator of V made some big claims that raised a few eyeballs, they've gained a reasonable following over the years, have a pretty serious looking website (https://vlang.io) a beer-money level Patreon following and some corporate partnerships/sponsors. However have experienced some pretty brutal takedowns over the years, with some of the bolder claims about the language/compiler being exposed as being.

A word I keep seeing in relation to V is "aspirational" - the project aspires to be a serious language with some major features, so I think it's fair to approach it with a more critical eye than one would a kid's side-project. I think HN would have been pretty understanding if they were open about the state of the various features and were a little less defensive when they encounter articles that treat it like a Real Language and review it as such. If the authors don't want this kind of feedback they can just say front-and-centre (or on their FAQ @ https://github.com/vlang/v/wiki/FAQ) "this is a toy" or "this is pre-alpha"

Autofree has existed for years and can work. Here is a demo. It is used in V's Vinix OS, Ved, and other applications. Part of the issue is there are detractors who purposefully spread misinformation nor know about its other memory options, and the other part is understanding how to use it.

Another option is to write the kernel in V. Vinix is an OS written in V. You can use it for reference when building your project.

And that's why vinix [1] is full of manual free call? That tells how good autofree is, isn't it? Can you compile v compiler with autofree? Last time I checked, you can't.

[1] https://github.com/vlang/vinix/search?q=free&type=code

vweb, volt, and ved are not a "little more than alpha"

yes, the os is being developed in V, and it can already run bash, GCC, G++, and Doom.

https://github.com/vlang/vinix

It's a great concept, but languages like Rust (https://www.rust-lang.org/), Zig (https://ziglang.org), Vlang (https://vlang.io/), etc... are already running with a similar idea to being easy to interact with C and are viable alternatives to it as well. Vlang even created its own OS, Vinix (https://github.com/vlang/vinix), to show its capabilities in this regard.

Seems to me, Cello would be more for those C programmers that didn't want to try the various alternative languages that are now out, and happen to agree with its developer's interpretation of what high level constructs would look like. The point of these alternative languages is to offer features that C doesn't have or to implement them in easier or clearer ways.

Vinix shows the capabilities of V on bare metal, in additional to it being useful for high-level programming as well. https://github.com/vlang/vinix