Ralith
Ralith on Hacker News
There's a (configurable, easily bypassed) limit for newly created file size to catch that common mistake.
Disabling that option makes the `%SystemRoot%\system32\GigabyteUpdateService.exe` binary mentioned by the original article stop appearing, so it seems so.
There's even been experiments with binding futures to glib or various GUI event loops!
"system" here is intended to refer to the application using tokio, i.e. if you got rid of tokio and did everything by hand you wouldn't be able to make your application faster.
Missed opportunity to render pixel art in the calendar display.
Thanks for the details!
> the core protocol objects in quinn that directly link to specific socket and address and even event loop reactor objects - and these objects strictly in Rust to boot.
This isn't accurate. The core protocol objects in Quinn are those defined in "quinn-proto", which has absolutely no awareness of how I/O is performed or what event loop is in use: the interface is structurally very similar to Quiche's, with the caller providing data/timeouts by any means and consuming events that result. See https://docs.rs/quinn-proto/0.2.0/quinn_proto/struct.Endpoin... for details.
The high level "quinn" crate interface, which incorporates awareness of UDP sockets and the tokio event loop, is strictly an optional binding; that's why it's a separate crate.
> existing solutions available right now would not be able to offer the level of flexibility and abstraction we need, nor would they likely be able to add the interfaces we need in a reasonable timescale, nor would they likely tolerate our requests to do so.
Support for this type of flexibility, up to and including allowances for a C API suitable for integration with existing software, has actually been an express design goal of Quinn from the start, and I regret that that wasn't clear.
It's worth emphasizing that QUIC is more general than a new transport for HTTP; it has wide ranging applications, due to being far more versatile than TCP.
All Rust programs call out to platform-dependent unsafe code sooner or later in the form of the standard library. Otherwise, you wouldn't be able to allocate memory or do any I/O whatsoever.
Sometimes the standard library doesn't expose functionality you want, like the capability to read/write the ECN bits of your UDP packets, so you have to bind some syscalls yourself. The capability to do this is one of Rust's core strengths, and it does not compromise a program's rustiness any moreso than calling a wrapper around write to print "Hello, world!" does.
> But for C/C++ projects I would just compile in an Ubuntu container as well.
Setting up a reproducible build environment with nix-shell is much more convenient than screwing around with containers.
> Binaries are a pain, but that's always true if you aren't running the exact distro that the binary was built for.
This is actually easier to deal with on NixOS than elsewhere, because the tools for handling that case (patchelf, buildFHSUserEnv, supporting multiple versions of a lib, etc) are so well developed.
> I invented quaternions using matrices
what
Even if you're writing your own engine from scratch, VR runtimes provide orientation information directly to the engine as a 4x4 transform matrix. They would have to ignore all the documentation and go far out of their way to somehow regress to euler angles, and are likely introducing other precision issues in doing so.
> There is no support for datagrams, just datastreams.
Datagrams can be easily and effectively encoded as discrete short-lived streams. If you need streams of datagrams, you can encode your own header to do that. I see no reason why this has to be built into the protocol when the provided primitives are sufficient.
> Forward error correction is actually cool but just using XOR is too limited.
Pretty sure FEC was removed from the IETF draft.
Those are probably supported version numbers.
Do you want GNU extensions? Use the latter. Otherwise, use the former.
One of Rust's selling points is literally that it has very easy zero-overhead C interop.
Who needs type systems, anyway? Or any datatypes but strings, for that matter!
> There is a return statement; it just can't return anything
What? Return works exactly like it does in C, it's just not required as much.
> warning: unnecessary parentheses around `if` condition
I'm confused about how reducing the amount of required syntax is "gratuitous syntax."
A type system for Nix would be pretty neat, but a lot of unfortunate design decisions were made in the absence of one that may make this a difficult project.
It should be noted that rooms are not "on" a homeserver the way IRC channels are on a network. The server is just a convenient reference point. If it goes down, the room still exists and can still be used, and even given a new name.
> Over 10 years the government will save $1.32 for every $1 invested for fuller support for the chronically homeless, Sacred Heart Mission estimates
32% return on investment sounds like a lot to me.
That's a problem Wikipedia has in general; improvements to Wikipedia's botany coverage are not going to meaningfully change it one way or the another.
You can compromise on turing-completeness, too. Idris, for example, lets the programmer decide whether a given definition should be required to provably terminate or not.
It could still make sense to ship an ad blocking plugin with the browser distribution.
So if I use LaTeX and it gives me the results I want and I don't find myself spending inordinate amounts of time tweaking things, does that make me an intermediate user? I guess I had better stop learning.
> I had been mainly looking on the Who's hiring posts of HN
Well, there's your problem. HN consists mostly of web developers/startups.
> It's almost like you don't realize that Java came out a decade before Go
This might be a more compelling argument if Go didn't ignore (more than) the last decade of PL research.