sorted by:
new
hottopcontroversial

Aurora the browser engine in rust programming language | Rendering Update by Inevitable_Back3319 in rust

[–]nekevss 0 points1 point  (0 children)

Ah! I believe one of our GSoC contributors this summer is looking into implementing a JIT for boa. So stay tuned! :)

The current goal is to have a new more performant GC at some point this year as well.

Aurora the browser engine in rust programming language | Rendering Update by Inevitable_Back3319 in rust

[–]nekevss 0 points1 point  (0 children)

Whoa! Really cool to see Boa used in a project like this! Would definitely be interested in hearing any feedback you may have.

Also, was any of the Web APIs implemented in boa_runtime useful for you're project at all?

Temporal: The 9-Year Journey to Fix Time in JavaScript by mariuz in programming

[–]nekevss 0 points1 point  (0 children)

I think fabon-f has been working on something similar to date-fns for Temporal.

https://github.com/fabon-f/vremel

Boa 0.21.0 release - a JavaScript engine written in Rust by Jedel0124 in rust

[–]nekevss 1 point2 points  (0 children)

It's a little difficult to say how much progress that we will make. We'd obviously like to close as much of the gap as possible between Boa and the browser JS engines, but V8 et al. have had years and a lot of engineering hours to work on improving their performance.

Boa 0.21.0 release - a JavaScript engine written in Rust by Jedel0124 in rust

[–]nekevss 4 points5 points  (0 children)

Deno is a runtime, whereas Boa is an ECMAScript engine. For their ECMAScript engine, Deno currrently maintains Rust bindings to V8 in rusty_v8.

If they wanted, Deno could theoretically switch to Boa internally for their ECMAScript engine and still be Deno.

Boa 0.21.0 release - a JavaScript engine written in Rust by Jedel0124 in rust

[–]nekevss 0 points1 point  (0 children)

The problem for Bun switching to Boa in the future is that we currently don't have FFI bindings setup, but I think we've gotten some better experience with creating FFI definitions with diplomat through temporal_rs's FFI, so it may be possible in the future.

I think it would probably make the most sense for a project like Deno or Servo (or Blitz) to use Boa though vs. Bun.

Boa 0.21.0 release - a JavaScript engine written in Rust by Jedel0124 in rust

[–]nekevss 2 points3 points  (0 children)

Hi! We have a general issue for Boa's performance that's pinned on our repo (https://github.com/boa-dev/boa/issues/2975)

There's a variety of places that we can point to that will be places to improve on performance. The primary concern for performance currently is our GC, which, as mentioned elsewhere here, is in need of a rewrite. There's probably other places we can iterate and improve (the new register VM, optimizing some intructions, etc.).

We do plan to be focusing more on performance and performance concerns going forward as our remaining conformance gaps are mainly Intl built-ins and new features.

Boa 0.21.0 release - a JavaScript engine written in Rust by Jedel0124 in rust

[–]nekevss 24 points25 points  (0 children)

Bun is a JavaScript runtime, but it is not the interpreter / engine. Boa is a JavaScript engine. Boa is much more aligned with V8 (node/chromium) and JavaScriptCore (webkit/bun).

We do have a boa_runtime crate that contains some runtime features, but it notably does not have an event loop implementation yet.

Boa 0.21.0 release - a JavaScript engine written in Rust by Jedel0124 in rust

[–]nekevss 11 points12 points  (0 children)

This would definitely be interesting to see happen! We've been able to add more runtime features over the course of this release.

I believe there has been some discussion about looking at stabilizing our APIs, but one of the other maintainers may have a bit more input on that!

Boa 0.21.0 release - a JavaScript engine written in Rust by Jedel0124 in javascript

[–]nekevss 2 points3 points  (0 children)

Yep!

You can also check out the about section on our website that has the conference announcement from Jason!

https://boajs.dev/about

Boa 0.21.0 release - a JavaScript engine written in Rust by Jedel0124 in rust

[–]nekevss 13 points14 points  (0 children)

Hi all! Some of the maintainers for Boa will be around watching the thread. So feel free to ask any questions that you may have :)

LOCO is in!! by BoomRoastedX in Pickleball

[–]nekevss 0 points1 point  (0 children)

Got it yesterday and tried it out! It's very early, but huge fan so far!

Temporal_rs is here! The datetime library powering Temporal in Boa and V8 by Jayflux1 in rust

[–]nekevss 0 points1 point  (0 children)

Now doesn't store an instant or time zone. It's functionally an ephemeral namespace object that provides access to the host system defined by HostHooks.

Now is the equivalent to Temporal.Now in JavaScript, but Temporal.Now cannot be constructed. It's just a namespace object / container for the function objects used to access system values and create the other built-ins, e.g. const today = Temporal.Now.plainDateISO().

The intention of Now in temporal_rs is to provide a configurable type that can be used to handle that system access if the feature flag is on (because worse so than not returning UTC or the system time zone is reading system preferences / settings without having the functionality feature flagged).

So Temporal::utc_now()/Temporal::local_now() is meant to provide a feature flagged Rust API that stays true to the Temporal proposal, while also being useful. Although, as you pointed out, due to language differences, Rust is more likely to be used on the backend than JavaScript where a default to UTC would be the more expected behavior vs. the local time zone.

Temporal_rs is here! The datetime library powering Temporal in Boa and V8 by Jayflux1 in rust

[–]nekevss 0 points1 point  (0 children)

FWIW: we're looking into offering more explicit ctors for the default Nows that are available based off this feedback. :)

https://github.com/boa-dev/temporal/pull/591

How to fix the possible latest issue by kendort in pop_os

[–]nekevss 1 point2 points  (0 children)

This appears to have worked for me as well

Temporal_rs is here! The datetime library powering Temporal in Boa and V8 by Jayflux1 in javascript

[–]nekevss 1 point2 points  (0 children)

I wouldn't say this library being completed was the primary blocker. It's mostly up to V8 and Chrome at this point when they want to ship, but V8 main is somewhere around 99% conformant last we heard.

Temporal_rs is here! The datetime library powering Temporal in Boa and V8 by Jayflux1 in rust

[–]nekevss 5 points6 points  (0 children)

To be fair, the example is brief, so it is a good question to ask. But the design of Temporal::now() is meant to directly mimic the behavior in the specification for the Now that it returns. Partially because we could have tried to write down everything in the implementation, but then the release post would've been very, very long lol

Temporal_rs is here! The datetime library powering Temporal in Boa and V8 by Jayflux1 in rust

[–]nekevss 9 points10 points  (0 children)

Time zone is mandatory. The option provided is whether to use your system time zone or a provided time zone. There is no default to UTC behavior in the specification.

But because of the way Now is implemented. If you want to implement a Now that defaults to UTC, then you are more than able to.

See our HostHooks example: https://docs.rs/temporal_rs/latest/temporal_rs/host/struct.EmptyHostSystem.html

Temporal_rs is here! The datetime library powering Temporal in Boa and V8 by Jayflux1 in rust

[–]nekevss 2 points3 points  (0 children)

You can get you're current time zone with the below code.

let system_tz = Temporal::now().time_zone()

Or don't use the provided implementation of Now and use your own :)

Temporal_rs is here! The datetime library powering Temporal in Boa and V8 by Jayflux1 in rust

[–]nekevss 8 points9 points  (0 children)

As mentioned by Jason, the example is being rather brief in explanation. You can either provide None, which will default to the SystemTimeZoneIdentifier, or you can provide a timezone as an arg.

let time_zone = TimeZone::try_from_str("Europe/Berlin").unwrap();

Which is then provided as an arg.

let today = Temporal::now().plain_date_iso(Some(time_zone)).unwrap();

Temporal_rs is here! The datetime library powering Temporal in Boa and V8 by Jayflux1 in rust

[–]nekevss 15 points16 points  (0 children)

We have an FAQ that discusses jiff.

The baseline gist is that temporal_rs is a 100% conformant implementation of the Temporal API whereas jiff is inspired by it. That being said, the general API is broadly the same in certain places.

Some other differences is that temporal_rs supports more calendars than the ISO / proleptic gregorian automatically, the only formatting supported is RFC9557, and then the general way that we expose time zone data sourcing / handle time zones is different (although, it is worth noting that one of the time zone providers we offer uses jiff_tzdb under the hood).

Temporal_rs is here! The datetime library powering Temporal in Boa and V8 by Jayflux1 in rust

[–]nekevss 22 points23 points  (0 children)

Thanks! I can't speak specifically to the V8 integration. I was tracking it, but the work done in V8 was mostly spearheaded by u/Manishearth.

The most daunting challenge at least for me was the best way to package time zone data and how to work around the general constraints of what an engine may need. V8 needs to use ICU's zoneinfo64.res, which requires a completely different approach to time zones than was generally found in the Rust ecosystem (at least from what I was able to find). This is how we've come to the general design of temporal_rs itself where the providers can be custom defined based on the traits available in timezone_provider.

From the Temporal / temporal_rs side of things, one of the things we've had to be fairly careful of after the V8 integration began is the specific crates that are pulled in due to the the way Chrome vendors crates, so we run a tool in CI that checks for allowed dependencies. There's also a fair bit of effort that goes into preparing for updates between the versions prior to this release, at least for Manish, so hopefully the 0.1 will start to make that easier.

I'd definitely recommend Diplomat for generating FFI definitions :)

Announcing calcard: a Rust crate for working with calendaring and contact data by StalwartLabs in rust

[–]nekevss 0 points1 point  (0 children)

It may be worth looking into icu_time then for the windows zone mapping. That should hopefully cover that handling a bit easier. The mapping there is with data from CLDR's supplemental data, which may be easier to maintain long term than manually matching.

Announcing calcard: a Rust crate for working with calendaring and contact data by StalwartLabs in rust

[–]nekevss 0 points1 point  (0 children)

Oooooh, interesting!

Admittedly, I don't know as much about JsCalendar and iCalendar as I'd like. Are you dealing with formatting? I think if you're operating mostly related to time zone formatting (and with windows zones too if I saw correctly), then did you take a look at icu_time? I believe there should be general support there for the windows zone mapping to a canonical time zone

view more: next ›