I think it depends on what you mean by "cheap foreign engineers." I am born and raised Canadian. I make a decent chunk less than my American counterparts, even when working for the same company. Not because they are necessarily better suited for the job, but literally because of the country I live in. The same is true for engineers all over the world.
So yes, companies absolutely can get cheap(er) labour and have the same, or at least similar, quality.
The foreigner from your point of you is a local to the market that companies like Amazon or Meta are serving. It's easier to understand what appeals to that market from the ground rather than the US west coast.
I wanted to know the same and had to dig into the Docs section on the website to find that it currently supports all Chromium based browsers. Support for other browsers is said to be coming in the future.
That is just saying that they will be giving some donations to the project. I have zero insight into W4 or the Godot Foundation, but they may have already donated. They don't claim to be the sole financial contributor to the project.
Looks like they do donate: https://fund.godotengine.org/ (W4 games is an icon there as "Platinum Sponsor"). It doesn't say how much but given the amounts in the lower tiers it's probably not entirely insignificant.
So they _are_ actually using their $8M seed fund to fund Godot.
I do wonder if the author of the original post did their research properly. W4 games doesn't need to donate but they do so anyway.
> I do wonder if maybe streaming large data chunks over Erlang distribution might be a problem and a secondary data channel (e.g. over udp or sctp) might be worth playing with.
You may want to take a look at the partisan[0] library written in Erlang. It is basically that, a reimagination of distributed Erlang, except that it can be multiplexed over multiple connections.
Yeah but partisan gives you a "ton of stuff you might not need" plus the point is to treat distribution as a control plane and separate concerns from the data plane. There used to be things to worry about using Erlang distribution in general -- irrespective of backend, iirc, like HOL blocking (I think those are resolved now).
It really isn't this simple, no. I remember a number of years ago someone tried to do this. Pardon the language, but the "product" was called "Fuck adblock" I believe. It was a piece of JS that you could include on your site that, if I remember correctly, tried to see if certain JS objects existed. If they did exist, you could disable aspects (or the whole thing) of your site. Very soon after, someone released "Fuck fuck adblock" that essentially disabled this piece of JS.
It was a cat and mouse game for a while, but ultimately, if you want to detect if someone is using adblock, you need to do it in JS. And then the ad blockers will just add that piece of JS to their block lists.
Sure, but it's much easier to be on the defensive here rather than the offensive. And it implies your site is popular enough to warrant anyone reverse engineering it anyway.
Since the adblocker strats are necessarily public, you could even have a system to automatically monitor them and apply a set of composable tweaks which breaks the current public release.
You may very well be living in your own circle. My anecdata is that most engineers use VSCode these days. In my current organisation I am the only person that uses Emacs that I am aware of (and I use evil-mode). I know a handful of people use (n)vim. But by far the most common editor I see being used is VSCode.
I work on a frontend team, most of my coworkers use VSCode and very few use the vim plugin for it. On our backend teams I believe IntelliJ is still the most popular editor, it’s really uncommon to find anyone using vim or eMacs for work.
Personally I just use Jetbrains IDEs w/ IdeaVIM for most things because I can’t be bothered with all the plugins and configurations I would rather my IDE just work out the box in any language.
Not the person you replied to, but I have had some issues with this in the past. Though it is more with how it was done than the approach itself.
In this project I do not believe the IDs were always encrypted when being sent to the user. So we sometimes had to guess whether we received an encrypted ID vs a regular integer ID because it is possible for the encryption algo that was used to return a sequence of numbers.
If this is just for being able to easily switch branches, have you considered using git worktrees? Essentially you have have multiple branches checked out into different directories at the same time. The key point though is that all git refs are still maintained in a single place so you are not actually having full clones for each worktree that you have.
I personally use Emacs and magit which has great support for worktrees. I do not know if the VSCode git integration supports it.
Ah right, the main advantage I have here is that the dev server also stays running when I go to another branch (since it's a different VM). So I can work on one thing, share it with the team and in the meantime continue on another branch. They can see the devserver / running code, while I am working on something else.
It's especially useful for things like migrations or dependency management. In one branch I could work on something that has some database migrations, and then I can still switch to other branches without having to roll back the migrations.
I didn't know about git worktrees though! I'm going to read up on this.
> In one branch I could work on something that has some database migrations, and then I can still switch to other branches without having to roll back the migrations.
This is a good use case of git worktree.
> I didn't know about git worktrees though! I'm going to read up on this.
Indeed, you will like it.
The only limitation is that you cannot checkout the same branch in multiple worktree.
> In one branch I could work on something that has some database migrations, and then I can still switch to other branches without having to roll back the migrations.
I use it with VS Code since the project I work on takes 5-10 minutes to build if a major header is modified. It shows up as a separate directory, but VS Code will still realize that the directory is a git worktree.
The only thing kind of clunky is that you have to keep track of which branch is open in which directory since you can't checkout the same branch in two different directories.
> The only thing kind of clunky is that you have to keep track of which branch is open in which directory since you can't checkout the same branch in two different directories.
So yes, companies absolutely can get cheap(er) labour and have the same, or at least similar, quality.