treeform

I started using python around 2005 and Nim does have that feel of early python. Nothing was set in stone and the fields were open. Lots of optimism.

Nothing is without the cons. I would say:

* Libraries: there is no NPM ecosystem to get anything you need.

* Stack-overflow: If you looking for a aswers there might not be anyone who encounters it before. You might have to dig really deep to find some thing.

* Some times you might run into a compiler bug usually related with performance of the generated code. Like it generates correct code bug it's slow for no reason and minor changes to the code make it fast again.

* Relying on OpenSSL especially v3 especially on windows is a big problem, but thats more on openSSL i think. I actually wrote a library around this that uses platforms HTTP/SSL instead: https://github.com/treeform/puppy

* Not having HTTP gzip support in standard library. You can always work around with zippy though: https://github.com/guzba/zippy

* async stack traces are really hard to read.

* not enough docs around the different ways to do threading. There is no one solution some times you want a quick thing, some times you are doing CPU tasks other times you are doing network tasks (where async is better). But many big languages struggle here, there is no one fits all threading solution.

It's definitely not style case insensitivity which everyone loves to bike-shed about.

I use Nim in production, its great. Easy to write like Python, but super fast like C. Type system prevents typos. Has very advanced macros.

I've been doing Nim professionally for about 3 years now. But I only shipped a small project in Go.

I feel like Go specifically “dumbs down” the language so that it can be used in large teams with varying programmer skills and high turnover. Perfect for large companies. Go routine stuff is really cool. But If you're not writing a super concurrent http server in a large team, Nim is just better at compiling to JS, Game Dev, Mobile and Embedded applications. It allows you to do cool meta programming and express things with templates and macros. You can go really low level with SIMD and manual memory or really high level with database, html, ui, and api DSLs.

Go feels like it was made to do one thing, while Nim is more of a swiss army knife of things.

You can do a lot with Nim at compile time, check out my talk on Nim Metaprogramming not just for FizzBuzz, but real world applications: https://fosdem.org/2022/schedule/event/nim_metaprogramming/

I am working an a macro to compile Nim code into GLSL. So not only can you write Nim to C or Nim to JS, it can also (in limited way) do Nim to GLSL GPU Shaders. See here: https://github.com/treeform/shady

I am also working on a macro system similar to SWIG, where using a some macros one can write a Nim library and generate wrappers for your NIM library for many languages like C, Python, JS, Ruby. See here: https://github.com/treeform/genny

I don't think so. I have binding to the google cloud API https://github.com/treeform/googleapi (for work) and the digital ocean API https://github.com/treeform/digitalocean (for personal) almost no one uses or cares about it besides me. If there was some pent up demand I would have more issues and PRs.

It might have some thing to do with lower popularity of the QtCreator editor. VS Code is just very popular even for non-Nim.

I don't think there is anything for Nim people todo. Anti virus companies run a very simple algorithm, they flag everything they have not seen before...

At this point anti virus companies are the virus, slowing down peoples computers, mining bitcoin, false advertising, hard to cancel payments etc...

Mostly Data Science and Engineering and Visualizations.

See this as one of the examples: https://github.com/treeform/shady

It makes debugging shaders much easier as you can use print statements and unit tests. You can also share code between CPU and GPU side.

I love Nim. I been using it professionally for more than 3 years now. At first I started with it just as a faster python with types, but it so much more! You can run Nim everywhere regular places such as backend, frontend, mobile, but also in crazier places like GPU shaders and imbedded.

I also like the community. It's not so big that it feels like you only see people once but not so small that there are no useful libraries written. Just the right size for me. You can always get people to help you out on stuff, reminds me of old IRC days.

I chose to write Pixie in Nim because I really like Nim:

* 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 works everywhere: From Desktop Windows/Mac/Linux, to mobile iOS/Android to embeaded devices. It even compiles to JavaScript (like CoffeeScript/Typescript or WASM) or GL shader language. It run anywhere.

* 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.

Can you give us more details on what did not work for you? We would love to fix it.

Thank you for watching our pixie presentation!

That's unfortunate. I did not know about pixi.js when we picked the name. It feels like all of the cool names are taken! When we were thinking of a name we just looked around the Nim community for name collisions.

We did not really "need" a GIF decoder but it was a fun thing to make. It can decode many many gifs, but yes its still missing features. I hope to get to them though eventually.

I agree shaping is hard. But so is a lot of other things we have done. We will just take it one setup at a time. I am sure with time we will conquer shaping as well.

This is correct. Given any C/C++ program one can write an equivalent Nim program. But because you have advanced metaprogramming available to you it will probably be shorter and easier to understand.

To learn any new language or framework I just recommend diving in and doing things. Have some goal and mind that you want to create and work at it. Its usually hard to start at first but once you get going its just a little bit of progress at a time.

1) Why CPU? Mainly we used CPU because it's easier to get working. A lot of this graphics stuff requires deep understanding. It’s just easier to get CPU mode running. I do have many GPU experiments though. I even have a macro that translates a subset of Nim into the GLSL - GPU’s shader language. In time if the GPU path becomes better we will switch to it.

2) Yes, Pixie will render Fidget. Current system is that Pixie renders to a texture atlas. Then Fidget just deals with the textures. Pixie does work only at “load time” or when a new element comes on screen. For most screens Pixie CPU rendering will not be called that often. At this time the CPU render for text is faster than my on-the-GPU render. More things will switch to GPU as it becomes faster.

3) I am still working on Fidget, but I really wanted to get Pixie done first. I have this idea that I am exploring. But I don’t have anything for sure yet. One thing for sure Fidget 2 will be a total paradigm ship from Fidget 1. But Fidget 2 is still ways off.

I am the presenter in the video. I am here to answer any questions about 2d graphics, Nim programming language, performance and testing. Thank you for watching!

That's a lot more talks this year. Can't wait!

1. As I understand the {.acyclic.} pragma is way to telling the compiler that you take full responsibility. Otherwise without the {.acyclic.} pragma it will spend the extra time scanning the objects for cycles.

2. It appears that Nim will use "move ownership of isolated object graph" from one thread to the other. The cycle detection code is very similar to freeing an object graph to moving of the ownership of an object graph to a different thread.

I would also like more clarification from the creators. The above is just how I understand it right now. More simple example code would be great.

It's great that Nim is pushing boundaries in the memory management space. I remember reading how Java and Go were able to scan large heaps faster and faster. But what if you don't even scan the heap? Brilliant.

At first I did too, but then I thought about peoples handwriting and how it might be very hard to read the numbers. Then imagine a political fight over how many 1s are actually 7s?

I have so many little nim scripts all over the place.

Yes. People have done this.

Your explanation is very clear. Thanks.

Yes. There is nothing fundamental to nim's ARC working with nim's async. There are attempts on make nim's async cycle free.

On the website they show the foils retract into the boat.