Nim boilerplate

Yes, everything you don't understand is "complicated" and makes you feel uncomfortable.

Nim boilerplate

> in a language with macros as a focus That's the problem in itself. Do I want a language with "macros as a focus" \- absolutely not, why would I want extra complexity in my project if I can avoid it? Macros are nice to have, but it should be avoided, unless you absolutely need it. Like in 0.1%

related_post_gen benchmark

`--added--` without `match=native` looks like `clang` visible better. JFI: `-d:danger` is much faster than rust

Nim boilerplate

Odin also implements Unions but it does not implement auto dispatching based off runtime time, as such you need to do the same thing as Nim

related_post_gen benchmark

My last solution were merged into main repo * I put `tables.nim` from the develop channel near. I think it is ok just to not wait * `findTop5` was remade with swap + somehow it helped a bit to create seq in it

Nim boilerplate

Preventing boilerplate in a language with macros as a focus is not good enough to justify direct union/sum types over object variants. And if you want type safety, you will still experience a similar amount of friction with either design. I also know only 1 language that implements them, [Crys

Nim for mobile

"Introducing Nim for mobile is a game-changer! This powerful language, known for its efficiency and speed, is poised to revolutionize the mobile app development landscape. With the expertise of an https://www.appingine.com/enterprise-app-development";>Enterprise](https://www.appingine.com/enterpr

Why is building the community and ecosystem such a struggle?

I'm a new Nim user. I first started playing with it less than three months ago. I created a forum account just now. Perhaps we need to step back and ask ourselves a philosophical questions. What is the purpose of a programming language community? Once answered a strategy can be formulated and t

set global for all libraries

> What is your usecase for this, though? I'm writing a little additive synth. In some libraries there are some stray functions that need a sample rate set. There are a few objects that need a samplerate set but that don't inherit from or build upon each other. When creating textures/patterns fo

Nim boilerplate

> If you feel the need for it, feel free to use some interface macro. And not > again this "it needs to be in the stdlib!". Point (2) applies for "must be in > stdlib" too. Well, I'm the one who suggested than an interface macro should be in the stdlib and I feel somehow bad for it. In fact wh

set global for all libraries

What is your usecase for this, though? Why would an object not suffice? It's what I'd prefer personally, but if your usecase requires a global, that's understandable Though if it's a mutable global value, you may have issues if you ever use threading and such

set global for all libraries

> "used by all included libraries" Hah, three decades of POV-Ray shows, libraries are `include files`. I wasn't aware of Nim's `include`, can be useful but I'll try with `const samplerate {.intdefine.} = 0` first and add the `-d:samplerate=100` to the `nim.cfg` Thanks.

set global for all libraries

Is it possible to set a "global" variable form the main "program" that is then also used by all included libraries. An example would be the samplerate for audio that is used all over the place.

set global for all libraries

You could use a define: Have this in all your files: const samplerate {.intdefine.} = 0 Run Then set them all with `-d:samplerate=100` for example. You say "used by all included libraries", I assume you meant imported, but in case you actually meant included you just

Compiling on i386: Pointer size mismatch between Nim and C/C++ backend

> The issue is in the build.sh script, it uses 'uname -m' to detect the arch, > but within Docker container this command returns cpu architecture of the host > machine (x86_64), and not the cpu of Docker's target platform. Yes. But all other architectures work (except s390x for other reasons I

Nim boilerplate

_Variant have problems, for example, many functions need just the single variant, but you had to pass the all variants, and end up with lots of unneded check like ``variant.kind == 'a'`` etc. And some other type safety and other problems_. I do believe that my example: _the one that sparked thi

Nim boilerplate

As I said earlier in the thread, it would be nice if something like this was built into the language / standard library. I understand (and agree with) the idea of not adding too many things to the standard library, but this seems like a language "building block" which, once designed, would not n

Nim boilerplate

> You doing manual boxing/unboxing. here's the diff with union types, judge > yourself which one is better. The one that doesn't imply a language change for the loud minority consisting of 1 being that will use TypeScript anyway in 3 ... 2 ... 1. ;-)

Nim boilerplate

I no longer get the point of this forum post and should no longer participate, but...Thank's to leorize's there is a usable union solution. import union type CodeCmd = distinct string ReplaceCmd = object elementId, content: