Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
dureuill
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
8 ms
·
31.
▲
by
dureuill
3y ago
> Much has been spoken at various occasions about drivers and I feel that the consensus is to wait for now. Interesting, I did not follow that development. I thought the plan was to use Rust for some out-of-tree/optional drivers. Wh
32.
▲
by
dureuill
3y ago
`let` defines a new binding, as opposed to changing the value of an existing binding. You can't remove `let` to keep only `=` because it has a different use case. Not indicating the type is idiomatic in Rust, but you can annotate it:
33.
▲
by
dureuill
3y ago
Interesting, I was lacking this context. Could you provide me with more information about this? I only saw atomic_shared_ptr come up in discussions about bugs up to now.
34.
▲
by
dureuill
3y ago
I would rather use the non-atomic shared pointer from Boost[1] linked upthread than a non-standard non-portable implementation detail from GCC, but yes, it exists. You can definitely implement a non-atomic non-threadsafe shared pointer in C
35.
▲
by
dureuill
3y ago
The point of the article isn't that single-threaded non-atomic shared pointers are unfeasible in C++, it is that their usage is too dangerous. The fact that it wasn't included in the standard library for this reason is an argument
36.
▲
by
dureuill
3y ago
Yes, this is discussed in the article, I do not understand your point.
37.
▲
by
dureuill
3y ago
In this context, "unsynchronized access" refers to read/write operations happening concurrently on multiple threads, *not* to the shared pointers pointing to different objects as a result of the assignment. Unsynchronized acc
38.
▲
by
dureuill
3y ago
> which is by definition a non-thread-safe operation yes, but at this point, since the reference count is reaching 0, there is supposed to be only that one thread accessing the object being destroyed, so the destruction not being thread-
39.
▲
by
dureuill
3y ago
"performance" is about profiling and avoiding bottlenecks. That I'm using reference counting on the error path of my parser (so there's something wrong with the input and the task is not going to complete) is very unlike
40.
▲
by
dureuill
3y ago
This strikes me as a weird criticism. If I hired someone to paint my wall and they were saying "I'm not going to use any protection against splatters on the ground because I am that good and don't need training wheels",
41.
▲
Too dangerous for C++
(blog.dureuill.net)
93 points
by
dureuill
3y ago
|
86 comments
42.
▲
by
dureuill
3y ago
The issue with this approach lies with the current content of the stdlib: the stdlib is for vocabulary types , that is, types that are meant to be used as interoperability bricks in almost all programs (think Option, Result, Vec). If you s
43.
▲
by
dureuill
3y ago
It is both. "Memory safe" means that if the user is "holding it wrong", it won't cause a memory error. In safe Rust, it is impossible to call free with the wrong address (simply by virtue of the `free` equivalent be
44.
▲
by
dureuill
3y ago
You make it sound like Rust made these choices for the heck of it, whereas there are very good reasons why impl blocks are separate from the struct: 1. Make class methods open to extension. This allows adding methods from other contexts, in
45.
▲
by
dureuill
3y ago
> That link is about learning rust. While this is true for most of the article, I think the quoted sentence is about more general Rust use. > In my experience, this is not a big effort at writing new code, but at refactoring/main
46.
▲
by
dureuill
3y ago
[citation needed]. Here's a reference to the contrary[1]: > Overall, we’ve seen no data to indicate that there is any productivity penalty for Rust relative to any other language these developers previously used at Google. [1]: htt
47.
▲
by
dureuill
3y ago
Because gov agencies say so? Also, memory safety vulnerabilities is the largest class of vulnerability by count today by a large margin (70% of the total) and cost a lot of money to bigger companies. As changing language stacks also cost a
48.
▲
by
dureuill
3y ago
> Is make considered bad or something? Depends what you're using it for. Generated from CMake, Makefiles are OK I guess, although Ninja is strictly better these days. Manually written, I would say make is bad. 1. It doesn't pro
49.
▲
by
dureuill
3y ago
We have to be careful when using impl trait in return position in public APIs. The opaqueness means that the consumer of the API cannot name the type and cannot store it inside of a struct (without making it generic (moving the issue one le
50.
▲
by
dureuill
3y ago
AFAIK, not yet. It was a goal of Mimir, but LMDB (used by arroy on particular and Meilisearch in general) uses filesystem and os features (mmap, file locking) that are incompatible with wasm. If you're interested in bringing WASM suppo
51.
▲
by
dureuill
3y ago
One of our top oss contributors is developing mimir as an embedded Meilisearch: https://github.com/GregoryConrad/mimir/tree/main/packages/mi...
52.
▲
by
dureuill
3y ago
It increases the places it can be used, but it decreases what type can be returned. Not all types can be sent between threads (in particular, types that feature unsynchronized mutability through shared references are not Send). If you execu
53.
▲
A curiously recurring lifetime issue
(blog.dureuill.net)
3 points
by
dureuill
3y ago
|
0 comments
54.
▲
by
dureuill
3y ago
why would be using a "fancy tool" a bad thing? Headers are to be maintained manually, which is lost productivity and invite errors. The "fancy tools" can provide specialized search, formatting of the documentation, inter
55.
▲
by
dureuill
3y ago
I agree that the compact API overview is a good thing to have, but I loathe that C forces the user to write it by hand, while modern languages just generate it from the documentation comments of the source. See: `cargo doc` that generates n
56.
▲
by
dureuill
3y ago
> Modules adoption would be severely stunted if everyone had to adjust all calling code in order to convert a library to use modules. "We'd like this new feature to be good, but we have to cripple it for adoption/back-comp
57.
▲
by
dureuill
3y ago
Of course you're correct that Rust has no support for making the `Self` type itself generic, which is the core of the "deducing this" feature. However, "deducing this" has the side-effect of allowing to explicitly s
58.
▲
by
dureuill
3y ago
If that interpretation is correct, how can websites like lemonde.fr propose to either accept all cookies or get a paid subscription, under the GDPR? Is that actually illegal? Or am I missing a difference with what you're describing?
59.
▲
by
dureuill
3y ago
I wish we had the option to specify explicit captures in rust closures too. When you need it you need it, and it is good for clarity. The current "add `move` to switch from by-reference to by-value" is too coarse grained
60.
▲
by
dureuill
3y ago
The most recent high severity vulnerability I could find in libjpeg is CVE-2016-6702[0]. If you're willing to count libjpeg-turbo, there's also CVE-2020-17541[1]. For h.264, if you're willing to count Firefox or gstreamer, we
More ›