HackerTrans
TopNewTrendsCommentsPastAskShowJobs

namjh

no profile record

comments

namjh
·2개월 전·discuss
As a South Korean I'm lowkey surprised that most reactions posted here is describing the detention experience to be some kind of human rights abuse. Most Koreans debating on Internet demand severe punishment so criminals be afraid of getting jailed. I know this is a very questionable strategy, but afaik this is the most dominant public sentiment over this topic.
namjh
·7개월 전·discuss
Yes we do have[^1] but unfortunately it looks like not checking the integrity, just reachability.

[1]: https://downdetectorsdowndetectorsdowndetector.com/
namjh
·2년 전·discuss
Amazed that Safari does not support WebGPU even with the latest release. Opened Chrome and it works. Very cool demo!
namjh
·2년 전·discuss
> Consequently, this also means you cannot define two error variants from the same source type. Considering you are performing some I/O operations, you won't know whether an error is generated in the write path or the read path. This is also an important reason we don't use thiserror: the context is blurred in type.

This is true only if you add #[from] attribute to a variant. Implementing std::convert::From is completely optional. Personally I don't prefer it too as it ambiguates the context. I only use it for "trivially" wrapped errors like eyre::Report.
namjh
·2년 전·discuss
Anyone who needs to handle FFI in Rust, should read the FFI chapter in Rustonomicon: https://doc.rust-lang.org/nomicon/ffi.html

Unsafe Rust is indeed very hard to write correctly. Rustonomicon is a good start to learn unsafe Rust.
namjh
·2년 전·discuss
There was an NFT section in the claim form so certainly they are aware of but I'm not sure it's still open
namjh
·2년 전·discuss
Big kudos to Rust compiler devs about their sophisticated type system and its kind (and highly intelligent) help messages. A little concern is that AFAIK its complexity in type systems and other static analysis things require deep domain knowledge, so in a far, far future there may be a lack of "core" engineers comparing to a demand much increased at that point. This kind of change looks like already requiring deep understanding of both Rust's type system and internal compiler structure to implement.
namjh
·2년 전·discuss
That's because the code triggering compilation error is using reference. If you use Rc or Arc (which pays runtime cost) there should be no lifetime at all.

Albeit I admit there somewhat exists a community sentiment like "if you use Rust, you should maximize its zero cost abstraction feature so lifetime is good and generics good", and my (minor) opinion is that, it's not always true to all users of Rust.

And the clumsy Arc<Mutex<Something<TheOtherThing>>> makes users feel bad about using runtime cost paid types. Maybe we should introduce easy Rust dialect which transpiles into Rc/Clone everywhere but I doubt it's trivial to transpile.
namjh
·2년 전·discuss
IMHO the mentioned examples of complexity like multiple type variables and lifetimes with bounds are for who "really" wants compile-time contracts. These are mostly opt-in so higher level use cases(like writing backend business logics) should not care about that, just wrapping everything with Boxes and Arcs.

Of course Rust is not perfect; there is some 'leakages' of low level aspects to high level like async caveats(recursion, pinning, etc.). I'm not sure how these can be avoided. Maybe just trial-and-errors for all..?
namjh
·2년 전·discuss
Do we have a better method of verifying compilation output than just re-executing the compiler with same source, than comparing the output? TEE attestation could be a thing(albeit it could be a "trusted" third party which occasionally be broken).
namjh
·2년 전·discuss
Albeit 1.6PB/day may be somewhat exaggerated, comparing Binance to Ethereum needs much more consideration including:

- Ethereum's transaction throughput is normally 12~20tx/sec so there cannot be a "high-frequency trades" on Ethereum smart contracts with naive contract interaction(it will cost enormous fees). There are scaling concept like "layer-2" or "layer-3", but they still cannot beat highly optimized centralized server applications. Decentralized exchanges have different schemes to centralized ones to reduce txs to discover the price(keyword: AMM, "automated market maker")

- The transactions per sec metrics are just recording "confirmed" txs by the blockchain, and many "retail-squeezing" trading txs (called MEV, maximal value extraction) are competing behind the blockchain and only one tx is chosen by the blockchain, which will rebate most profits to the blockchain validator(which is analogous to the HFTs on the centralized exchanges).

- The blog post's argument would count all logs of intermediate hops, like L7/L4 proxy and matching engine and so on, and Ethereum's full node storage is only a single component which is almost like a non-parallelized matching engine. Maybe we should also count logs of public RPC nodes of Ethereum? (Also many txs are not gossiped to the public mempool so these are hard to count)
namjh
·2년 전·discuss
Interesting project and kind of tangential topic, will JIT compilers still be widely adopted given they are considered a critical attack vector when it misbehaves? I wonder if there is an effort to formally verify its safety or do a complete redesign to ensure it.
namjh
·2년 전·discuss
Great work! I really enjoyed the interactivity. Actually I already was aware of the concept of zero-knowledge proof from the wonderful article by ZCash(which is a privacy-oriented cryptocurrency) core developer Matthew Green, worth to check it out: https://blog.cryptographyengineering.com/2014/11/27/zero-kno...

My two cents of the ZKP illustration is that directly using hashes are more likely to convince "computer-friendly" people to introduce the commitment scheme.
namjh
·2년 전·discuss
In reality, the entire map should be sent first to the verifier (with colors hid behind the post-it) so if it was a bogus randomly colored map, you may find two adjacent points having same color if you try extremely many(think hundreds or thousands in the website's case) times. If you sufficiently try many times and fail to find the adjacent points, you will convince that the prover have the map which is correctly 3-colored.

Note that the entire map is sent again, shuffled its color each time after you choose the two points.
namjh
·2년 전·discuss
Am I the only one just seeing a blank page? Proxying via archive.is did not help.

Edit: after some googling I found https://lists.freebsd.org/archives/freebsd-hackers/2024-Janu... but I couldn't read the whole thread at once
namjh
·3년 전·discuss
> The problem is that in the ecosystem we are building the prevailing assumption is that anything async must also be Send, which means we end up using Send primitives even in non-Send contexts, which is always a waste.

Honestly I don't think every user want top notch throughput when writing asynchronous Rust applications. Most users would just want the correctness of the Rust type system, and its "lightweight" runtime characteristics compared to CPython, Node.js etc., which can provide fairly good performance.

The thing is, using Arc in single threaded runtime does not greatly harm performance. If it matters, you should be handling 1M+ rps per core and using multithreaded runtime because it scales better, which benefits from using threadsafe primitives.
namjh
·3년 전·discuss
> Making things thread safe for runtime-agnostic utilities like WebSocket is yet another price we pay for making everything multi-threaded by default. The standard way of doing what I'm doing in my code above would be to spawn one of the loops on a separate background task, which could land on a separate thread, meaning we must do all that synchronization to manage reading and writing to a socket from different threads for no good reason.

Why so? Libraries like quinn[1] define "no IO" crate to define runtime-agnostic protocol implementation. In this way we won't suffer by forcing ourselves using synchronization primitives.

Also, IMO it's relatively easy to use Send-bounded future in non-Send(i.o.w. single-threaded) runtime environment, but it's almost impossible to do opposite. Ecosystem users can freely use single threaded async runtime, but ecosystem providers should not. If you want every users to only use single threaded runtime, it's a major loss for the Rust ecosystem.

Typechecked Send/Sync bounds are one of the holy grails that Rust provides. Albeit it's overkill to use multithreaded async runtimes for most users, we should not abandon them because it opens an opportunity for high-end users who might seek Rust for their high-performance backends.

[1]: https://github.com/quinn-rs/quinn
namjh
·3년 전·discuss
Might be related: https://arxiv.org/abs/2211.16421 It's a paper about directly learning via JPEG encodings which works well with visusal transformers' patch mechanism.
namjh
·3년 전·discuss
When I was a newbie for Rust, I was encouraged to use CLion with the Rust plugin. What's the difference between CLion + Rust and IDEA + Rust?
namjh
·3년 전·discuss
Wow, if I were you, I would never think of analyzing the rustc source code. Great job!