It's extremely fresh but our tests are working so consider giving it a try.
For those interested in Nim's meta-programming, we're generating those Python bindings for Pixie from our Nim code using https://github.com/treeform/genny here https://github.com/treeform/pixie/blob/master/bindings/bindi...
More languages in the works.
This project is likely to get drowned out by pixi search results when its users try to Google anything related to it.
In this instance the Nim and JS libraries have different names (and even different spellings of the common subset) so I don't see an issue.
That's an awful lot of sass from someone who didn't bother to read my post:
1. You're not using the language name in your search query like I suggested one should. So your example is moot.
2. You're still being highly critical about something that is awfully hard to get right. Naming projects is one of the hardest things you can do to a project. Firefox went through 2 naming collisions before they landed on Firefox. As an open source contributor myself I frequently get people say "Your name is used by this thing over here too" despite me spending literally hours going through multiple different name options and Googling them to see if they have a presence (search engines aren't always good for checking this stuff by the way).
When there are hundreds of thousands of people creating software each month, you quickly run out of phonetics to use. While naming might seem like an infinitely large namespace, in practice there's only a finite number of names out there yet a literal infinity of projects due to new ones popping up all the time. So collisions aren't just inevitable, they're going to become more frequent too.
This is why open source frameworks for different languages where the spellings differ is fine in my opinion because you should always include the language you're targeting in your search query for more accurate results anyway.
Sometimes I think people just like to throw namespace collisions as a criticism on HN because they're too lazy to research the framework properly but still want to appear knowledgeable to everyone else. It's literally the lowest effort critique one can make on a project.
Do you really want to pretend with all your might that naming your graphics library after the same creature as another graphics library is a good idea? Really?
Coincidentally I just named a rendering library for WebGL a few days ago and it's already the first result on google.
Naming projects isn't that hard if you don't want a 3-6 letter name. There's only so many possible combinations of five characters. You'd think software developers of all people would understand that and maybe stop giving their projects short names that look like acronyms and convey literally no meaning.
The easiest way is to pick a longer descriptive name with a good acronym. If your project becomes popular, it'll become known by that acronym. Most 2 word combinations aren't taken either.
People make associations all the time with often unrelated things. That's exactly how our brains are wired to operate. The fact is the names in question are still different.
> Coincidentally I just named a rendering library for WebGL a few days ago and it's already the first result on google.
Google tailors results. And I bet if you shared the name of your library I'd find some similar project that I have an association with when I hear your name.
> Naming projects isn't that hard
Naming things is incredibly hard!
> There's only so many possible combinations of five characters. You'd think software developers of all people would understand that and maybe stop giving their projects short names that look like acronyms and convey literally no meaning.
Love the contradiction of how you start out by saying naming things isn't hard and then go on to explain why naming things is hard. It's also worth noting that adding more characters creates might create more entropy but there's still only so many phonetic phrases available before you drift into the realm of stupidly long names.
> The easiest way is to pick a longer descriptive name with a good acronym. If your project becomes popular, it'll become known by that acronym. Most 2 word combinations aren't taken either.
Please no. Acronyms are almost as bad for names as stupid pseudo-words (like SPDY and NGINX). A name doesn't have to be English, but it should at least be a word. Otherwise you're making things artificially hard for anyone who isn't a native English speaker or who has reading difficulties (like dyslexia).
Like I keep saying, naming things is incredibly hard.
They're both named "Pixie" and they're both graphics libraries. I assume you meant something else than what you literally said, but I'm not sure what
It seems absurd to me that developers are too lazy to add one extra keyword to their search to ensure they get specific results, yet are happy to moan about maintainers not putting enough effort in to avoid namespace collisions in a finite pool of usable project names (and particularly when the project names here are literally different). This strikes me as bad workmen blaming their tools; you have a bad search etiquette and are then passing the buck onto the maintainers to fix.
Sorry if that seams harsh but naming things is really hard but adding `nim` into your search query is really easy. To me it is pretty clear cut where this problem should be solved.
I've been trying to learn it / grok its documentation for awhile. Any suggestions on how to learn it better? I've given Exercism.IO a try (disclaimer: satisfied learner from there but not trying to shill) but I've had difficulty adopting the language from a Python background.
If you haven't read through the Nim-for-Pythoners  it'd be good. I read the "nim manual"  constantly and just use ctrl-f. Though Nim Basics by narimiran is a nice tutorial form .
There's a few standard links:
I did not see any allocs/de-allocs, which suggests some kind of garbage collector is being used? I guess a lot of that is straightforward with stack allocated data structures going out of scope. But that would put this language in the same realm as Go and not Rust/C/C++, which don't rely on garbage collectors.
I'm mainly doing Kotlin currently, which also has a multi platform compiler (with native, js, and jvm compilers). Though particularly the native compiler is a bit a work in progress. But, Nim could be considered similar to that as well. Though obviously the languages are very different, what is similar though is a focus on programmer convenience. It's something I really appreciate in Kotlin and it seems this language has a lot of that too.
It will be interesting to see how this language grows and evolves. Looking at Rust and Go in recent years, there are a bunch of gnarly topics that inevitably come up like how to deal with asynchronous stuff and co-routines, generics, error handling, etc. Kotlin also had its fair share of that. That's when languages get more complicated. I think Rust is a good example of a language that has a pretty high level of complexity at this point.
Just a first impression. But mostly a good one.
Nim use a new GC they call ARC, which is just a clever combination of non-atomic/locking reference counting and move semantics. That combination enables the GC to be realtime capable and deterministic. It's also doesn't have GC pauses or issues with enormous heaps, but it requires more work when multi-threading. In theory Nim sounds be more similar to Go than Rust/C/C++, but with ARC you can use Nim where you'd use C/C++ (or turn off GC entirely). I'm using it on embedded RTOS'es and routinely getting exactly the same memory allocations with only a single integer add/sub overhead. Actually, many larger Rust programs end up using `Rc<mystruct>` a lot, which should result in an almost one-to-one correspondence on generated code to what Nim+ARC produces.
> I'm mainly doing Kotlin currently, which also has a multi platform compiler (with native, js, and jvm compilers). Though particularly the native compiler is a bit a work in progress. But, Nim could be considered similar to that as well.
Probably not a bad comparison. Kotlin sounds like a pragmatic language with just enough "functional concepts" to make it more productive but not type/theory heavy.
> It will be interesting to see how this language grows and evolves. Looking at Rust and Go in recent years, there are a bunch of gnarly topics that inevitably come up like how to deal with asynchronous stuff and co-routines, generics, error handling, etc.
Ouch, those are tough topics. I avoid Nim's async because it requires cycle detection (ARC w/ cycle detection) on embedded. Rust has difficulty with closures and async for similar reasons IIRC. Luckily Nim's error handling/async/co-routines are all pretty standard otherwise. There's some work to be done in Nim for improving modules and removing nill'able types from the standard library. But nothing that should cause the gnarly topics Rust/Go have been facing (:fingers-crossed:).
I'd say the opposite. Just look at how it compares to C++. Even Swift is a rather complex language when compared to Rust.
"nim in action" by dom96
nim days by xmonader
Some years ago when I was going through languages frequently, I was pretty interested in it for a bit, but found it kind of hard to get into and my interest ultimately wandered.
I thought a large part of that was due to my unusually strong dislike of the syntax, and that that was why I found it unusually difficult to grok. Maybe it wasn't. Interesting.
(BGRAControls contains the BGRABitmap components).
It's sad Lazarus/FreePascal doesn't get much play, because high quality libraries like this have existed for years for it and it seems to not get much traction.
Just like Skia, all pixel accesses is SIMD accelerated.
It doesn't have C bindings, but they can be trivially implemented.
For example, I have a few "megatests" where I render entire icon sets or emoji sets such as
Running these tests helps me feel more confident that changes I'm making are not breaking things.
From a quick glance, pixie should pass 10-20% of those tests.
Yes, SVG is that complex.
Without knowing how much overhead Nim brings in, I still believe it would have been better if this library preliminary was a C or C++ lib and then had binding for all the other languages.
> Sadly, I am not enough of a Nim expert to know the trade-offs between using native code or importing C libraries.
So I don't think it's far-fetched to emit C with hand optimizations if you really need them.
That's the weird thing about Nim. It's not really a new language so much as a syntax and front end to several existing languages.
If you compile in "-d:danger" mode turning off all checks and highest optimizations, the C code it spits out is pretty human readable even.
> That's the weird thing about Nim. It's not really a new language so much as a syntax and front end to several existing languages.
I haven't really compared any other features though. Scaling images does appear to be quicker though (when compiled with -d:release -d:danger --opt:speed)
* Nim very fast. I can beat any C/C++ program in performance using same tricks as they do. Cleaver Memory management, inlining, static analysis, SIMD. There is no wall that you run where you need to drop into "C".
* Nim is very easy to write, I came from Python/CoffeeScript and it was a very easy transition. Nim feels like Python with Types.
* Nim is very powerful with generics/templates/macros allowing you to write DSLs quickly.
* Nim has very easy interop with C. So its very easy to use existing C libraries or low level operating system APIs.
* Nim has a smaller community that has not been overrun by complexity or apathy. Everything feels green and fresh and everyone helps everyone else. But still big enough that there are libraries for most things.
I think it's kinda cool and relevant, and a quick search didn't reveal any other library with the same name. If you're up for rebranding, feel free to use it :)
It's a decent starting point for trying to build your own toolkit.
I have recently added a wgpu backend but for now it lives in my fork https://github.com/adamnemecek/femtovg
run the demo with `cargo run --example wgpu_demo --release`.
Also join the femtovg discord https://discord.gg/V69VdVu