I agree. NATS is much more simplistic to use and deploy. Easy to run locally for development. Jetstream offers useful features like persistent streams, and kv and object stores.
A lot of people are focusing on why insurance is complicated in the United States, but I'll do my best to answer why tech has not made this more simple.
Why tech hasn't simplified health insurance?
There are no incentives for an insurance company to make the process easier. Their incentives are complying with the law while minimizing payouts. Insurance companies make large technology investments in making this happen. Providers are also incentivized by complying with the law, but instead of minimizing payouts they maximize their billing to the insurance company. They too make large technology investments in making this happen. No one is incentivized to make any of this easier for the patient, so why would they pay for tech to solve that?
Beyond that, yes there are regulations that make things complicated. Chiefly HIPAA, but also the ACA. The real challenge is a solution that makes everything more simple for the patient while appealing to providers and insurance companies that have conflicting incentives. Is there a tech solution for this?
I've been picking up Elixir and the Pheonix framework and I'm impressed so far. Pheonix is a very productive framework. Under the hood Elixir is very lisp-like, but the syntax is more palatable for developers who are put off by the syntax of Lisp.
Why isn't it more popular? It's always an uphill battle to introduce a new programming language or framework if BIGNAME doesn't use it.
I disagree that GDScript is a poor builtin language. It is somewhere between Python and JavaScript. It gets the job done and there is a lot you can do with it. Signals are great for things like state management. I'm not really sure what you mean by spaghetti code and how signals are supposed to help. I do agree that there are some annoying OOP aspects like providing a path to a scene (module). It's verbose but not unlike library imports in other languages.
When using the optional typing in GDScript, I'm surprised at how many errors are caught before runtime. The optional type syntax is nicer than Python's and the auto complete is good.
Godot could have built on Python, but they would have had to also include a language server (and maybe ipython or jupyter or something) to get the full seamless experience that GDScript gives. Including all that seems a bit much.
So, like you, I appreciate GDScript and have sympathy for why it was created.
Also, GDScript hasn't done anything like implicit type coercions (see JavaScript) and so GDScript can improve without breaking backward compatibility. If needed, breaking backwards compatibility in GDScript won't be as bad as breaking backward compatibility in a real programming language, so they can steer it where it needs to go for the benefit of Godot.
This post has generated a surprising amount of conversation for how little documentation this repo has. Looking at the code this looks more like a project rather than a game engine. The property editor looks interesting. Seems like this post is being upvoted based on the title vs the content.
Others have mentioned Godot and I really recommend it as an introduction to game development. It is very easy to pick up and the default programming language (GDScript) is easy to learn. I have a few small games and plenty of PoCs with Godot.
While many engines can be ported to the switch, including Godot, your son won't be able to do that with the Switch he has. This requires an official dev kit, which requires approval from Nintendo. See this thread to get an idea of what is involved. https://old.reddit.com/r/godot/comments/1f9o4sp/i_just_recei...
If you think your son will be motivated to make a game for a handheld platform I recommend the Steam Deck. Your son can install Godot on the deck and with a mouse and keyboard attached your can actually use the Deck to both build and play his game. The short feedback cycle will hopefully keep him engaged.
reply