Also being able to prove the relationship between different parts of the code enables a lot of productivity tooling like IDEs. Simple things like renaming a class or a struct become chores at best in a statically typed language, whereas in dynamic languages there is an element of risk in refactorings like that.

Proofs of concept are a very common thing everywhere. Sometimes it's easier just to show code instead of explaining everything, which was the case here.

We're not able to properly define general intelligence, let alone build something that qualifies as intelligent.

I don't know, SQLite it's something that makes sense in theory, but I think its easier for ops people to just use a proper database. If you need to move the database to a separate machine, limit permissions, etc. its just easier to do.

SQLite is great for local apps that need a structured way to store their data, but I'm not really comfortable using it for more than that.

Hey, if people are going to go back to reading manuals like we're in the 1980's again is it such a bad thing? /s

It's insane how a single tool managed to completely destroy the value collectively created by people in over a decade.

I can think of four aspects needed to emulate human response: basic knowledge on various topics, logical reasoning, contextual memory, and ability to communicate; and ChatGPT seems to possess all four to a certain degree.

LLM's cannot reason, nor can they communicate. They can give the illusion of doing so, and that's if they have enough data in the domain you're prompting them with. Try to go into topics that aren't as popular on the internet, the illusion breaks down pretty quickly. This isn't "we're not there yet", it's a fundamental limitation of the technology. LLM's are designed to mimick the style of a human response, they don't have any logical capabilities.

Regardless of what you think is or isn’t intelligent, for programming help you just need something to go through tons of text and present the information most likely to help you, maybe modify it a little to fit your context. That doesn’t sound too far fetched considering what we have today and how much information are available on the internet.

You're the one who brought up general intelligence not me, but to respond to your point: The problem is that people had an incentive to contribute that text, and it wasn't necessarily monetary. Whether it was for internet points or just building a reputation, people got something in return for their time. With LLM's, that incentive is gone, because no matter what they contribute it's going to be fed to a model that won't attribute those contributions back to them.

Today LLM's are impressive because they use information that was contributed by millions of people. The more people rely on ChatGPT, the less information will be available to train it on, and the less impressive these models are going to be over time.

DMD is the reference implementation as far as I know, so I don't think they have the same issue that C and C++ have with regards to needing to have a standard that pleases everyone. I agree that it has an issue positioning itself relative to other languages, but to me D is the good kind of boring. It has most of what you need, there is very little that is surprising in it, if you find yourself needing to do something, probably D has an easy-ish way of doing it.

There can be a universal language in theory, but it's borderline impossible to achieve. Every domain has a different set of problems that it needs to solve, and language design involves tradeoffs that may make sense for one domain but not another. That's why I think language wars are silly, without context it's impossible to say which language is "better", because you could have different answers depending on what you're trying to do.

In the end you shouldn't be too concerned with it. There are lots of languages, but all of them fall under two or three paradigms where if you learn one language from that paradigm, your skills are mostly transferable.

I completely understand where you're coming from because I very much used to be very much the same way. Problems like this can be frustrating because you feel like you're wasting your time, youre telling the engine the right thing but its not working and you feel like it's taking time from other problems you could be solving.

My advice: go easy on yourself. Write down all the other stuff you have to do so you dont forget it, and give yourself time to focus on that specific problem to see how you can solve it. Dont look at it as something blocking the other stuff that you have to do, look at it as just another task in your project.

In the case of the Z axis issue, take a step back and start reading about the Z axis and how it works. Create a separate project and start playing with it to see how it works for yourself. Convince yourself that this feature is not broken, and if you still can't make it work on a simple project at least you'll have reduced the problem so that if you ask for help online, it's more likely someone can spot the issue and tell you where you went wrong. If you do manage to make it work, at least you'll have something working to compare your original code with and make it more likely to spot the problem.

What differentiates an experienced developer from someone who's learning, is that an experienced developer has already ran into and solved a ton of small problems like these. It's a hurdle you need to overcome if you want to become effective at developing games.

I went into this with an open mind, then I saw the rant about error handling and I closed the article immediately.

Rusts error handling in combination with eyre/anyhow is the most pleasant error handling I have used in any language. You know exactly which lines can return errors, you can very quickly propagate them and attach context so that you can quickly troubleshoot later on, and it's completely natural and unintrusive. No figuring out whether you already logged the error somewhere else, no inconsistent handling of them, it's one library that does everything for you and you never have to think about it.

The go example is comparatively awful. You are forced to handle the error at each stage, and it runs into the same problem as exceptions where you're not really sure at which point you actually handled the error among other things.

When you're at that point, it's usually a sign that you need to start applying what you learned. There are two parts of programming:

1. The concepts, the theory which is honestly the fun part.
2. Dealing with the little annoyances, setting up a development environment, learning APIs, wiring things together, running into problems there is no clean solution for and implementing something that works.

The second part feels unimportant, something you can always learn later, but it takes time to learn and get good at, and what you need to learn to start to effectively apply more advanced concepts. Otherwise you're learning things you won't be able to use.

If you wanted to introduce every industry best practice in an intro course you'd never get to the actual programming.

It would be good to have a 1 credit course(one hour a week) where you learn industry best practices like version control, testing and stuff like that. But it definitely shouldn't be at the start.

It's really a question you should be asking someone in your company. There is no general answer to this question, and every company has it's own reasons for doing something like this. It could be that the CTO is a moron and wasting engineering time chasing a fad, it could be that staying on Java presents some sort of risk to the company, it could be that Java simply isn't a good fit for the problems the company is solving, there are a million reasons for doing something like this. It doesn't necessarily mean that Java is bad, just that Java isn't really fit for the company's purpose.

A good language matters. A good type system matters. A good use of a good language with its type system, patterns, abstractions, ecosystem, and all it got to offer matters.

Eh research shows otherwise. Rust eliminates defects for a very particular set of problems, but when it comes to logical correctness it isn't better or worse than other languages. If those problems are prominent in your domain(such as you have to write a ton of concurrent code), Rust makes sense. Otherwise being well rested will have a bigger impact on the quality of your code than the best type system in the world.

In terms of dev practices, the only practice demonstrated to have a consistent positive impact on code quality is code reviews. Testing as well, but whether it's TDD or other kinds of testing doesn't really matter.

Sorry about that, it seems I unintentionally created a bit of controversy and am being a bit defensive.

I mean if youre going to think of it that way any Turing complete language fits the bill, but what I mean by universal is a language you would reach for to solve any problem you have and it would be better than any other language. It's not a computer science problem it's a software engineering problem.

The fact that you have to operate a VM on your machine in order to use it is a no go for me. Either use Linux as your OS in that case, or spend the time to make a dev environment that actually works. Even just mounting a directory is a painful exercise, and something that comes with performance limitations. I've had to deal with networking problems, drive problems, all sorts of issues that you really don't want to waste your time fixing when you have a deadline coming up.

Multiple levels of virtualization, meaning you have the containerization part which is virtualizing the userspace of the VM, and the virtualization of the VM itself. Your development environment consists of multiple layers of complex, not to mention fragile technologies which is an incredibly bad idea for something you rely on heavily for your day to day work.

The people I know who have to use it run a fully fledged Linux VM and do all their work on that. That is how bad the developer experience is on Windows.

Also I'm a bit insulted that you immediately assumed that I'm speaking from a lack of experience, as opposed to years of experience supporting docker dev environments on windows and failing to find a solution that doesn't come with severe drawbacks.

This works great, assuming you're using Linux. On Windows this kind of a setup is a nightmare to maintain, since if something goes wrong you have to troubleshoot through several layers of virtualization and weird OS integrations to understand what's happening. Venv is a much better solution for that.

Regardless, I don't see it as something that is the silver bullet that people make it out to be. Being able to introspect the production database, query it, and generally have a set of tools to properly manage your data as opposed to having everything in a file fully managed by your application is something useful for me that you lose with SQLite.

The difference is that you can't have a generic mechanism in Go for error handling. It's basically up to the programmer, and every if error != nil line is a potential source of bugs.