rust VS Nim

There are three. The official one, mrustc (no borrow checker, but can essentially compile the official rustc) and GCC (can't really compile anything substantial yet). Only rustc is production-ready though.

By following this issue to this issue comment, I think the reason is the sheer complexity of tuple struct constructor: * The syntax of tuple struct constructor is the same as either a function call or a constant, so to make life easier, the rust devs made it a function or a constant, i.e. declaring a tuple struct with pub fields also fills the value namespace with a function or constant. * Named field struct constructor is cannot be mistaken for a function call, so rust devs are free to let user construct them with type aliases.

Relevant rustc issue

Not that hard if you're writing Rust: https://github.com/rust-lang/rust/pull/29837 and the like.

Love the article.

In my mind I see the problem of dynamic linking in rust to have a bunch of overlap with the "I want this rust library to be exposed in my higher level GC'd language with minimal safety/handwritten bindings" problem.

My hunch is that the lack of expressiveness of the C ABI is holding back both. the thing I'd love to see some sort of "higher level than the C ABI" come out. And something like `wasm-bindgen`[0] to exist for more languages.

Here's a link to the rust "interopable_api" proposal! I don't understand all the implications, but it seems to be in the right direction https://github.com/rust-lang/rust/pull/105586

[0]https://rustwasm.github.io/docs/wasm-bindgen/

GitHub issue tracking implementation of RFC 2005: https://github.com/rust-lang/rust/issues/42640

The "Why Rust" section just under that slogan makes it clear enough what sort of language it is and whether it might suit your needs. It can't be done in a headline ... https://www.rust-lang.org/

Glad you like it 🙂 https://github.com/rust-lang/rust/pull/58530

We ship Microsoft-signed Win32 binaries via PyPI, and I regularly have to go and deal with new releases being reported as malware.

Granted, this is a debugger, which among other things contains code to inject threads into running processes - which, of course, trips any decent heuristic scanner. But there are many broadly legitimate patterns that are also useful to malware and so get falsely reported as such, e.g. https://github.com/nim-lang/Nim/pull/19767

Scala 3 and Nim took inspiration from the Python indentation based syntax. I find it a bit more readable than Rust/C/Java syntax, but there are also downsides.

Interesting. I saw shades of this when I tried porting a tool over to Nim, found it was much slower than trivial code in Python and Groovy, then stumbled into this discussion:

https://github.com/nim-lang/Nim/issues/9026

Nothing as strong as the above but it definitely rubbed me the wrong way. So much advertising about Nim being efficient/fast and the default way to read a file is incredibly slow and inefficient .... and they don't care.

Now clone the Nim project: git clone https://github.com/nim-lang/Nim.git

Nim and Codon are Python-inspired compiled languages which I find interesting.

https://github.com/nim-lang/Nim/commit/2843f272bd20be838031fc732f76fd1a3fcba98c seems to not be on any branch, so https://github.com/nim-lang/Nim/blob/devel/lib/pure/oids.nim#L25 still has int64.

nim

/u/bmwiedemann, I recommend you reopen https://github.com/nim-lang/Nim/issues/20285 because the last attempted fix seems to have been reverted.

Are you sure google can’t find this? https://nim-lang.org/