Kind of how you'd say you have a dashboard for your business to see metrics in real time (as opposed to some kind of daily report).
I think that usage of real time is very common outside of a pure engineering sense, so you're being a bit of a stickler by being annoyed at this specific instance ;)
My Phoenix channels, your rails action cable, your web sockets: soft real-time.
Real-time was reserved for true real time guaranteed delivery times.
I think calling it a "streaming" or "live streaming" interface is a better descriptor than "real-time".
> I think that usage of real time is very common outside of a pure engineering sense
Maybe, but we're talking about the software engineering world here aren't we? I think we should seek to be precise with our terminology and try to avoid unnecessary ambiguity.
I think both uses of the term are acceptable in their different contexts. (But yes I also agree "streaming" is a very good term.)
The non strict usage is far more common then the term of art. One would be well advised not to assume "real time" is being used as a term of art unless specifically called out, or clear from the context.
I'd say common usage of the phrase "real time," means with respect to human perception, and that is how its being used here.
So do you consider YouTube a real-time system? After all, images are moving on your screen "in real-time" from the user's perspective.
It seems to me that these are all streaming systems, and when the data is "live", then it's "live streaming".
Even colloquially, I hazard that "real-time" has some implication that there's some correspondance between your temporal reference frame and the original temporal reference frame. I think the engineering definition just made that correspondance precise.
Yes people do say "real time playback" with respect to video. Generally, however, that is only noteworthy to call out when its unusual. Such as "real time 16k playback."
It's been 5 years since I've worked in that industry, but I still view the use of "real-time" the same way and can understand some people's issue with the term in this case.
I'm not calling out this person specifically, I'm just hopeful that we can use more precise terms instead of overloading existing ones. I think "streaming API" or "live streaming" is a better fit for these purposes.
The earliest computers didn't even include an operating system, never mind one with real time guarantees as we think of them today. You submitted your program on paper tape (later, punch card.) and hours later, you'd get the output. This was the batch computing era. The idea of getting a (soft) real time response from the computer (which was the size of a room), was unheard of.
As computers evolved, real time systems came to refer to computers that operated on the opposite of batch computing. The user could interact with the system in "real time", rather than having to wait hours after submitting the job for the results.
Later on came the distinction between systems with hard real time (vs soft) guarantees. Computers didn't have the same CPU speed that we have access to today, so even audio processing required special real time guarantees.
Eventually, "hard real time" was shortened to "real time", which takes us to today.
Systems which have existed since the dawn of computing such as banks back in the 50's, or the IRS, still hold onto the batch vs real time nomenclature, possibly because batch processing systems still exist. Banks still process records nightly in batches, some even still run on newer versions of the same IBM mainframes, though some are starting to move to "soft" real time systems. (If you ever wondered why it can takes days for a check or bank wire transfer to clear, this is why.)
Look, this is simple: literally all of our technical textbooks and engineering manuals agree on what "real-time" means.
If people were running around calling their smart phones "desktop computers", or "laptops", or "mainframes" you'd be very confused I think. Sure, smart phones and desktops these systems have a lot in common, even run a lot of the same code, and sure our phones have more computing power than mainframes back in the day, but overloading this term conveys literally no benefit and actually creates confusion.
Of course I'm pissing into the wind here, but whatever, if I've convinced even a couple of people to be more precise with their terminology, I'm fine what that.
As someone who grew up with those systems, this is a major mis-statement of the terms.
In the early days the terms were "batch", "online", or online's near-synonym "interactive".
Real-time has always meant bounded-latency and guaranteed execution since the earliest days, to actual computer systems engineers.
It is a true statement that many people use the term differently today - much to the detriment of precise communication between humans. But there was never any confusion about the term until perhaps the 90's and widespread interactive screen-based applications.
I view real-time as "the clients reflect the true state of the world without taking action." So if something changed the state of the world, all clients paying attention to that should also be updated.
That's a perfect description of "live streaming".
Medical data in one case, moving images and audio in another. The properties are the same in either case, that's why the term fits.
Saying context doesn't matter is just ignoring how everyone else uses language and saying that your view of it is right.
So now we have two terms referring to exactly the same thing, which doesn't resolve the term conflation problem I initially wrote about. The "web world" context isn't that different from the larger software engineering world that they should repurpose engineering terms.
> Saying context doesn't matter is just ignoring how everyone else uses language and saying that your view of it is right.
I am saying that web programmers do tend to use professional language wrong, that it's unfortunate, and that we should try to correct it when it happens. I don't think the first part is controversial, but apparently trying to insist on precise engineering terminology when talking about engineering systems is controversial.
This page classifies a broad definition for real-time and then breaks into different categories (hard, soft, fail-safe, fail-operational).
Is the default definition of real-time "hard real-time", or does it always need to be defined by its classification?
My point around context is that no one in the web world is saying that soft real-time systems are hard real-time systems. That would be blatant misappropriation of a term. They are saying that "real-time" defaults to "soft" in the web world. Just like "real-time" defaults to "hard" in the embedded world.
I don't know if I would classify this project as the embedded world (despite it using hardware), because it's consuming a stream of packets and isn't at the actual physical device level. I may be misunderstanding what they're doing, but I believe this to be the case.
The broader reason why I commented in the first place is that your comment feels like gate-keeping of a term when most people are going to quickly pick up on the context of how the term is being used. I understand and agree with your point around hard vs soft, but I don't think it's as clear cut as you seem to think it is regarding what the default classification is in different contexts.
Maybe you guys ought to call hard real-time "Guaranteed bounded latency" when needed.
Even in the dewey eyed early years, Go saw STW latency in the hundreds of milliseconds. By 1.8 it's in the hundreds of microseconds.
Your hard-real-time is out the window as soon as routing and UDP is involved. The intent is "real time bounded by the amount of time it would take doctors to react to a code blue (heart issue/failure". One second of reaction (thousands of gc's, dozens of health checks, a near eternity in program time) isn't going to make a difference when human reaction time latency is hundreds of milliseconds.
Call it "live streaming" if that sounds more objective, but conceptually if the clients (humans) don't perceive a difference in state, it's real time (to them).
Save the milliseconds-hard-real-time talk for rockets and cars.
https://blog.golang.org/ismmkeynote
https://www.reddit.com/r/golang/comments/aetba6/gcs_stw_paus...
Would love to see a worst case analysis for go though. (My worry is, that long running applications are more prone to extensive gc stw, since os starts to swap pages, and gc tries to access them, might take a while)
Of course if you can guarantee that go always has stw gc for less than a second (or even 10 seconds) that would be great (and make go a hard real time language, of course not a very fast one)
In my mind "real time" as a term of art applies to things like hardware control systems with very strict tolerances.
Although, as a hacking challenge I'd love to see the most catastrophic delay one could plausibly accidentally code into a go application.
"Real-time" is now being used for streaming APIs to mean "small latency on average, but no guarantees".