I feel like it would be better if the docs explained both IPv4 and IPv6 and told you that you're going to need support both for most software. If there is no good default then it's best to not choose any default.
Forum The Rust Programming Language Forum
users.rust-lang.org ↗Forum Discourse in inglese. 8 sezioni seguite: announcements, code review, community, embedded, help, meta, tutorials e uncategorized.
- Discussioni al giorno
- 7
- Discussioni raccolte
- 421
- Messaggi al giorno
- 55
- Sezioni
- 8
- Fonti seguite
- 10
- Motore
- Discourse
Ultime discussioni
Raccolte ogni 4 ore dal feed pubblico del forum. Riproduciamo solo il titolo, il link e l'inizio del messaggio; ogni link rimanda alla fonte.
Morgane55440: but ipv6 must be the default if there has to be one This is most of the reason why I even started this topic. I'm sometimes a bit baffled how every programming community, programming example, network equipment etc. does not at least to this. Feels like after almost 30 years after coming up with the standard that could be the bare minimum. I don't think anyone wants to make things harder for the sake of the transition, that's why we haven't completed it after all, but at least going v6 first should be "normal", and I don't think that's too much to ask for by anyone who cares about the topic. And I don't want to argue that it makes a large difference, I just think it's the right default, and considering good defaults is something this community objectively cares about, I think this could be one of them
I'd like to nominate remus , a CLI that exports a PostgreSQL schema as Mermaid, DBML, SQL DDL or JSON from one static binary. The Postgres side is on the site ; what may interest this crowd is the shape: one catalog query, one model, pure emitters. One query. A single statement against pg_catalog returns the whole schema as one JSON document. It is embedded with include_str! and printed verbatim by --print-sql , so the query the binary runs and the query you can audit are the same bytes — and you can run it in psql yourself and pipe the JSON back, never handing the tool your credentials. A core with no I/O and no async. remus-core holds the model and stays compilable to wasm. Every format is a pure function of that model, which is what makes the whole emitter suite golden-file testable with no database in the loop: cargo test works on a fresh clone. One crate per emitter. remus-mermaid , remus-dbml and remus-sql each depend on the core and never on each other, so the compiler — not a convention — stops formats reaching into one another, and a wasm build can link a single format. The interactive flow is behind a default-on feature. remus with no arguments opens a prompt flow, but --no-default-features drops inquire and 13 other crates, which is what the container image builds. Nothing prompts unless stdin and stderr are both terminals, CI is unset and --no-input was not passed: a PTY is not proof that anyone is watching. crates.io · docs.rs · MIT or Apache-2.0
Which one is better to use then? What are the main differences?
So if I exported my model to onnx from darknet it should then work on either candle or burn (obviosuly I convert it to native for burn)?
I've looked at the docs a bit more and looks like Candle can only run inference on ONNX models. Burn has a converter that converts ONNX models to their native tensor format. I've not read anywhere that either only supports a subset of the ONNX format.
Regardless if I used ultralytics, darknet etc, if I exported my model to onnx, would it be automatically compatible with Burn or Candle etc?
jofas: doption won't suddenly increase due to some Rust docs using [::1] instead of 127.0.0.1 . i don't think anyone expects the doc change to have a huge impact, but the fact that it isn't a big deal doesn't mean we shouldn't use the better default jofas: Plus, young developers who still learn networking with IPv4 at school / uni, probably, might get unnecessarily confused. It's not worth it IMO. that would be a problem with the course, not rust. if there is a networking course that doesn't teach ipv6, the curriculum should have gone in the trash 10 years ago. no one is talking about removing ipv4 or even making it harder to use in any way. having documentation for both certainly is fine. but ipv6 must be the default if there has to be one edit : i would add that having both side by side in some example might in fact be helpful to indicate the similarity to users which are only familiar with one
And from Clar Fon again... This time in yesterday's design meeting: in stdlib we can make up our own compiler features if we need to, but in user-land that's not possible (is there a "most nominations in one week" prize?)
Burn, candle and torch all support the conversion of ONNX models to their native representations. Burn and candle are written in Rust. Torch—arguably the most widely used deep learning framework in the world—is a C++ library with a Rust wrapper.
I agree with the people opposing your proposed changes to the docs in the issue you linked. IPv6 is now almost 30 years old. Adoption won't suddenly increase due to some Rust docs using [::1] instead of 127.0.0.1 . Plus, young developers who still learn networking with IPv4 at school / uni, probably, might get unnecessarily confused. It's not worth it IMO.
421 discussioni raccolte dal 2 settembre 2026. Segui questo forum con una parola chiave →