olliej · HackerTrans

vor 3 Jahrendiscuss

Ah, it seemed from everything he said and did that he's the kind of person who actually believed that he couldn't possibly go to jail.

olliej

vor 3 Jahrendiscuss

No, the problem was the overwhelmingly abundant recorded evidence that also supported the credibility of the many witnesses even though they had plea agreements. In no part of his life has there ever been anything other the copious amounts of money. He could get on bail of 250M, and still broke conditions. This is before you consider where all of the money he stole went.

His defense was always fighting a losing battle here, and likely would have recommended he also try to get a plea deal rather than forcing a trial with this probable outcome.

olliej

vor 3 Jahrendiscuss

V8 provides a JS runtime.

Node uses the V8 C++ APIs to add additional functions and objects to that runtime.

So Node has a specific JS runtime environment, just as browsers have a specific JS runtime environment (and Workers have another), etc.

All of these environments are extending the runtime environment provided by their underlying JS runtime, they're not all providing their own stdlib implementations, they're not providing their own implementations of arrays, objects, global object, etc.

olliej

vor 3 Jahrendiscuss

You're right an interpreter is not a runtime. However V8, JSC, SM, ... aren't just providing you an execution engine. E.g. they are providing all the core objects, APIs, etc that are equivalently provided by the "Visual Studio Redistributables for C++" which you seem happy to call a runtime.

The lack of direct IO is irrelevant. You can take any of these libraries, and execute arbitrary JS, and then display the output (Serenity's spreadsheet uses LibJS for equation cells IIRC). E.g. JS that runs and uses the "runtime environment" to do things.

Your particular use case may benefit from exposing some additional APIs to JS, and all these libraries allow you to do that. But exposing, for example, printf to a full JS runtime environment does not mean you've made a runtime. The belief that for something to be a "runtime" it must have built in IO routines me that no generally usable scripting environment could be a runtime.

olliej

vor 3 Jahrendiscuss

V8, JSC, etc have an interpreter (or JIT, or what have you), but they also include everything else: the GC, the standard library, the standard and core objects. e.g. the full runtime.

Adding a couple of functions to an existing runtime is not rolling your own runtime.

olliej

vor 3 Jahrendiscuss

> Specifically, a runtime (IMO) is the set of variables and their associated functionality that exist in the global scope, or are expected to be importable in a predictable and standardized way.

All of which is provided by V8 in this example. The global object, math object, "Object" in general, Arrays, etc are all the runtime. All this tutorial series on embedding V8 is doing is instantiating an existing runtime environment and adding using the APIs to insert a few new APIs.

All together you might say you've got a custom runtime as you have the baseline "JS runtime" + some new APIs and that's clearly a new runtime environment that is distinct from the JS environment on a web page, vs. the one in a worker, vs. in node, etc. But that is at best "extending a runtime", not "rolling your own".

Using the embedding APIs provided by a JS runtime as documented and intended, is not "rolling your own". By that definition I could make an app, embed a WebView, and claim I rolled my own browser runtime, which I would hope is more clearly absurd. Or I could "roll my own Command-line" by reading a string from a user, prepending some commands, and then passing it to system().

olliej

vor 3 Jahrendiscuss

No.

The runtime is the combination of the execution engine, the garbage collector, and the environment.

V8, JSC, SpiderMonkey, LibJS, etc all provide all of those.

They all have APIs that let you (the embedder) a few new objects and functions, as it would be a useless embedding API otherwise. But that's all you're doing: adding some glorified callbacks to an existing runtime. You are in no way "rolling your own JS runtime".

To break it down:

Execution Engine: the part of the runtime that evaluates JS, an interpreter, jit, or some combination. That would be "Ignition" and "TurboFan" in V8, "LLInt" and "FTL" in JSC, "WarpMonkey" in SpiderMonkey.

Garbage Collector: the part of the runtime that supports object allocation and reclamation. "Orinoco" in V8, but not sure if given a separate marketing name in other runtimes.

The environment: this is all the builtin objects and functionality, things like the global object, the regex engine (note it's not a regex runtime because all it does find the start and stop sections of matches, the embedding environment is responsible for everything else), all those core things like the Object, Array, Math, Number, etc types, and all of their implementations and runtime functions. The Execution engine does not need any of those to be implemented, as to the engine there is essentially no distinction between those builtin things and anything else written in JS.

When you embed V8, JSC, LibJS, etc you are getting a full runtime, that can do a huge amount. You _might_ choose to use there APIs to add some new objects or or functions, but what you are doing is negligible, and certainly not "a runtime".

olliej

vor 3 Jahrendiscuss

This is not any kind of "rolling your own JS runtime". This is "use our framework to use v8 from rust". What an obnoxious title.

v8 is a JS runtime. JSC is a JS runtime. SpiderMonkey is a JS runtime.

All of these are embeddable and have usable APIs. If all you are doing, is linking to a JS runtime, and then using it, you aren't "rolling your own runtime".

If you want to roll your own JS runtime go look at how the LibJS folk in serenity did it - they did it without corporate backing and despite that I believe LibJS is fairly complete even with the new draft language features, albeit lacking a decade or so of performance optimizations.

olliej

vor 4 Jahrendiscuss

yes, I said it's standard webdev laziness.

Many aeons ago I worked on webkit, and the first step for a great many site compatibility bugs is "does it work with a Firefox ua string".

Because it is always easiest to just check ie/new-ie and then useragent gate everything else, that is what happens. Which is why we keep getting sites requiring chrome (new ie) or ie (old ie) - it doesn't matter if the site is broken due to reliance on chrome behavior vs spec, what matters is devs coding to a single browser and considering any deviation to be a bug in anything else.

olliej

vor 4 Jahrendiscuss

Yeah, all browser developers have tried to essentially freeze the UA, if nothing else to stop keying site behaviour off random subsets of it. For example here is my UA:

    Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.2 Safari/605.1.15

Which is all sorts of frozen (old os version, intel on an arm device, etc)

olliej

vor 4 Jahrendiscuss

No, it's just standard web developer laziness. They haven't made it IE only, they just broke the less popular browser, and likely anything else that is not chrome/blink, because chrome/blink is the new IE: its bugs define "correct behavior" it shipping something means "it's standard", no different from the "IE is the internet" era (and just like chrome there was a long period where IE was the best browser, before devs started targeting it alone).

olliej

vor 4 Jahrendiscuss

I thought Fuchsia was going to be their secure OS, and I actually worked on it... I guess not?

This is like a really dumb version of the 90s era MS competing teams nonsense. All I can see is it burning out a lot of really talented engineers.

olliej

vor 4 Jahrendiscuss

While this is true, and I'm generally fairly anti-chrome, this does disregard a huge amount of very real, and very hard engineering work.

I think V8 was not actually that complicated - a lot of the "deep" computer science they originally wrote and talked about in marketing material was from the 80s, and things like the hidden classes were picked up almost immediately by JSC at least (as in just a few weeks of non-crunch time). The original JITs for V8 and subsequently JSC were essentially template JITs, i.e not particularly complicated (for JSC the big issue was having to support x86, x86_64, and Thumb2, and managing the security implications on iOS). Even the GC imo wasn't super impressive.

The primary reason that Spidermonkey and JSC didn't have the JIT or hidden shape concepts wasn't engineering complexity, but simply that at the time the apparently important perf problems were with other parts of JS and the DOM - so huge numbers of objects (the argument for generational GC), and non-dom property access (which recall was not optimized in V8 at the time) were just not considered that important compared to other parts of JS and the browser.

But when you get to WebCore and the browser the Chrome folk did a lot of very hard work, the process separation was also conceptually simple, but practically a huge amount of very complex work. You can contrast the difference in time it took to get JS engines performance up to the same order as V8 vs the time it took any degree of process separation in WebKit and Gecko. The first multiprocess Safari was just two processes, the app, and the render process - just getting WebKit going with a single separate render process was a lot of work, it was at least two full releases before true multiprocess was a thing in WebKit (WebKit's multiprocess model makes the process separation part of the engine, vs. the blink model of having the app be responsible).

Then for sandboxing, WebKit obviously got to leverage the Mac+iOS sandboxing that was built into the system. The chrome folk had to build an entire sandboxing system for windows, without kernel support, or in fact any support. Which was another gigantic amount of work.

So kudos to the chrome team, they did a lot of work, and a lot of it was very hard, and shouldn't be reduced or dismissed.

olliej

vor 4 Jahrendiscuss

Seniority doesn't mean "senior", it's a product of expertise. Obviously there is a strong age correlation because generally going up seniority ladder is going to correlate with time at company, and domain knowledge/expertise is going to be correlated with time spent work in that field.

But I know plenty of people my age (my vintage? :D) with higher and lower seniority, similarly I know people older, and people with more time at the company in the industry with substantially lower seniority, and vice versa.

But also the companies I've worked at (FAANGs, so obviously large) don't treat "seniority" at the IC level as giving some kind of priority over lower seniority ICs. Obviously seniority factors into "how reasonable/accurate is their opinion" but that has never, in my experience, been a blanket override of lower "seniority".

The primary real difference is compensation, which is why companies like to get rid of senior engineers. I assume for a competent company they're doing a trade off "how much do they cost vs. how much value do they add", but obviously where we see this is always poorly managed "get rid of all the expensive people, WCGW" policies.

olliej

vor 4 Jahrendiscuss

I really don't understand the "sprints" approach to development - I've never worked on any project where it makes sense, either the things I've been working on take less time than a "sprint" or they take longer, and that's for any sprint length you can produce.

Real software requires some degree of planning, and sprints seem to be more an attempt to avoid that planning. I don't mean to the level of gantt chart hell (I've experienced that as well).

Sprints, at least as they actually occur in the real world, seem to actively harm any large scale projects, and increase the overhead for long term projects if you can get them to fit.

olliej

vor 6 Jahrendiscuss

Am I getting this right?

Irrespective of whether you use any other google products, if you use chrome google can now track you over any property that uses google ads, recaptcha, etc.

The header is inserted by the browser after any extensions run, and google pins google properties so you can have an intermediate proxy that strips the header, so they gain persistent tracking of all users across most of the web?

If it wasn’t a tracking vector why do they limit it to just google ads, etc? Why not other ad providers as well?

olliej

vor 8 Jahrendiscuss

JSON.parse already supports that through the reviver parameter.

olliej

vor 8 Jahrendiscuss

The spec breakage is that you’d need the n suffix to indicate it’s a bigint.

olliej

vor 8 Jahrendiscuss

But you can't determine (without a suffix) whether a number you encounter is a BigInt or a floating point value that lost precision so doesn't have a decimal point.

comments