rlp

Julia's ahead-of-time compilation story is not great. If you just want a single executable, it's kind of a pain, and there are all sorts of caveats. I think it's slowly getting better, though, but the language really wasn't designed for that use case. If I needed run-time metaprogramming/JIT compilation/a REPL, I'd go for Julia. For a single executable, I'd choose Nim.

I'm a big fan of Nim, but I really wish it supported cyclic type declarations in separate files and out-of-order functions without forward declarations. As it is, I'm constantly structuring things around those limitations. Big projects often end up squeezed into a single huge file (or a few huge files).

No, they aren't. That's why those two were called out. Not sure how IHME's mistakes come in to play here. If they are making mistakes, they should be called out as well.

But those doctors clearly don't have a good grasp of basic statistics. You cannot extrapolate cases for a whole state based on test results from a non-random sampling of people. They are making a basic error and claiming to be experts, that deserves some shaming in my book.

It's not exactly an industrial-strength GC, but Nim uses TLSF to reduce fragmentation: http://www.gii.upv.es/tlsf/. I'm not sure how that compares to the strategy in the article, though.

Same, janky scrolling in Chrome and Firefox.

It's a header-only library, it would effectively add "using" statements anything that included the library.

The author of this also created the excellent Sokol cross-platform graphics/sound library, which is being used here.

https://github.com/floooh/sokol

See linear probing hash tables, the items are stored directly in the main array with no linked lists.

Well, I would say that it highly depends on your workload. .NET's biggest performance win is lower-level memory management, like structs and Spans. If you can use those to avoid allocations and improve memory locality in your critical path, you'll end up beating the JVM.

For allocation-heavy workloads that can't use .NET's lower-level memory tools, I think the JVM is still a bit ahead with its better GC and profiling HotSpot JIT compiler.

You're technically right, but that's potentially an enormous task. If we're comparing Unity with Unreal functionality, integrating a scripting language should include editor integration, debugging, etc. I'd rather spend my time actually making a game.

Well, I've used both extensively, and they are good at different things. Unreal is far better IF you fit cleanly into one of their templates (first person, third person, etc). Superior renderer with great built-in post effects, FAR better multiplayer support, better materials/shader editor. However, if you try to do something substantially different than they have imagined, it can get ugly very fast. The C++ used is strange, with all kinds of weird GC macros strewn about. As a programmer, I hate blueprints. I wish there was a scripting language alternative. And god help you if you actually want to modify the engine code substantially, it's a monster (not poorly done, just sprawling and extremely complex). Look at the nvidia gameworks integration, it's all these forks of the engine built by random people, it's a mess.

Unity shines in its flexibility, easy scripting, and fast workflow. I can whip up a script in C# very quickly that does exactly what I want. With that scripting, I can have a lot of control how the engine and rendering and post effects work, much more than Unreal. Prefab workflow makes much more sense than anything in Unreal blueprints. Mecanim is not as fully featured in some ways as Unreal's animation system, but with the Humanoid skeleton, animations can be used easily on different models. With Unreal, you need to use retargeting, which is painful and can have serious problems if the models are even slightly different in size.

I would suggest SBCL if you're going with Common Lisp, although Clojure + libgdx could be an interesting combination.

The first letter of a Nim identifier is case sensitive, it's just the rest that aren't.

This is not accurate. C++ has statically enforced private variables that cannot be modified by outside functions without fairly painful workarounds and castings. But, if you want to say that the ability to do those castings would disqualify any compile-time guarantees, well, OCaml has an equivalent escape hatch. Module Obj contains a bunch of functions to manually manipulate any object fields and cast arbitrarily using the "magic" function.

Is there a better alternative to CMake? I find its syntax painful and inconsistent, but once a project is configured, it works reasonably well for producing cross-platform builds.

I couldn't find anything on this either. The assembly emitters in their repo don't suggest a WASM backend: https://github.com/ocaml/ocaml/tree/trunk/asmcomp

LGPL does not allow static linking. From Qt's legal page:

In case of dynamic linking, it is possible, but not mandatory, to keep application source code proprietary as long as it is “work that uses the library” – typically achieved via dynamic linking of the library. In case of static linking of the library, the application itself may no longer be “work that uses the library” and thus become subject to LGPL. It is recommended to either link dynamically, or provide the application source code to the user under LGPL.

For learning Reason, I found this page invaluable: https://reasonml.github.io/try

You can put in Reason or OCaml and it will spit out the other. I used it to work through Real World OCaml in Reason.

This is a common story in many countries, a fear of the rich immigrants/expats "taking over" while simultaneously finding ways of profiting off of their money. I've seen similar situations in many Asian countries with much more overt racism. No reason to be hard on America here.

Even in game development in C/C++, you wouldn't want to be allocating/deleting heap objects in every frame. You'd probably end up pooling there too, unless you're referring to the problem that the JVM has no value types and forces heap allocation for all objects. This will be fixed in JDK 10 (see Project Valhalla).

Do you find LuaJIT much faster than a JavaScript engine like V8? That used to be true, but I was under the impression that V8 had basically caught up (unless you need to make a lot of FFI calls, since LuaJIT is heavily optimized for that).

I think React is actually quite sane to use now. However, if you're looking for the future, you may want to check out Web Components and Polymer: https://www.polymer-project.org

I agree, MobX felt much more natural to me when dealing with CRUD-style apps, there was very little boilerplate. Redux is great for apps with extremely complex workflows, but that's fairly rare in my experience.

Sarno's program completely cured my RSI. My highly-regarded surgeon was ready to operate for cubital tunnel, which had been getting progressively worse for about 2 years. I was to the point that I would feel pain all the time while typing, and had some tingling/numbness. I was concerned about surgery, so I decided to try some alternatives first, and the stuff from Sarno was amazing. It was scary as hell to just tell myself that the pain wasn't real, and that I wasn't hurting myself, but I figured it was worth a shot.

It's been 10 years since then. I now have zero problems, no special exercises, no ergonomic keyboards, chairs, desks, etc. I also regularly play ARPGs like Diablo 3 and Path of Exile, which make most people with RSI cringe.

I agree that Sarno's framework is not perfect. I'm not sure I buy his explanations as to why it works, but it does work. The key is that there is a huge mental component to RSI (or, at least, to some cases of RSI) that most people don't acknowledge. The monitoring/worrying about damaging yourself does something to those muscles/tendons that builds up over time.

I love Atom, but it is noticeably slower than VS Code when editing, especially when autocomplete is involved.

Love the name! But there's no way Go's feeble type system supports anything remotely like a Monad.

Try clicking the Show All Files button at the top of the solution explorer. It will show everything by folder, which I think is what you're looking for.

I'm not a huge fan of promises on their own. I think they are clearer than straight callbacks, but it gets confusing as you do more complex things. However, they really start to shine when combined with generators. Being able to yield a promise makes code very clean and clear.

And you can always use something like bluebird's promisify if you're combining promises with existing callback code.

I didn't have any lag. That was fun, kind of like Bomberman. Nice job!