I can't overstate how good Elixir + LiveView is, especially for prototyping. I have been experimenting with it ever since it first came out, mostly games, and I have to say that building even simple multiplayer games is a lot of fun.
(FYI there is no actual game here, just pick emojis, place them in the arena and watch them fight to the death via a poorly designed combat system. Yes, those placing emojis other than you are other players.)
This was a prototype that I built to see if real-time multiplayer games were feasible. Apparently LiveView manages high tickrates decently enough to be a valid solution for (quasi) real-time games. This game for example runs at a whopping 8 ticks/s! It can handle more, as I've tried developing with faster tickrates, I think as high as 24 t/s, but I want to avoid server strain. With enough HTML/CSS/SVG wizardry you can get away with quite a lot. But the most amazing thing was the fact that there was no need to fiddle around with state syncing. Everything just works! I have nothing but praise for it.
I understand what you're saying, but with Facebook it's different, because it's tied to your real identity, which changes the context a lot compared to other services.
In my case, because of that, getting a Facebook account is hard, if not impossible, because those "real identity" checks are obscure: I attempted twice to sign up for work-related reasons, and I failed both times despite providing IDs and pestering support.
I have literally NO idea why I cannot have a FB account.
However, even if I could, I hate Facebook so goddamn much that if this was my only option I would rather not use VR altogether.
And I love my Oculus Rift, especially for game development.
I am royally pissed off, and I will gladly go forward with a class action lawsuit.
I tried both and it's much better than Mastodon IMO due to how much more lightweight, faster and easier to deploy it is.
Maybe it has less features, but they're fully worth the sacrifice.
My first thought was "I absolutely love this" and sure enough it's the first comment that pops up.
I remember a 24/7 livestream that ran on Youtube some time ago that only played drive-throughs of Tokyo videos while cheesy 80s japanese city-pop played in the background. It was pretty fun, but of course it was shut down, probably because of copyright. I miss it, but this is a valid replacement. Thank you!
Worst possible case you can drop the messages from a domain, which is how federated systems already work.
There's no reason to ever revoke control for messaging systems, though, genuinely: imagine if your e-mail address could be taken on a whim by anyone. It can be! But you'd never want to revoke control of a domain rather than just marking it as spam or illegal and dropping messages from it. It functions as an inbox more than it functions as an outbox.
I agree with the first statement. I'd go as far as saying that Unity is the JavaScript of game development.
Sure, when you start out you get out results FAST, but then you run into limitations, weird behaviours and quirks that have to be worked around, and soon everything becomes a mess.
Mind you, I'm a hobbyist in this field so maybe you could chalk it out to inexperience, but I shiver to think to what professional developers have to deal with if the small prototypes I cranked out got so convoluted.
I'm trying out UE4 lately and although it can be daunting at times (and with horrible documentation), it feels much more comfortable to use in the long term.
> Mind you, I'm a hobbyist in this field so maybe you could chalk it out to inexperience, but I shiver to think to what professional developers have to deal with if the small prototypes I cranked out were that painful.
Careful adherence to best practices (often discovered the hard way), banning certain code pitfalls with a linter, and many workarounds :(
It took me months to make something semi-usable out of (a subset of) UNET, and I can clearly see why nobody at Unity wanted to maintain it. Still, something half-decent and mostly backwards-compatible could have been made of it with enough work, but again they chose to chase the new shiny :/
The more you can avoid the "nice" stuff the better your project will be. All those shiny things in the UI that look easy will be painful in the long run once they start disappearing (I swear component references just disappear sometimes) and breaking and making the life-cycle of the application confusing.
My main complaints about UNET could be summarized as "the order in which things happen is very chaotic" (in unbelievably many ways!). I've not checked to what degree Mirror has improved on this.
Based on a superficial look, I'm worried it might have been more concerned with adding features than fixing and simplifying the fundamentals, but I don't really know.
Mirror is amazing :) But it's a big shame for Unity that you need to use it in the first place, because they don't ship a working networking stack out of the box.
What limitations does Javascript result in after initial FAST results as you say? All of the web is running on JS. It’s not without its faults but I resent the analogy.
Do you have any pointers towards good tutorials for a hobbyist on UE? I dabbled with Unity and want to see the other side and it wouldn't hurt to get back into C++ after all these years.
Sorry, I don't have a solid reference, I'm mostly watching snippets of random youtube videos and trying stuff out on my own and putting the pieces together as I don't have the patience to sit through a course.
Also, I'm working with blueprints as the C++ side lacks any kind of docs or tutorials. Initially I was repelled by them, but after getting used to them, they're not as bad as they seem at first glance.
And from skimming along the comments, both on HN and on Disqus, there's a lot of confused people trying to understand/describe the difference between Nix and Docker, because although the article described how Nix works in a very technical way, it didn't explain what it can be actually used for.
It's a package manager written in such a way as to properly solve the problems with existing package managers which docker patches over. It uses deterministic builds and careful isolation of dependencies to ensure that the environment it creates is the same each time, and that you can have packages which depend on conflicting versions of another package installed at the same time.
The entire OS is accurately described by a config file, and this can be reproduced exactly using just that file.
In contrast to traditional package managers: handles conflicting dependencies, state is tracked through editing the config file, not a serial of install/uninstall commands which mutate the state of the system. Config files of installed packages are also controlled through nix config.
In constrast to docker: properly reproducable (Docker will re-run the same commands in the Dockerfile, but there's no guarantee you'll get the same result. For example, basically any package installation from a traditional package manager you run in the Dockerfile will not reproduce when run later because newer versions of packages will be installed), also more efficient in terms of space usage. However, AFAIK it does not namespace networking and so on (nixOS has its own containers system which does do this however).
* automatically installing all project libraries and dependencies so you can build your project without having to apt install a bunch of stuff first. This is done through direnv/lorri, so when you cd into the project directory, direnv uses nix to install everything automatically. Very quick onboarding and also no need to keep up with the various company projects' deps.
* building docker images with intentional layering so deltas remain small is a breeze: buildLayeredImage.
* with home-manager I can ensure my dotfiles have all their dependencies so vim plugins and whatnot just work. It also means I get the same nice home environment on _any_ Linux distro I choose.
* Same as above except for my entire system with NixOS.
* Shipping packages with specific config defaults _only_ for your project directory so you don't have to worry about making everyone configure something is also a breeze with Nix package overlays and overrides.
* You can even have Nix modules for your VPN connection and the like so co-workers can import that into their home-manager or NixOS configuration, and if it changes so does your system/home config next time you build it.
I understand the feeling, but from my experience it fades away pretty quickly once you get the feeling of the language.
These days I'm working again with Rust to add a new feature to a project after not touching it for months, and that feeling of "oh dear god this is awful" that I felt when I was starting out with the language was back again.
However, once everything clicked in, with the compiler telling me exactly what was wrong with the code, and the project compiling which meant that I could be damn sure that the code I wrote would work with little to no risk of breaking in unexpected ways... that sure did spark joy.
That seems a lot like taking up smoking to me. I took a puff once. "Oh dear god this is awful" was pretty much my reaction. For some reason people experience this, then power through the "awful" until they've ingested so much they can't easily walk away from it.
I've never understood this. Why continue taking "awful" puffs? Why not just use/ingest something else that doesn't feel awful?
And yes, I get that languages are extremely subjective and some folks find it joyful not awful. Good for them. I'm glad they found happy. For everyone else though...
An example:
https://dev.voppe.it/chess
(FYI there is no actual game here, just pick emojis, place them in the arena and watch them fight to the death via a poorly designed combat system. Yes, those placing emojis other than you are other players.)
This was a prototype that I built to see if real-time multiplayer games were feasible. Apparently LiveView manages high tickrates decently enough to be a valid solution for (quasi) real-time games. This game for example runs at a whopping 8 ticks/s! It can handle more, as I've tried developing with faster tickrates, I think as high as 24 t/s, but I want to avoid server strain. With enough HTML/CSS/SVG wizardry you can get away with quite a lot. But the most amazing thing was the fact that there was no need to fiddle around with state syncing. Everything just works! I have nothing but praise for it.
Try LiveView if you have the chance!