idea : reuse libraries from other languages

Nothing against reusing good code but after a couple of years "somebody talked about unfinished unproven software X on hacker news, maybe we can also use X" gets really tiresome.

idea : reuse libraries from other languages

Theres a package that wraps the Arduino StdLib, thats compiled C++ AFAIU.

idea : reuse libraries from other languages

But the problem is that the types will not match, eg a string in JS and TS will be actually an array of int in the generated JS of Nim etc.

How ready is Nim (and the ecosystem) for front-end web development?

Okay but who cares about 2G networks anyways? Most carriers don't even support that nowadays. Should we keep worrying about stuff not fitting on floppy drives?

Infiltrating Rust with Nim packages

I'd like to publish a Rust frontend to a Nim library that works as if native when use from `cargo build` and `cargo run`. This means at one point, the `build.rs` script should call the Nim compiler. I'm wondering if there is an example of that, or even better a package like `cc` which abstract

idea : reuse libraries from other languages

I mentioned it on discord a couple of times, but a non ideal idea for filling the ecosystem would be to write a typescript .d.ts file parser. With a bridge you could use them in the backend when targeting c/cpp (think of non-perf critical libs like redis, mongo, etc. although maybe bun is fast e

related_post_gen benchmark

Interesting hash function comparison: taken from this article:

related_post_gen benchmark

Is there a reason to not do that apparently simple transformation (other than too many other things to do of course!)?

idea : reuse libraries from other languages

Nim and go are a bit hard to combine due to both of them relying on incompatible GC:s and go having a built-in thread scheduler while nim threading support is missing at best, but here's how we do it at least:

related_post_gen benchmark

Why xxhash and not fvn1?

related_post_gen benchmark

Some of the xxhash implementations actually look pretty simple, no? The official repo does not, I agree. I don't know which version of the algorithm you used, but these implementations: * *

thriftcore - Apache Thrift primitives

I haven't been on a job yet (accept internal to FB years ago) that required Thrift. None ever that wanted Capnproto or msgpack or any others. Multiple ones that used GRPC. Even if I could have used Nim on those, lack of GRPC would have been a show stopper. And yes, I know it's possible to use C+

idea : reuse libraries from other languages

It's a bit different than Node or CPython, Go is a compiled language, and with a standard library that relies on the libc instead of their specific runtime, it could work like a standard C library. But it seems they are only targetting wasm for the moment, so perhaps that's not a so goo idea.

install nim failed

By default MacOS uses zsh shell, so you can open "~/.zshrc" in any text editor and add this line at the end: export PATH=/Users/zhenxingsun/.nimble/bin:$PATH Run That would make the terminal and apps launched via terminal see nim and tools installed with nimble. For G

install nim failed

These final lines hint that you should change your PATH environment variable. The way you should do this depends on your shell. I believe that the default shell by default on MacOS is zsh. You probably want to add the following line to your ~/.zshrc configuration file. export PATH=

How ready is Nim (and the ecosystem) for front-end web development?

> For a complex web app, that could be several megabytes, ... Pure speculation and seems to be an unrealistic extrapolation.

idea : reuse libraries from other languages

> a new stdlib for Golang Kinda like and

install nim failed

just new here, I confused about below choosenim-init: Downloading choosenim-0.8.4_macosx_amd64 Info: Version 2.0.0 already selected choosenim-init: ChooseNim installed in /Users/zhenxingsun/.nimble/bin choosenim-init: You must now ensure that the Nimble bin dir is in your PATH. choosenim-in

How ready is Nim (and the ecosystem) for front-end web development?

Several minutes is an exaggeration, but the truth is that, by my measurement, the _minified_ JS code produced by Nim is about 7 times the size of the _unminified_ Nim source code. I should do a proper benchmark at some point. For a complex web app, that could be several megabytes, which is much

How ready is Nim (and the ecosystem) for front-end web development?

Also, nothing stops you to actually run a js minifier in your "push to production" pipeline.

How ready is Nim (and the ecosystem) for front-end web development?

One option is to minify sure, another (or in addition) is to enable compression in your upstream proxy

idea : reuse libraries from other languages

Since this is a separate stdlib, doesn't that mean that existing Go packages won't work with it?

idea : reuse libraries from other languages

Recently, I saw this news: [a new stdlib for Golang](https://news.ycombinator.com/item?id=37744563) which removes the Go runtime, produce small binaries and should be mostly compatible with C. Go is known to have a really good HTTP implementation so that it is used in various production grade r

related_post_gen benchmark

Oh right, yeah that rules out xxhash unless we want to re-implement the entire thing in Nim. But fxhash only requires casting a position in a string to an unsigned integer, that's supported in the VM isn't it? Doesn't really have to be pointers either, this also works: result.hashW

related_post_gen benchmark

> By the way, considering how big the speedup of FxHash and XXHash appears to > be, would you be open for a PR which changes the default hashing algorithm? You can give it a try but it is harder than you think as everything must be available at compile-time the compiler and the runtime must agre

related_post_gen benchmark

By the way, considering how big the speedup of FxHash and XXHash appears to be, would you be open for a PR which changes the default hashing algorithm? Of course we'd have to run a test for collisions as well, but assuming they don't perform significantly worse in that regard I don't see why we

How ready is Nim (and the ecosystem) for front-end web development?

> Although slow recompile How long does it takes for you? Have you considered split in libraries/modules?

related_post_gen benchmark

> Huh, I thought the main proc speedup thing didn't apply any more. Depends on what is in the main proc. ORC made the code significantly better for toplevel code but we still don't do the trivial `proc main = body; main()` transformation.