ibraheemdev

10 ms·

31.
by ibraheemdev 4y ago
The post introducing Ristretto, a similar Go cache is also a great technical read: https://dgraph.io/blog/post/introducing-ristretto-high-perf-...
32.
by ibraheemdev 4y ago
Works for me.
33.
by ibraheemdev 4y ago
Is allocating a large array on startup to avoid gc cycles better?
34.
by ibraheemdev 4y ago
The new `runtime.SetMemoryLimit` is actually a pretty big deal and solves a lot of long standing issues regarding the garbage collector not being very configurable, I believe including the one described by the viral "Go memory ballast&
35.
The Go Memory Model(tip.golang.org)
2 points by ibraheemdev 4y ago|0 comments
36.
by ibraheemdev 4y ago
This is a consequence of runtimes relying on global variables that their core future types are dependent on. Creating abstractions to solve this problem is one of the main goals of the the async working group [0]. [0]: https://gi
37.
by ibraheemdev 4y ago
Blocking I/O+threads can actually scale very well now, and with block_on you get the worst of both worlds, but yeah, I agree that most people are probably fine with it.
38.
by ibraheemdev 4y ago
> I'd instinctively worry about overhead there Yeah, one of the nice things about blocking I/O is that you can perform it with a single syscall. With block_on(async_io), you're now dealing with registration with a reactor,
39.
A Guide to the Go Garbage Collector(tip.golang.org)
233 points by ibraheemdev 4y ago|21 comments
40.
“people depend on third-party libraries too much”(twitter.com)
1 points by ibraheemdev 4y ago|0 comments
41.
by ibraheemdev 4y ago
It uses the linux futex api directly, not a user space parking lot as used by the parking-lot crate.
42.
by ibraheemdev 4y ago
> - Noisy neighbor problems from other threads messing with your TLB and L1 cache Switching between threads within the same process doesn't require a TLB or L1 cache flush. Not sure if you were implying this, just wanted to point th
43.
by ibraheemdev 4y ago
> More precisely, OS threads, because of their scarcity, introduce an artificial bound on throughput that's lower than what the hardware can support, and usermode threads remove that bound. Why are OS threads scarce? The OS allocate
44.
by ibraheemdev 4y ago
This works with runtime agnostic futures, but you can't do any I/O without requiring a specific runtime. reqwest for example doesn't use a generic block_on, it runs tokio behind the scenes.
45.
by ibraheemdev 4y ago
I would say that threads work _very well_ for concurrency in _most_ apps. Thread context switches have gotten much much cheaper over the years, and the idea that threads are heavyweight is very outdated.
46.
by ibraheemdev 4y ago
It definitely can work, but Rust's model is incredibly powerful, and can make it easy to model complex control flow. Certain patterns, such as cancellation, can get pretty hairy in Go, although this is a place where Rust has some work
47.
by ibraheemdev 4y ago
Rust makes it very easy to use plain old OS threads, which work very well for many, dare I say _most_ use cases. OS threads are a lot lighter and cheaper than many realize, and async has it's own hidden costs. In the cases that OS thre
48.
by ibraheemdev 4y ago
The most common confusion with this is that when importing library code from your binary, you use `crate_name::...` as opposed to `crate::...`, as they are separate. You also don't have to declare the lib.rs as a module from the binary
49.
by ibraheemdev 4y ago
The rewrite commit is here for anyone interested: https://github.com/ruby/ruby/pull/5826
50.
Rocket's 2nd v0.5 Release Candidate(rocket.rs)
2 points by ibraheemdev 4y ago|0 comments
51.
A Shiny Future with GATs(jackh726.github.io)
4 points by ibraheemdev 4y ago|0 comments
52.
by ibraheemdev 4y ago
> There is no way for your operating system to know exactly how much stack space a thread will need so it allocates an amount on the order of around a megabyte. You only have around a bakers dozen gigabytes of RAM, so you can only make g
53.
by ibraheemdev 4y ago
You can follow 2-look OLL/PLL with just a handful of algorithms.
54.
by ibraheemdev 4y ago
The article seems to have been written by: > a 15 year old student who likes to code and blog for some perspective :)
55.
by ibraheemdev 4y ago
You can unsafe to get around the borrow checker, just not directly; you have to go through raw pointers.
56.
by ibraheemdev 4y ago
You can usually use pattern matching to get around a check followed by an unwrap. I would rewrite your example as: if let [first, ..] = &some_vec { print!("{}", first); // .. more code }
57.
by ibraheemdev 4y ago
If you look at the techempower submission source code you'll quickly see why: https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... .
58.
Pointers Are Complicated III, or: Pointer-integer casts exposed(ralfj.de)
11 points by ibraheemdev 4y ago|1 comments
59.
Hyper 1.0 Roadmap(seanmonstar.com)
4 points by ibraheemdev 5y ago|0 comments
60.
Rust Strict Provenance(github.com)
2 points by ibraheemdev 5y ago|0 comments

More ›