gw

Is it a "javascript application" or a "page with text that uses javascript for dynamic features"...

Y'all both are making great tools but consider giving a read-only view of the page when javascript is disabled. After disabling JS this gives me a blank white screen: https://athensresearch.github.io/athens/ Same thing when i tried it with roam.

You sure? https://forum.nim-lang.org/t/4022#25046 edit: the docs seem to say you're right, maybe that forum post is outdated but it's from nim's author.

Not the commenter but which one of these is the defer generating?

    // option 1
    try {
      fp = os.open(x)
      fp.read()
    }
    finally {
      fp.close()
    }

    // option 2
    fp = os.open(x)
    try {
      fp.read()
    }
    finally {
      fp.close()
    }

Should we close if open fails? Maybe, maybe not, but with try/finally it is obvious which one it is doing.

Nim's defer just wraps the current scope in a try/finally, with the deferred code running in the finally. It is probably better just to use try/finally directly because it's more explicit about what is in the try block. It's not worth it to obscure that just to avoid a new level of indentation...

You can still hold on to references to textures and meshes you uploaded to the GPU without using a full-blown scene graph. Some state is necessary no doubt, but this seems more like unnecessary state that could be replaced by something more direct. But i don't know, i'm not familiar with three.js; the click handlers seem useful.

That makes sense, but it seems like a case of building an abstraction to solve a problem caused by another abstraction. If a scene graph creates a new chore for me that necessitates yet another dependency, i think it'd be simpler to not fuss with these layers at all. That's a choice i don't have with the DOM.

That looks neat but why would you need a react-style reconciler to render a webgl scene? It's immediate mode...every frame is rendered according to the latest state available. What is even being reconciled?

Crawford says nobody truly followed in his footsteps but I think Jason Rohrer qualifies. The two even shot a documentary together, and the scene where Crawford showed off his Storytron project to Jason was pretty revealing. Jason called it baroque and Crawford responded that he'd consider his life a failure if the project fails:

https://www.youtube.com/watch?v=zA_0_dSD3-Q&t=27m35s

Crawford definitely is not doing enough introspection. I hope the man resets and makes an inspiring project without the self-romanticizing or self-pitying.

Yeah it's a bit bifurcated. Internally there's a lot of coupling -- HTML embedded directly in the C code and whatnot. This could be resolved if tools could be built on top of fossil, but the CLI code uses `exit` everywhere which makes it impossible to use as a library. I think they made an incomplete attempt at a JSON API, but what you really need is a proper linkable library like libgit2.

It would at least be far less of an issue. I don't see anyone being confused that https://github.com/facebook/react is the official repo, and not https://github.com/react/react. It's the fact that a collapsed name is a shortcut that imbues it with this special stature. And i believe maven central doesn't even allow one-segment group names for new libraries, though clojars obviously does.

I wasn't even addressing the crates.io team, i was addressing the author of the post.

The quote was a guideline, not a requirement. Cognitect (who makes the clojure CLI tool) doesn't even control clojars, the main clojure maven repo, so they wouldn't be able to enforce that even if they wanted to.

I didn't choose the shorter names because i "care[d] about having shorter names", i did so defensively, because i figured if i chose `net.sekao/iglu`, someone else would choose `iglu/iglu` which would imply that theirs was the original or official version.

Another point i didn't mention is that maven was designed from the start to be decentralized; many companies run their own private maven repos, but also pull artifacts from maven central. Having group names reduces the chances of collisions between their private servers and a public maven server.

You really should look to other ecosystems and see what lessons they've learned. In java, packages are normally "namespaced" by the author's reverse domain name, like `org.lwjgl/lwjgl`.

Since clojure uses maven as well, the same applies, but clojure tools like leiningen decided to create a shortcut: if the group and artifact name are the same, like `iglu/iglu`, they can be collapsed into one name: `iglu`

Well, that just encouraged everyone to choose collapsible names. In retrospect, this didn't buy us much. Who cares about saving a few characters of typing? Most now seem to agree it wasn't a good idea.

When the "collapsed" name falls out of maintenance, the forks will all seem somehow less "official", even if they are much higher quality. Forks are inevitable; why would you want to discourage them?

I finally decided to start using the reverse of my personal domain for my future libraries. The java folks were right all along.

I think the instrumenting and generator stuff gets disproportionate attention. For me by far the biggest win from spec has been with parsing. This completely changes how you'd write a library that takes a data structure and parses it into something meaningful (for example, what hiccup does for html or what honeysql does for sql).

In the past, this required a lot of very ugly parsing code and manual error-checking. With spec, you write specs and call s/conform. If it failed, you get a nice error, especially if you pair it with expound. If it succeeded, you get a destructured value that is really easy to pull data out of. I've done this in a half dozen different libraries and i'm pretty sure i wouldn't have even written them without spec.

Deprecated, not removed. In fact opengl will still be supported in the new ARM macs.

Interesting. When you say "save and restore state", do you mean actually serializing it and loading it later? In what situation would you want to do this? Not doubting that there is one but i haven't heard of this before.

Webgl doesn't have this problem since it runs those functions on a context object. But yeah i wish there was a way to do that with opengl.

It is pretty wild, though mine wasn't quite as bad. It ended up clocking in at 650 lines. I guess part of that is because nim doesn't have braces... https://github.com/oakes/vulkan_triangle_nim/blob/master/src...

It's things like this that make me not worry about sticking with opengl. It's supported everywhere, fast enough for my uses, and is exactly the level of abstraction i want to be at. I completed the vulkan triangle tutorial and i cannot imagine needing all those knobs for the games and other things i make. I'm pretty confident that by the time opengl is no longer natively supported, software layers like this will be stable and fast enough.

For nim i like this one: https://github.com/johnnovak/illwill

It is immediate mode so you render the entire UI every tick, though it is smart enough to not actually redraw things that didn't change.

You can do that if you want. You can also just sleep the render thread until inputs are received, if you are sure that only user input can cause changes in the UI. See glfwWaitEvents for example:

https://www.glfw.org/docs/latest/group__window.html#ga554e37...

I do love how zig's comptime naturally led to generics without extra syntax. But after using nim i'm convinced that macros make even more sense for systems programming. They can even affect performance -- nim's macros can generate types that would be difficult to write by hand.

I also take issue with your statement that zig is "more minimal" since that only applies to the user's perspective -- from the compiler's perspective, macros make a language far more minimal. But i vaguely recall already discussing this distinction with you so i don't want to rehash it.

At any rate i will definitely be paying attention to andrew's progress, he has a really clear vision.

I did manage to fork it and prevent it from aborting, but i don't want to maintain it forever. I tracked it down to this function:

https://github.com/nim-lang/Nim/blob/cd28fe2ef7a204721efa720...

It's calling `quit` which cannot be caught in a try statement.

Yeah it really is a hidden gem. You can use it as a bash replacement, and with the new compiler API you can embed the entire interpreter in your program. My only complaint is that the interpreter aborts the process when the nimscript code has an error, so you can't really use it for hot code reloading right now. I hope they fix that eventually.

> Who's using Nim? What are you using it for and how are you finding it?

I am using it for game and music programming: https://github.com/paranim

Only been using it since the beginning of the year and it is fantastic. Much less development friction than rust, and perf is very good, especially with ARC.

I would look into IMGUI + GLFW. A lot of neat programs are being made with IMGUI these days, for example: https://remedybg.handmade.network/ RemedyBG's entire UI is IMGUI, including the menu bar, tabs, etc.

I've seen that but Bryan said this just a few days ago:

> This was a smaller consideration - but more fundamentally, the model Neovim uses for input - queuing it on an event loop and handling it asynchronously - is at odds with what we required - to be able to process the input -> handle updates synchronously.

https://news.ycombinator.com/item?id=23628381

> as a side note, i think more and more people are starting to realize that the async paradigm is not a panacea.

This is why libvim (from the oni2 project) is based on vim rather than neovim. Even aside from performance, it is a huge simplification if you can interact with an editor engine in the same process, synchronously. At some point we replaced simple function calls with baroque APIs accessed over localhost...