101–110 of 125 posts
Earlier quoted context omitted.
It carries some weight, very roughly in the direction of formal verification. Since (assuming there isn't any unsafe), a specific class of bugs are guaranteed to not happen. However, this repo seems like it uses quite a bit of unsafe, by their own admission.
There's a lot of unsafe in this at least. hard to be both safe and fast.
> Compacting garbage collector, written in very unsafe Rust
Earlier quoted context omitted.
First time seeing a few of the engines listed here - based on this table I'm surprised Samsung's Escargot hasn't gotten more attention. LGPL, 100% ES2016+ compliance, top 10 perf ranking, 25% the size of V8 & only 318 Github stars. A quick HN search shows 0 comments for Escargot - is there some hidden problem with this engine not covered in this table?
Because it pretty much only makes sense for Samsung TVs and smart appliances since it scores 3% on the benchmarks vs V8. It's too big for most embedded devices, too slow for general computing, and if you can run something 25% the size of V8, you can probably just run V8. If for some reason that size and speed profile does fit your niche and you aren't Samsung wanting to use their own software, then Facebook's Hermes…
Sometimes you can't run V8 or any JIT engine because policy or politics, and it's nice to have options.
Earlier quoted context omitted.
Does that include emojis?
Emojis are complicated from a font rendering perspective. But from a string processing perspective, they're generally going to be among the simplest characters: they don't have a lot of complex properties with a lot of variation between individual characters. Compare something like the basic Latin characters, where the mappings for precomposed characters are going to vary wildly from 'a' to 'b' to 'c', etc., whereas…
Earlier quoted context omitted.
Yeah, the majority of the difference is from the Unicode data for Intl along with probably the timezone data for Temporal.
Is it possible to build Boa without these APIs?
Earlier quoted context omitted.
are you for real? Rust most definitely is not highly readable and the language reeks of complexity
It's comparable with Java. It's significantly easier to parse than C++.
And C++ can only be beaten by the likes of K, J and brainfuck. Very low bar to clear.
Earlier quoted context omitted.
Go has probably more packages than Rust, but i rarely see Go projects that use as many as rust. In Go the usuals are depending on the app, possibly some db drivers, a simple router and maybe some crypto related thing. Most projects do fine with just the stdlib. In rust i tend to see 100 deps, and 1000 transient deps. Compile times are not in seconds, but minutes.
You can do that just fine in Rust too, for example the Makepad[1] developers take a pretty extreme non-invented-here stance, and builds a full UI toolkit with no external dependencies (and a major focus on clean-build compile times). However, it isn't really part of the Rust OSS culture to operate like that. The culture typically values safety over compile times, and prefers to lean on a deep stable of battle-hardene…
Earlier quoted context omitted.
Unicode is everywhere though. You'd think there'd be much greater availability of those tables and data and that people wouldn't need to bundle it in their executables.
Unfortunately operating systems don't make the raw unicode data available (they only offer APIs to query it in various ways). Until they do we all have to ship it seperately.
Why is stuff written in rust always promoted as "written in rust" like its some magic thing?
Earlier quoted context omitted.
Agreed! FWIW, they are not even "complicated" from a font rendering perspective: they're simple non-combining characters and they are probably never used in ligatures either (though nothing really stops you; just like you can have locale-specific variants with locl tables). It's basically "draw whatever is in a font at this codepoint". Yes, if you want to call them out based on Unicode names, you need to have them in…
> they're simple non-combining characters Skin-tone emoji's are combined characters: base emoji + tone.
Earlier quoted context omitted.
Emojis are complicated from a font rendering perspective. But from a string processing perspective, they're generally going to be among the simplest characters: they don't have a lot of complex properties with a lot of variation between individual characters. Compare something like the basic Latin characters, where the mappings for precomposed characters are going to vary wildly from 'a' to 'b' to 'c', etc., whereas…
Sorry, what? You mean, emoji composition rules are simpler than combining diacritics? https://blog.codepoints.net/emojis-under-the-hood.html