Oh, it's happened quite a number of times...

Have they really though? They may bump old threads and restart the discussion but have they ever made good threads?

Don't see why not.

As for the type language for structures, depends. If it's simple stuff i'd do C (I particularly dislike C++, but love D). Though it really depends on what type of data you are having and matching the language.

Neither do I.

I was just responding to Shadowstalkers16's comment about bot created topics being turned into useful topics, and that it has happened before...

While not really involved in programming language theory, I would surmise that eliminating all possible cases of memory leaks might not be possible for a general purpose programming language. They can definitely make it harder though.

I think that's a stretch to put all garbage collected languages in the same basket in terms of performance.

While there are some real-time cases that require fine-tuning of memory management, there are worlds of difference between the performance of Python and Golang.

For example, I don't think etcd (a project implemented in golang) could feasibly have been implemented in Python.

Fair enough and I guess that would certainly explain why so must of the bastardisation of the language came from that crowd. People who worked with Javascript in the backend did so by choice and liked the language as it was well enough.

Well, this is second hand as I never partook, but I've heard (and I don't have a hard time imagining) that Typescript is a leaky abstraction over JS. You need to be proefficient both in JS and Typescript (in contrast with a compiled language where you don't need to know assembly), but also, because you are reliant on Javascript (and all its ecosystem) which isn't typed, typing in Typescript can be quite funky and not as dependable as a compiled language that goes directly to assembly or to its own abstraction specifically made for the language.

Also, you are giving up the ability to execute a script as is without any extra processing that interpreted language typically have (and which is often an underestimated perk of interpreted languages btw), and yet, you gain none of the performance improvements of a true compiled language nor its possibility to run as a small self contained binary.

Also, the tooling you use to transpile is not a universal standard the way a compiler is for a compiled language and each place has their own "homemade" (ie, hot mess) setup to transpile their stuff in typescript and I've seen many a frontend tech lead spend the day to fix "their setup" because the transpilation is breaking.

In my opinion, if you are using Typescript by choice instead of a compiled language and it isn't because you are in the browser or there is a super hot library in Typescript that just makes a world of difference for the particular problem you are trying to solve, you are using an inferior alternative.

You can by eliminating all dynamic memory allocation.

Worth noting that memory leaks can occur in garbage collected languages. It is possible for data to still be reachable, but not actually accessed that way. (For example, put every new node into a list, but never remove it from the list, even when done with it, and keep a reference to the list around somewhere.)

Golang may have better performance than Python, but it still has some similar properties; in particular, worst case performance (when garbage collection occurs at a bad time) is still much worse than average performance. Hence, I still wouldn't use either language for hard real-time (for example, if failure to get something done in time would result in a crash).

From a perspective of learning data structures, garbage collected languages are basically equivalent (unless, say, one of the languages has a fundamentally different programming paradigm, like if you throw in some Lisp dialect in there).

Deno (an alternative to node.js) addresses this by integrating the typescript support into the runtime.


Bun (yet another node.js alternative) does the same.

I think that would greatly reduce the usability of the language though.

Yes, exactly. That's why I'm skeptical that it is feasible to eliminate all cases of memory leaks.

I believe that would require accurate extrapolation of a programmers' intent from the code (something a human can do, but anything short of an AI can't).

Well, I don't think you and I are working on the same kinds of software. I tend to work with networked software a lot, where realistically, there are milliseconds delays during network hops and things that happen within a fraction of a second are acceptable.

What I can tell you is that a store like etcd, which is written in golang, can support 10k concurrent writes per second, which is enough for the overwhelming majority of our operational use cases and to run a kubernetes cluster on (and the worst case performance for those requests are still a small fraction of a second).

Would it deliver the same throughput if it was implemented in Python? Very doubtful.

If you do a lot of btree processing for a database, I guarantee you that golang will do it faster than Python.

Here are some benchmarks (the difference is quite ridiculous): https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go-python3.html

Sure, it would be even faster in rust/C/C++, but there are tradeoffs to consider:
- For many of our use cases, Golang has the better ecosystem support (ie, richer integrations with other stuff we use)
- Go is a better sell with the team, because it has a small learning curve
- Go is faster to develop in and we have deadlines
- Given the above and the fact that the difference between rust and go are not as drastic as between go and python, there are diminishing returns to consider

Yes, that at least addresses the standardization problem (ie, one elegant universal tool to do the job), but it still transpiles to JS instead of assembly (or some bytecode better adapted to the source language) and thus the other limitations apply.

Actually, I believe the creator of Dano even expressed some regrets about making it for typescript.

Unless someone manages to make Typescript render to a lower level abstraction (ex: assembly) and then divorce the language from Javascript completely, I think it is doomed to be a passing fad (very intense one, but a fad still).

At this point, all the run times (browser engines really) have years of optimization in JS so that might take a while, if it ever happens. Should it happen, maybe I'll give it the time of day, but until then, I'd rather invest my limited time mastering better more well thought of tooling that are not a knee-jerk reaction to what a language it is based on and heavily coupled with isn't.

If we game the Python version significantly more powerful hardware than the Golang version, then they would have the same performance, and would have similar performance properties.

The thing is, real-time is not the same as raw speed. In your use case, millisecond delays are expected. In a hard real-time situation, on the other hand, millisecond delays could be catastrophic.

For example, if you're generating sound and immediately playing it back, and the sound isn't being generated fast enough, the result will be audible, and it won't sound that good, even if this only happens briefly. For example if, during audio generation, a garbage collection cycle is triggered, that can cause audio to not be generated fast enough, and there will be an audible "pop" in the audio at that point, and we don't want that, particularly if you're trying to produce music. (One typical solution is for the audio code to run in its own thread, in a language with no garbage collection, and with realtime priority.)

Or, you could have software that controls safety critical hardware. A failure here could be catastrophic, resulting in property damage, or worse, loss of human lives. (Before you say that's ridiculous, look up the THERAC-25, which killed people via radiation overdose because of a software bug.) If you have a hard real-time constraint here, you can't afford *any* unpredictability here.

The important point: Real-time is not actually about speed; it's about predictability. What's important here is not that the task gets completed (on average) as fast as possible, but that it gets consistently completed in under a certain amount of time.

By the way, there is one very common soft real-time situation that comes up in many types of software, including web applications; the user interface. If the user clicks on something, and the computer doesn't respond fast enough, the user will think that it's not working. I don't remember what the actual time constraint is, but it's definitely a soft real-time constraint. (Note that it's OK if the entire action takes longer than that; it's just that the GUI needs to respond, in some way, within the time limit or the user will get frustrated.)

But Rust's performance is more predictable, and sometimes that is what you need.

Sure, more hardware is always an argument when you have something that is slow, except that Moore's law has cooled off a lot and while governments allocate a lot more budget to hardware than to manpower to operate it (hence why you have two guys here operating hardware equipment worth millions and until recently before that, it was one guy), the budget for hardware is not unlimited and also, when you scale hardware vertically, the increase in cost is not linear with the increase in capacity (ie, at some point, it becomes ridiculously expensive to buy better hardware vertically).

Some solutions like mongodb will scale well enough horizontally (assuming you are smart with your shard keys) if the nature of your queries scale well horizontally also (most tend to). Other solutions like a postgres and etcd cluster, not so much so you need to make your hardware count (and you can go a long way with those solutions even though they don't scale as well, because they are implemented efficiently).

Sure. As I said, we work on different kinds of problems. If milliseconds delays are unacceptable, you pretty much take anything networked out of the equation anyways (which is what I tend to work on).

However, there are many categories of applications where reasonable differences in latencies are not an issue, but that doesn't mean that performance doesn't matter.

Agreed, though I'll add that speed is still an impact. If things take predictably 1 second to respond with a minuscule margin of error, its probably not good enough for most real time domains.

Completely agree and this is why I'm learning Rust.

High-frequency trading is an example of a networked hard real-time problem. If it takes too long for a stock trade to occur, money could be lost.

Online multiplayer gaming is an example of a networked soft real-time problem, assuming the game is real-time and not turn-based. If the packet doesn't reach the other player in time, it is effectively lost, as the situation is no longer relevant. Streaming of video or audio is another one. (One interesting characteristic of these problems: If it takes too long for a packet to arrive, it might as well not have been sent. Hence, the advantages of TCP (reliability and reliable ordering of packets) are not present here.) (Note that, for a turn based game like Civilization 3 or Pokemon, the situation is very different, and you don't have the real time constraint here (aside from having the UI react to player input, but that part doesn't involve the network).

I would start with C, working through a book like https://en.wikipedia.org/wiki/The_Practice_of_Programming

Then move to Rust. It's the flavour of the month.

In this case, before you move to Rust, make sure you understand why you get segmentation faults in C and what causes it. Also, I would wait until you've actually had to debug segmentation faults in your own code.

(On Windows, segmentation faults are called general protection faults; it's what typically causes the "this program has performed an illegal operation window" dialog to pop up.)

True, the stock market is another animal in itself and something I know remarkable little about. My guess is that they must have strong locality requirements to make it work.

Unless you're paying a fortune, such guarantees are hard to make over the internet.

I think for the usual game happening over the internet where you have latencies in the 10s of milliseconds realistically (more if you are talking inter-continent), I think that would comfortably drown any latency you get from garbage collection in a language where it is well implemented for a program that is well optimised.

Of course, you can have much better latency over LAN, but people don't seem to be doing that anymore.

I think people are often overblowing the performance impact of Python or interpreted languages for a lot of application domains, where it doesn't matter that much.

I think it is unsuitable for intensive system stuff, but I think a lot of applications are not doing anything special that would warrant the consideration.

I mean, most of them will leverage a database that is well optimised, leverage load balancers, network meshes, kubernetes and other lower level components that need to be well optimised and those components can't be implemented in Python, but most shops don't implement things like those, they just consume them.

The high level glue that puts all of the optimised components together and solve the requirements for some high level business application? Usually, that has much looser performance requirements.