The biggest attacks literally come from botnets. There’s not a lot coming from infrastructure services precisely because these services are incentivized to shut that shit down. At most it would be used as the control plane which is how people attempt to shut down the botnets.
You realize these are two different companies right? If you’re saying “I’m an AWS customer with cloudflare in front” I think you’ve failed to realize that two 99.9% available services in series have a combined availability of ~99.8% - that’s just math.
Your physical servers should have similar issues if you put a CDN in front unless the physical server is able to achieve a 100% uptime (100% * 3 9s = 3 9s). Or you don’t have a CDN but can be trivially knocked offline by the tiniest botnet (or even hitting hacker news front page)
I do. But I put both into the "cloud offering off-prem for very much money" shoebox. I setup a CDN once using VPS from different hosting providers for under 100 USD a month, which I would vastly prefer over trusting anything cloud.
And yes, I know that there's sites that need the scale of an operation like Cloudflare or AWS. But 99.9(...)% of pages don't, and people should start realizing that.
People who don't need that, also don't care much for an hour or two of service disruption. Most users will have far worse disruptions with the alternatives.
The problem is the value tends to be ephemeral and single use. Once the connection is established, the parties are better off communicating directly.
That’s why marketplaces like TaskRabbit struggle to generalize and grow. Contracting firms often struggle in similar ways and try to put clauses in their contracts to retain their relevance.
While I generally agree, the latest Android report suggests that rust developers get fewer reverts and code reviews are faster. This could mean that better developers tend to adopt rust or it could mean that rust really is a language where quality is easier to attain.
There’s some reason to believe that given how easy it is to integrate testing into the rust code base and in general the trait and class system is also a bit higher quality and it encourage better isolation and things like const by default and not allowing API that could misuse the data structure in some unsafe way. And it has a rich ecosystem that’s easy to integrate 3p dependencies so that you’re not solving the same problem repeatedly like you tend to do in c++
So there is some reason to believe Rust does actually encourage slightly higher quality code out of developers.
Or there are "reverts and code reviews are faster" because no one wants to actually read through the perl-level line-noise type annotations, and just lgtm.
> Or there are "reverts and code reviews are faster"
This seems like a slight misreading of the comment you're responding to. The claim is not that reverts are "faster", whatever that would mean; the claim is that the revert rate is lower.
Also, how would skimping on reviews lead to a lower revert rate? If anything, I'd imagine the normal assumption would be precisely the opposite - that skimping on reviews should lead to a higher revert rate, which is contrary to what the Android team found.
What type annotations? In Rust almost all the types are inferred outside of function and struct declarations. In terms of type verbosity (in the code) it is roughly on the same level as TypeScript and Python.
Does anybody here know how that's implemented, and what the difference is to this (if any)?
I lost track of all the methods (current and past) to block ads via browser extensions. Which of the two, if any, use "declarative blocking"; which inject JavaScript (and by extension require trust and site access permissions)?
I’m not a D programmer but I remember talks by Alexandrescu where he was arguing for this capability in C++ and ultimately one of his stated reasons why he switched from C++ to D
Look up static if - AST manipulation in native D code.
Now it may take you a while to figure out if you've never done Rust before, but this is trivial.
Did you perhaps mean simultaneous partial field borrows where you have two separate functions that return the name fields mutably and you want to use the references returned by those functions separately simultaneously? That's hopefully going to be solved at some point, but in practice I've only seen the problem rarely so you may be overstating the true difficulty of this problem in practice.
Also, even in a more complicated example you could use RefCell to ensure that you really are grabbing the references safely at runtime while side-stepping the compile time borrow checking rules.
Do you see catching up on performance with v8-jitless as a goal or is conformance the primary goal right now? Any plans on doing a JIT? I was always impressed by the idea of Truffle where you implement the language semantics once and you get both interpreter and JIT safely out of it which is a huge source of vulnerabilities in traditional JIT systems
Hi, I'm another one of the maintainers on the project.
In general, we are shifting more to performance now than conformance. We currently sit at around 94% conformance, so there's not really that much more to go conformance-wise. The remaining conformance gains are a couple of the newer specification features and Intl related features. Our current conformance can be found at https://boajs.dev/conformance.
Regarding performance, we are already making some gains, with hopefully more to come. The best example of this was probably the updates to script-bench-rs with our most recent release (which can be found at this commit https://github.com/khvzak/script-bench-rs/commit/d9635de77d2...). We still obviously have more to improve on, but we have already made some pretty steady progress from where we were.
EDIT: I forgot to answer your question about v8-jitless. Obviously in the future it would be nice to be able to be more competitive with v8-jitless, but at least for me, I'd just like to focus on improving the Boa overall.
Long answer: first, `fetch` is a runtime feature, and Boa is first and foremost an engine. So `boa_engine` -- the core project crate -- does not support `fetch` out of the box.
That being said, we do have a `boa_runtime` crate. This crate is not currently a full runtime, but it is a collection of runtime features that have been implemented and can be registered onto the context. `fetch` is one of the features that has an implementation completed in `boa_runtime`, and it does use reqwest if I'm remembering correctly. If you're interested to see some example code of registering features, you can look at our CLI code as an example :)
The past year has been huge for conformance for us, not only we caught up with the top engines but we surpassed them when working on Temporal and having all tests pass for that.
We hope to wind down some of the conformance priority now and focus on performance, we need to work on a new GC, refactor some parts of the engine, and improve various areas.
The idea of a JIT has been raised and we’re not against it, but it’s not on our plans right now (because of the above), that being said there is an open discussion.
You might want to look at the way the BEAM guys implemented their JIT in a slightly simplified and less performant (but obviously in way that is easier to reason about and extend and build upon) should you go down this road! Interesting project, I will take a look.
Right now, we use a forked and modified version of the `gc`. We definitely need to update it. Admittedly, I've been hoping to work on it but got a little distracted with temporal ...
I don't think I've actually heard of rsgc before. It's definitely interesting to see playXE put it together. I know that they'd been working on starlight at one point, so it'd be interesting to see takeaways from it.
To get to your question on the existing GCs, so far the answer is we don't truly know. We really need to do some GC experiments and test different options in Boa with JavaScript. There are not really that many GC crates out there of which I'm aware. There rust-gc's `gc` crate, dumpster, and `arena-gc` (tack on rsgc). But of those, the `gc` crate truly has the best API that we've used in Boa, but the performance is not ideal amongst other optimizations. It would be nice to preserve that API while improving the performance as well. But that remains to be seen.
I have no experience with them. In any case, it would be advisable to make the GC implementation swappable so that the language is gc-implementation-agnostic.
reply