You do not pay anything different for AI prompts. You should really actually try the product before you make up all these things about it.

But what you pay involves the calculated cost of using the AI, otherwise they’d be losing money if a lot of users were to make too many prompts. So it should be possible to have a lower price that didn’t give you any prompts.

Even if it was, there’s no way to know, people can just lie. It’s not like it will be obvious, some people might have a feeling it is (based on their experience playing with LLMs) but won’t be able to point exactly why.

But is it that different than the podcasts voices Google already generate with NotebookLM since a while ago?

And I already have the next bubble ready: https://youtu.be/wSHmygPQukQ

This has quite a lot of links already. I feel like it would be very useful to make some sort of “Wiki” about this.

Another option is to have enough people in the company interested in using that to justify it.

In my company (a large bank) Linux is now being rolled out to selected people as test because there was enough interest from a lot of the backend crowd.

You’re right that garbage collection makes Go simpler, and maybe other patterns do contribute to prevent complexity from piling up. I never worked with Go outside of silly examples to try it out, so I’m no authority about it.

What I meant was more of a “general” rule that the simpler a language is, the more code is necessary to express the same thing and then the intent can become nebulous, or the person reading might miss something. Besides, when the language doesn’t offer feature X, it becomes the programmer’s job to manage it, and it creates an extra mental load that can add pesky bugs (ex: managing null safety with extra checks, tracking pointers and bounds checking in C and so on…).

Also there are studies that show the number of bugs in a software correlate with lines of code, which can mean the software is simply doing more, but also that the more characters you have to read and write, the higher the chance of something to go wrong.

But yeah, this subject depends on too many variables and some may outweigh others.

That’s a good argument.

The mental model I have about performance is that the higher abstraction usually beats the lower level abstraction.

So in that sense, a well architected software with proper caching, multithreading where it matters etc. will beat badly architected software (ex: one that brute forces everything). Then, that being equal, good algorithms and solutions beat bad ones. Only then faster runtimes make more of a difference, and at the bottom things like more efficient processor architectures, more efficient compiler etc. beat slower ones.

A good example is Lemmy itself, which as far as I know was made in Rust to be super fast, but then at the beginning was being DDOSed quite easily because of the way the database was designed and lots of queries were very slow. Once they fixed that, Lemmy became actually usable.

Using git effectively is like heading superpowers in programming compared to not having any version control as it allows you to do a bunch of things that would be very complex otherwise. Ex:

• When writing code, if you only commit “working code” it’s easy to check at any moment what changes you’ve done in the last chunk with git status. Even most IDEs nowadays highlight the changes lines with some special marker. This allows you to know every detail of what you’re doing without filling your working memory tracking files yourself.

• Seeing the history of your project allows you to track any of your workmates changes as well, you can always check who last changed a line of code with git blame (IDEs also make that easier), your commit text will usually tell you what is that change about.

• It allows you to quickly try something out and if halfway through it you realize it won’t work, just discard the changes and restart using a different approach.

• It allows you to have multiple “work-in-progress” features simultaneously in different branches, which makes it possible to do hotfixes on production code even though the development branch is way ahead.

• It lets you break a big feature into multiple small commits and later on it’s easy to gather multiple commits in a branch into one big commit if it makes sense (let’s say you were not sure how you’d do it at first and kept changing something back and forth trying different things. Once you realize what the best approach is, you can turn all those changes into a single one).

• Committing often allows you to “revert” any change in the future very easily, in a non destructive way.

So a lot of advantages of git require also to use it alongside best practices, such as the different git branching models. It doesn’t matter if you prefer using the command line or some visual client, just the fact of understanding how you’re using it makes a lot of difference.

As a programmer myself, collaborating on projects can often be more complex than simply "adding features." It's not uncommon to encounter challenges such as mismatched preferences in technologies, differing architectural choices, or even divergent design aesthetics that can dampen interest. Besides that, the original creator may not even appreciate the proposed changes and could reject them.

if I have writer’s block, I just let them pump out something wrong since it’s easier to critique a blob of text than a blank page.

Yeah I mentioned this before while taking to a friend about it. Humans are much better at editing than coming up with stuff from scratch, so seeing the suggestion sometimes is helpful even if it’s wrong.