Live data from Hacker News

Ask HN: Why did Nim not catch on like Rust did?

news.ycombinator.com

101–110 of 139 posts

Re: Ask HN: Why did Nim not catch on like Rust did?

#101
post #97
post #89

Earlier quoted context omitted.

The problem with WebAssembly isn't that Nim couldn't compile to it (which it can), but that WebAssembly can't do anything without JavaScript.

We're not talking about hypotheticals. Rust wasm is used in production now. https://developers.cloudflare.com/workers/tutorials/hello-wo... Emscripten and experimental backends hardly count as support for Nim. Python can run in webassembly by the same token, but no one would . The standard rust compiler compiles directly to webassembly, natively, with the stable toolchain. In other languages, yes, the js bridge is a…

Doesn't Rust with WebAssembly require any JavaScript to run?

If not, can you show me a webpage that uses WebAssembly and doesn't contain any JavaScript?

If yes, what is the advantage over just compiling to JavaScript?

> However, not only will this be fixed in browsers at some point,

This has been promised for several years, and is still nowhere to be seen.

> yew.rs, a mature wasm framework, is faster than react.

Being faster than React is not a high bar.

Re: Ask HN: Why did Nim not catch on like Rust did?

#102
post #53

Earlier quoted context omitted.

Nim does guarantee memory safety if you don't use unsafe features like raw pointers.

Does Nim make you explicitly enter an unsafe mode to access raw pointers?

No, what's the point of that? It's not hard to recognize unsafe code.

Re: Ask HN: Why did Nim not catch on like Rust did?

#103
post #3

Rust had Mozilla's backing, and later other behemoths like Amazon and Microsoft jumped onto the bandwagon. Corporate support is absolutely essential for a new language to be taken seriously in the industry. If Go weren't associated with Google, people would have laughed that language out of the room long ago. Likewise, it's difficult to imagine TypeScript ever catching on if it didn't have Microsoft's might behind it…

Considering that the Zig Software Foundation not only doesn't have any big corporate backing, but also made an explicit point of always being fully independent, and the fact that we're overall doing fine, I beg to disagree. https://ziglang.org/zsf/ Big tech wants you to think that you're nothing without them, while in truth there are plenty of situations where small realities can absolutely out-compete them: https://…

To be fair, Nim isn't dead either. It's steadily coming along, with new developers, features, and libraries all the time. Sure it hasn't had the meteoric growth of Rust, but it's still climbing.

Re: Ask HN: Why did Nim not catch on like Rust did?

#105

Earlier quoted context omitted.

Does Nim make you explicitly enter an unsafe mode to access raw pointers?

What that even means? Just random words. unsafe block is just an illusion and doesn't prevent any bugs. Don't get me started on the cult that shames repos that use it.

Sure, but upon review it was found some of the code was using unsafe without reason, and people submitted pull requests which made the code better. It's better because you are sure it doesn't have a memory unsafety bug, even if the code "looked" right before.

Re: Ask HN: Why did Nim not catch on like Rust did?

#106
post #76
post #32

When Rust was able to get rid of a class of memory bugs, undefined behavior, concurrency bugs without a garbage collector, it achieved a breakthrough. You can now write JS or Java VM in a language that doesn't have buffer overflows, dangling pointers and all kinds of other nasty security vulnerabilities. Nim doesn't GUARANTEE memory safety, so it's basically... better Pascal? It's an iterative improvement that nobody…

Rust doesn't guarantee memory safety. I think anything that can generate a trivial hello world program that doesn't leak memory is better than V.

If you don't use `unsafe` then it guarantees it barring compiler mistakes. The compiler has had issues with memory safety before, they were found, and they were fixed. There might be some left lurking, but they are extremely unlikely since people are using it in production and haven't seen anything weird.

If you use `unsafe` you have to make sure of it yourself, but you can easily grep for this keyword and see where the monsters lurk.

Re: Ask HN: Why did Nim not catch on like Rust did?

#107
post #3

Rust had Mozilla's backing, and later other behemoths like Amazon and Microsoft jumped onto the bandwagon. Corporate support is absolutely essential for a new language to be taken seriously in the industry. If Go weren't associated with Google, people would have laughed that language out of the room long ago. Likewise, it's difficult to imagine TypeScript ever catching on if it didn't have Microsoft's might behind it…

Considering that the Zig Software Foundation not only doesn't have any big corporate backing, but also made an explicit point of always being fully independent, and the fact that we're overall doing fine, I beg to disagree. https://ziglang.org/zsf/ Big tech wants you to think that you're nothing without them, while in truth there are plenty of situations where small realities can absolutely out-compete them: https://…

Dart is a no go especially because Google is not really backing it.

Re: Ask HN: Why did Nim not catch on like Rust did?

#109
post #104
post #102

Earlier quoted context omitted.

No, what's the point of that? It's not hard to recognize unsafe code.

You can't grep for it, but you can grep `unsafe`

`ptr`, `addr` and `cast` are the only ways to introduce unsafety, as I understand it. You have to run three greps, but you can definitely grep.

Re: Ask HN: Why did Nim not catch on like Rust did?

#110
I've only played with Nim a little, but I found it really compelling and honestly quite fun to write. It's quite elegant and economical and the performance is impressive for the lack of ceremony.

However, the language itself still seems to be a little in flux (v2.0 is nearly out, and my impression is that v3.0 might finally be a nice stable language) and the BDFL makes some language decisions (and holds some opinions) that I'm not fully on board with, and I think make the language a little less than it could be. Obviously that's subjective though.

I'll definitely keep an eye on it and check back in periodically, but I'm also not going to write any non-disposable code in it for now.

Post reply on HN