For a MVP, it's hard to beat Phoenix Framework channels and Liveview, and if you want to completely decouple the UI from the backend with something like a native app, or separate webapp, it's absurdly easy to just add the resources to a route that goes through the :api pipeline instead of the :browser.
Once you are ready to outgrow a single machine deployment, the BEAM clusters so well in a way that works the same on your dev machine. Also if you want to get really complicated multi-service design, Umbrella apps are leagues better than docker-compose setups that I have had on dev machines that make a 16G Macbook pro instantly put everything into swap.
> Also if you want to get really complicated multi-service design, Umbrella apps are leagues better than docker-compose setups that I have had on dev machines that make a 16G Macbook pro instantly put everything into swap.
Not sure I feel the same warm feelings about umbrella apps and I definitely don't think you can compare them to general-purpose container orchestration like docker-compose, but that's totally an optional part of the language.
Otherwise, yes, Elixir/BEAM is an excellent soft real-time environment for developing chat applications. If your scale goes off the charts (millions of concurrent users), you can extend with Rust for the slower operations in your critical path. See https://discord.com/blog/using-rust-to-scale-elixir-for-11-m...
As mentioned, Phoenix Channels is a great place to start and will get you very far. The other nice and unique things in Elixir & Phoenix (OTP, LiveView, etc.) are just a bonus.
Half of the reason that I enjoy using GNOME, KDE, and other distros is that I can theme the entire system for a relatively consistent experience. I enjoy having system apps all be the same configurable color theme and even design language with flat themes and material themes becoming popular.
Layouts might be a bit much, but themes are a key part of the user experience.
I think the bigger issue are that devices are trying to handle many things at once, and badly. I stick with projectors (which keep getting more affordable) which just handles video, and an audio system which just handles audio. No smart tv bs, and I just use a fire stick/chromecast/laptop to handle the content.
I'm more than happy with my setup, except that I usually want to wait until after sunset to watch shows or movies. It's probably better for my own free time to not spend a day watching tv anyways.
That's pretty cool. I remember using a rocksmith cable into my laptop running Bias FX as a last minute replacement for my amp when it died the day before a gig. Good to see that there is a product that fills in the niche for USB-C.
My biggest question for this product is the sample rate, and at what output the input clips. This would be fine for most passive guitars, but active EMGS or a Piezo system could definitely clip or distort the input if you don't roll off some volume.
That's all fine if you stay stateless. Once a well-meaning developer introduces local application state into your web app or adds a feature that locks your database, your web server is no longer "embarrassingly parallelizable". This doesn't even start to handle issues you get when you use a single-threaded langugage that cannot handle multitasking well. Sidekiq makes money purely because Ruby is single threaded, and its thread will lock if you give it a task that takes too long.
The microservices movement seems to be a misguided reaction to these self-imposed issues where instead of handling proper task management on a process level or with async/concurrency, functionality is split between servers, codebases and infrastructure. This problem was solved with Erlang decades ago with the actor model and supervision, and newer BEAM languages like Elixir and LFE are a pleasure to work in.
You even have this model and concurrency ported to JVM with Akka, C++ with CAF. Granted, the Actor model and the field of concurrency as a whole is solving the problem of enforcing statelessness in a way such that tasks can be efficiently distributed multiple cores, and that no single task locks up your machine for too long.
Once a well-meaning developer introduces local application state
And this would break the minute you have more than one web server. How many websites of any consequence are running on only one web server?
Having server side session state that can be shared across servers is a solved problem as is having a load balancer that handles “sticky sessions”. I’m not saying either is a good idea.
Also if you are “locking your database” even if you use a faster runtime, you’re just delaying the inevitable of your scaling limits.
Maybe you don't understand persistent background jobs or maybe I don't understand Erlang.
What happens if you have a bug in a task and it takes a week for your development team to develop a fix? Does that Erlang task live in memory all that time? That's the point of Sidekiq's retry subsystem and persistence in Redis.
Ruby is multi-threaded. My customers buy my commercial versions because they want the more complex features and support.
Depends on what you want out of a computer. If you want a general purpose (as in write programs and run them) Plan 9 is a pretty self-contained operating system and software system if you are confident in your C and C++ abilities. I've also heard that BSD is pretty well documented internally, so if you know that system, you should be ok.
Alternatively a fun retro setup could be an apple II or a windows 98 box with Encarta disks.
As a specific distro that is directly focused on what you specified, Endless OS seems to have the Encyclopedia and other preinstalled apps for online use you were talking about.
Which leads to another interesting take on the situation. Which OS would make a good starter to rebuild from? It should be small, easy to build, and cover just core features including network. Even single-user, single process like Windows 98 as suggested could work, although we'd want much newer source without cruft. The GUI also seems superfluous--maybe just high density text panes.
Sometimes the vim key-bindings are incomplete, or wrong. I moved from intellij to vim with language server plugin because the times where the keybindings did something that I didn't expect, or were not supported leaving me hunting through dropdowns were a pain in the ass.
The other thing to consider is if you are really comfortable in a language, sometimes the lag you get from editing fast in an IDE outweighs the feature set you get from it. Vim is always buttery smooth for me, even in large files and with a bunch of plugins. I can't say the same for other editors.
Finally, having vim from within a terminal means that I can CTRL+Z to all my cli apps to manage the project I'm working in. That combined with backgrounding live-reload for web development, or jumping into a REPL make for a rewarding flow-state between building, executing commands and editing that I've only heard about from Emacs users. As much as it is on topic with the rest of the conversation here, I tried emacs and spacemacs and doommacs a few times, and have never been able to enjoy it as much as jumping between vim and zsh.
It could have been an internal document that was published a few years after written. This could be due to a indecision on whether or not to publish the work. This document could also be originally for internal use to educate new hires.
Building Javascript-based frontends are already compiling to static assets, which Netlify could already host. JAMstack is about having the javascript front-end call APIs on the backend. This is about creating an environment for all the back-end functions to be in one place, possibly with the front-end deployment. Not sure how it is going to be implemented though.
For a MVP, it's hard to beat Phoenix Framework channels and Liveview, and if you want to completely decouple the UI from the backend with something like a native app, or separate webapp, it's absurdly easy to just add the resources to a route that goes through the :api pipeline instead of the :browser.
Once you are ready to outgrow a single machine deployment, the BEAM clusters so well in a way that works the same on your dev machine. Also if you want to get really complicated multi-service design, Umbrella apps are leagues better than docker-compose setups that I have had on dev machines that make a 16G Macbook pro instantly put everything into swap.