ghnws

IntelliJ. To name a few features I've not been able to get in VS Code or have had a worse experience: - debugger

- refactoring (extracting functions and variables, renaming across entire project etc.)

- context aware selection (expand selection from cursor logically)

- stack trace / error parsing

- comparing anything (diff selection with clipboard for example)

- DB schema support even in SQL formatted as strings (e.g. when using psycopg) directly from DB by just connecting to a DB

- find in files (I've never seen a VS code user have an easy time finding stuff)

Etc.

> Type annotations do not rust make. And lack of types does not Python make.

That is never implied. See the first example in the article.

AFAIK the app code can be decompiled to see what it does. The messaging can be monitored as well. I find it hard to believe these apps could sneak in something that breaks the encryption without anyone noticing.

The proposed solution to stopping child porn from being shared on these platforms would at most only do just that: Stop sharing on these specific apps. There are plenty of alternatives including encrypted zips, TOR etc. Breaking e2ee in WhatsApp would not do anything to stop sharing the material.

I don't think it's a leap to question why this is proposed when it could never achieve it's intended goal.

I don't see how scanning for the material in major messaging platforms would impact anything. The people will just move to the next service that is encrypted. The technology exists. It can not be banned.

The linked article has a section about IDE that this one does not touch. I was surprised they are locking them selves in to one tool with their workflow.

I'm a bit worried about the dominance of VS Code. I can't stand the editor and it's popularity just grows and grows.

This is not micro optimization. This is fixing a known performance issue.

Fun fact: "Kysely" is "query" in Finnish.

You have to treat it like any other online service: Don't put anything in it that can't be shown publicly.

This screams russian propaganda.

Have a look at the frontpage of this site.

> It saves a ton of development time.

Could you expand on this? I have had the completely opposite experience.

While taking half the time to do it.

I've yet to see one good reason to use GQL for anything but public facing APIs, like GitHub API.

In my experience, you gain enough knowledge to set up a new container service in minutes fairly fast. I opt for containers because to me it's the perfect balance of ease of use, maintainability and performance. Managing container orchestration is completely optional too. All cloud platforms offer it as a service. With serverless I've had more trouble than benefits. It's not easier than containers to set up - often quite the opposite. When (not if) you encounter performance issues, they are either difficult to solve or simply impossible. I have never had this experience with containers.