Pope Francis used to work as a Chemical Technologist before becoming a priest. That must have something to do with it.

I understand, but this is not a common case scenario, and more like a rare situation.
It is also not a problem exclusive to GDScript, and might still happen with C#, C++ and other languages.
So, given in far most cases the situation you describe does not apply, using a custom language in this case seems more like "using the best tool for the job " principle.

Torque is shit, Gameplay3d is basic at most, Ogre3d is a renderer not an engine.
Unity and Leadwerks are not opensource.

I had the "pleasure" to port Torque3D to PSP, so I know it inside out. Torque is (sorry for the strong words) a pile of shit, it has always been a pile of shit and it will always be it.
It was opensourced because it failed as commercial offering, developers did not want to use it back then and that fact will not change even if you offer them money.

Except the above mentioned have several problems:
-They are dog slow because every indexing is a lookup in a hash table.
-They don't have proper multi-thread support (with ability to share context between threads), this is essential for videogames. They either not support it or have a global lock.
-They do not support vector types natively (Vector2,Vector3,Matrix2,Matrix3,Matrix4,etc) which are also essential to video games (and binding as usretype is really slow)
-Have terrible means of GC, which are also not designed for video games. GCs usually "stop the world" to work, and when they are run incrementally they can leak memory without the user noticing. Even Unity has problems with this with C#.


Why is it so difficult to understand that Godot has created a custom script language to avoid the problems mentioned above, because the "existing languages" everyone suggests are not designed for videogames and real-time?
Is it so important to use an existing language, even at the cost of poorer performance and worse integration?. GDScript also tries to be as similar as possible to Python, to ease the transition.

It's fair. Godot is not written in Java.
Seriously though, I have used JMonkeyEngine and it is sort of hit and miss. Godot architecture, features, platform deploy, animation tools, etc. are a lot more mature, please give it a chance when you have time.

The same as with this story: http://hardware.slashdot.org/s...

I fail to understand why do they spend so much time using robots, while modern physics engines can do these kind of simulations infinitely more efficiently and at a fraction of the cost and time.

MP3 players, Smartphones, etc. Apple did not invent them but succeeded into making that technology widespread, convincing people that it was harmless and that they could interact with them, until it became part of their regular lives. Let's hope this announcement helps do the same with relationships of the same gender.

Exactly, but it's not workers who determine what an acceptable market wage is but companies. Otherwise if there were only 5 capable guys in X field in the US, and 20 outside, you could also argue that there is no shortage either with the same argument because they really are worth as much.

This is why I say, there IS a shortage, the problem is that some people does not want to stop being paid high wages.

The shortage of skilled workers in IT is a real problem, this leads to wages being high for those with ample experience in the field.
The fact that companies can't get a hold of them due to elevated cost of the hire, makes them resort to H1B. Foreign workers, in turn, will gladly work for a low payment in exchange of a better standard of living. This is wrong.
Just allow skilled foreigners to immigrate normally, and don't give control over their stay to companies. This way everyone will play on an even field and the whole industry benefits.

If you ask me, I think this should be handled in-kernel for may reasons:
1) You need a process running SCHED_FIFO all for sound otherwise. This is OK but you are still at the mercy of the scheduler when you poll.
2) Letting this happen in userspace resulted in several competing APIs and no standard over more than a decade. While for toolkits this is not serious, for audio this is, because the competing APIs require exclusive access to a resource.
3) Resampling, at the best quality and even in a real-time audio process is extremely cheap, and you only need to do it for a single stream.

Which is what my OP is about, what you suggest we've been there, done that and failed. This is simple functionality that should be handled in kernel with a simple API presented to userspace.

This is not really a problem because, even if you wanted to use the most expensive interpolation possible, you can resample your lower-priority audio outside and feed it through a lock-free ringbuffer. This way the deadline constrained realtime audio has no penalty in practice.

Both Windows and OSX handle real-time audio in the way you mention, so you can have something like Jack and system sounds at the same time. OSS from 4front does this same thing.

The problem is that, for this to work, you have to open audio in real-time with the best possible combination of parameters, and this might involve resampling or dithering audio from lowest bit depth or sample rate. The kernel does not support using floating point code, so integer math needs to be used for the resampling.

Despite that most commercial hardware has for ages used fixed point math for this, and that even a simple spline interpolation would do fine for all cases since you are upsampling, most of the "audio gurus" of the linux audio development comunity of the time (like Paul Davis, Steve Harris, etc) convinced the kernel people that there would be a terrible quality loss and it was a bad idea to do this.

So, the situation of the linux kernel audio is one of those situations when instead of designing by use case, it was designed by designers that would prefer a "clean" solution instead of a practical one (that Commercial OSs and hardware implemented).

4Front OSS, which was later opensourced, could mix both low latency and high latency streams, and the API was *much* simpler and unix-like.