This is one of the things Elixir got right on day 1, all the libraries in the ecosystem use the standard library and it makes dealing with logs so much easier compared to other languages.
> For example, you don’t need sidekiq or Redis as Elixir/Erlang is a concurrent, distributed platform. This simplifies operations and is cheaper to run.
This is simply wrong. You need a Sidekiq alternative (There is Exq which is protocol compatible with Sidekiq, others like Oban are available as well) because Erlang processes are not durable, nor do you get retry, concurrency control, etc. Everyone loves to claim Erlang is distributed and you can connect them so Redis is useless? but this is rarely utilized in the context of the web server. I have been using Elixir for more than 5+ years now, and I have never seen a valid use case for connecting two nodes.
In reality, the tech stack of the Elixir web app is mostly similar, but it makes life a lot easier if you ever have to deal with any kind of concurrency. Making concurrent requests is as simple as doing a map over a list and they just work, unlike other languages where you have to double-guess whether the library you use is thread-safe.
It depends on the layer, some of the layers might be able to take advantage of how the data is persisted. For example, if you use avro/protobuf, the decoder will handle it for you. If that's not the case, you would have to implement the migration by yourself. There is a paper[1] on this subject called "Online, asynchronous schema change in F1", which explains how to implement it.
Salesforce has this model of development and it's horrible. They won't let you run the code locally since the environment is proprietary. Even to run the tests, the code has to be uploaded and run on their servers.
Same in the semiconductor sector. You run everything remotely off a centralized on-prem mainframe and your laptop is just a thin client to a X11 session on the server. At least that's how it was 8 or so years ago. Maybe now they started to move to the cloud.
But that's understandable. You need powerful machines to run simulations and stuff. And we could collaborate with colleagues over phone, with a shared VNC session, etc.
Ah yes, the joys of developing in Salesforce "Apex" At a previous company, we had some crazy "build scripts" that would sync a local filesystem into SF, but I recall it being pretty fragile. Also, there were annoying name spacing issues...
This was a long time ago, but I had a similar experience with Blackbaud (A Salesforce competitor). The suite of APIs required was only installed on a server so you could not run the code locally. You could either perform code edits locally and copy the files before building, or simply do all development while remoted into the dev server.
With all the time/effort Salesforce has put in to SFDX and the VSCode plugins releasing an APEX compiler must just be completely off the table. I do a lot of Salesforce work and introducing new developers to the SF way of doing things results in a lot of "wut." facial expressions.
In a previous company, we'd have people making direct edits in Salesforce. We'd then export the edits with the Salesforce CLI "force" utility, bring it into a local git repo, run some rather buggy scripts that would change the object namespaces/prefixes to a generic prefix. Then you could finally do a diff and a PR in a normal way.
We then had other scripts that would take the "generic" code and change the namespaces/prefixes for upload into QA or prod environments. It was quite painful.
You can opt out by clicking Manage settings and then uncheck the green tick. I just realized I can enable reject button as well[1], should be available soon.
Nothing specific, I was even looking at adding support for beancount then realized it's much more strict and doesn't support some features like periodic transactions (which I use for budgeting)
Cli is already available for linux (which provides the same functionality, just that you have to use the web browser instead of desktop window)
For desktop app I plan to add support soon. The delay is because there are too many variations (appimage/flatpak/deb/snap) and I need to figure out which one to support etc. I use linux myself (NixOS).
The project comes with a flake.nix file, you can try that (you would still need to build it manually, I use the flake only to bring the dev environment, not to build the final package). I don't plan to submit to nixpkg myself or any other package managers. I will only focus on binary builds that's downloadable from release page. I don't have any experience with maintaining distro level packages, and I don't think I can figure out the details and keep it maintained. I will leave it to the community to figure that out.
reply