|
I had changed from hardcoding the path in the command-line application. This is what I'm using now:code:
src/lib.rs src/command-line.rs (not the real name) lib.rs is wrapped in "pub mod lib" I feel kind of stupid having lib::lib and intend to change it but just decided to show you the sausage currently being made. Is this just dumping the raw source for lib in my command-line application? Edit: Closing that code tag. Rocko Bonaparte fucked around with this message at 18:44 on Sep 20, 2022 |
# ? Jul 22, 2022 03:56 |
|
|
# ? May 27, 2024 02:48 |
|
Yeah, Rust looks for src/lib.rs and anything public in that file is basically top-level, i.e. declaring mod lib is just an unnecessary layer of encapsulation. In fact I think this defines the interface of your library, were you to package this up as such. In other files within the project you can use (public) things from src/lib.rs with use <project name>::{<public definitions from src/lib.rs>}; Using crate instead of the project name might also work but I haven’t tried that Mostly speaking from my rear end here, mind you. A couple small projects and the O’Reilly book to go by
|
# ? Jul 22, 2022 04:42 |
|
Use decls don't dump source the way #include does, it's more like imports in any land built after 1960 instead where the compiler abstractly "links" the two in its compilation model and makes the symbols available
|
# ? Jul 22, 2022 09:37 |
|
If you call it main.rs I think you can get rid of the toml's [[bin]] section too because of the conventional name. Not 100% on that though.
|
# ? Jul 22, 2022 09:38 |
|
I don’t exactly know what the issue is here, but I want to share that a while back, I was having an absolute nightmare of a time following the rust book’s examples to break my code into separate files. Stuff just was not working like the book said it should. Then I noticed a line in my cargo.toml file saying “rust2017” or something like that. It was an old one-file project that I had recently resurrected. When I removed that line, everything just worked. It makes sense why that was a thing, but I was still furious
|
# ? Jul 22, 2022 12:54 |
|
Refer to the lib crate by yourcratenamehere. That's all there is to it. No mod declaration of any kind.
Ralith fucked around with this message at 18:03 on Jul 22, 2022 |
# ? Jul 22, 2022 18:01 |
|
Would rust ever make sense as a language for a REST api or a backend for a suite of web applications? It seems like such a cool language that I want to find an excuse to use. I've been using Ruby for over a decade and after now spending a couple years with Typescript I'm more than ready to declare undying love for languages that boss you around a bit instead of letting you ship garbage like Ruby does.
|
# ? Jul 30, 2022 18:09 |
|
sure yeah we use it on the server all the time, no problem. be liberal with clones and arcs to appease the borrow checker, no need to eek out every last 5% of speed.
|
# ? Jul 30, 2022 18:11 |
|
gonadic io posted:no need to eek out every last 5% of speed. Like I said I'm using Ruby so I don't even have the first 5%
|
# ? Jul 30, 2022 18:14 |
|
I've written a couple of relatively busy rust rest API things, and can recommend Axum as a new and tasty thing
|
# ? Jul 30, 2022 23:05 |
|
I blew quite a bit of time trying to invoke BufReader::lines() today. It was because I had neglected to import std::io::BufRead. I don't use BufRead directly but I guess that adds appropriate traits to use BufReader::lines on files. I got lucky with IRC and cross-checking examples online in this case, but how could I anticipate I'm neglecting something like that in the future?
|
# ? Aug 3, 2022 07:26 |
|
Imma turn that into a bit of my own question: Is there a downside or reason not to use std::io::prelude::* to just cover everything there? I know pretty well that embedded stuff tries to pare it all down even to excluding std itself, but for normal everyday code?
|
# ? Aug 3, 2022 07:47 |
|
Rocko Bonaparte posted:I blew quite a bit of time trying to invoke BufReader::lines() today. It was because I had neglected to import std::io::BufRead. I don't use BufRead directly but I guess that adds appropriate traits to use BufReader::lines on files. I got lucky with IRC and cross-checking examples online in this case, but how could I anticipate I'm neglecting something like that in the future? Doesn't the compiler error tell you to do that? Edit: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=1ac677079f88616b65c7d97c7ff40292 code:
Vanadium fucked around with this message at 10:19 on Aug 3, 2022 |
# ? Aug 3, 2022 10:15 |
|
I just commented out the the BufRead import to see and yeah, I guess I do see that in the CLion output. The formatting was a little goofy though. I guess the moral of the story is to fully scour that output (surprise, surprise).
|
# ? Aug 3, 2022 17:36 |
|
I've seen people get confused by diagnostics when they were only looking at what rust-analyzer says about an individual line instead of the full rustc output before, there's clearly some suboptimal presentation there.
|
# ? Aug 3, 2022 17:51 |
|
I'm having trouble with BufWriter living inside an option. I'm creating it as:code:
Something like code:
I've been trying a number of things but they're getting increasingly convoluted in a way that makes me think I'm fighting the languge.
|
# ? Aug 24, 2022 21:12 |
|
You want `match fs.as_mut()`. That and `as_ref` seem pretty unknown but are one of my most-used Option methods tbh
|
# ? Aug 24, 2022 21:22 |
|
Does anyone know of a Rust training consultancy they’d recommend? I’m thinking of adopting more Rust where I work and as part of that I’d like to look into some structured training options.
|
# ? Aug 24, 2022 21:34 |
|
gonadic io posted:You want `match fs.as_mut()`. That and `as_ref` seem pretty unknown but are one of my most-used Option methods tbh That worked! Thanks!
|
# ? Aug 24, 2022 21:41 |
|
fritz posted:That worked! Thanks! Once your code is more settled you'll find that clippy will tell you that lots of your matches are equivalent to functions like `map` and `ok` and so on, make the code much easier to read. No worries when just messing around though.
|
# ? Aug 24, 2022 21:50 |
|
Subjunctive posted:Does anyone know of a Rust training consultancy they’d recommend? I’m thinking of adopting more Rust where I work and as part of that I’d like to look into some structured training options. nope sorry i dont know anything about this
|
# ? Aug 25, 2022 06:35 |
|
gonadic io posted:Once your code is more settled you'll find that clippy will tell you that lots of your matches are equivalent to functions like `map` and `ok` and so on, make the code much easier to read. No worries when just messing around though. Yeah I'm already a big fan of clippy, but I wasn't even able to get the thing to compile so it wasn't helping.
|
# ? Aug 25, 2022 17:50 |
|
Does anyone here use Rust for embedded systems? How's it working out?
|
# ? Aug 26, 2022 00:50 |
|
fart simpson posted:nope sorry i dont know anything about this I’d like this to be a sarcastic response from someone who has a bunch of leads on excellent trainers, if we can arrange to inhabit that reality.
|
# ? Aug 26, 2022 03:06 |
|
i was being sincere
|
# ? Aug 26, 2022 03:11 |
|
StumblyWumbly posted:Does anyone here use Rust for embedded systems? How's it working out? There are a couple of competing approaches: the rust HAL people do things one way, Ferrous Systems have their own way of doing things, the Oxide people have a different approach. They’re all kind of incompatible.
|
# ? Aug 26, 2022 05:37 |
|
StumblyWumbly posted:Does anyone here use Rust for embedded systems? How's it working out?
|
# ? Sep 8, 2022 10:07 |
|
ploots posted:There are a couple of competing approaches: the rust HAL people do things one way, Ferrous Systems have their own way of doing things, the Oxide people have a different approach. They’re all kind of incompatible. Not knowing any of them, do they all ultimately try to put some layer up so you don't have to put unsafe blocks everywhere?
|
# ? Sep 8, 2022 10:34 |
|
Have any of you tried to make Debian packages of Rust code? There's cargo-deb, which assumes you are going to build through cargo and hit the Internet to resolve everything along the way. Alternately, there's debcargo-conf, which assumes you're pulling do public stuff in Rust's repository for creating Debian packages. What I have is a corporate-internal project using our own internal build system that expects you to get all your dependencies squared away up-front. The problem with this is I have to express all my dependencies as Debian packages, and these packages themselves have inconsistent sub-dependencies. So I have to bumble through layers of build errors to resolve all the dependencies. Is there at least some way with cargo where I can tell all the subdependencies I'm using normally so I can get all these listed one the first try?
|
# ? Sep 17, 2022 03:06 |
|
Sounds like cargo vendor would be helpful
|
# ? Sep 17, 2022 08:32 |
|
I did it, I finally got Rust approved for our backend at work (go gently caress yourself, node) I'm liking Rocket and SeaORM for microservices, very slick.
|
# ? Sep 17, 2022 20:26 |
|
minidracula posted:Well, I/we (myself and others) are about to try, at work. Somewhat speculative, but we'll see what happens... I'm very curious how this goes!
|
# ? Sep 17, 2022 21:47 |
|
Rust for backend is really sweet, we're building our latest service in it now. Using sqlx directly for the small amount of db stuff, an ORM seemed a bit overkill. We're using Axum as our web server/framework. Last i looked at rocket it didn't look as if it was very actively maintained anymore? Edit: yeah, latest rocket stable is pre-async, and their two 5.0 release candidates are from June 2021 and may 2022. Their repo doesn't appear to see very much activity either. I've previously built a small microservice using actix-web at work, and using axum this time feels a lot nicer and more ergonomic kujeger fucked around with this message at 01:42 on Sep 18, 2022 |
# ? Sep 18, 2022 01:34 |
|
We use Axum as well and it's pretty nice, can recommend.
|
# ? Sep 18, 2022 10:54 |
|
You're making me rethink. One of my needs is mtls, which is doable with axum but in rocket is just a feature to enable, rather than something I have to cobble together. How do you guys serve HTTPS?
|
# ? Sep 18, 2022 22:49 |
|
Piggybacking that, how hard would it be and/or what would support proxy passing from nginx like how PHP does it? I like my static serving to be direct and ssl termination even further removed. Because that's the answer btw: Put your rust service behind something like haproxy so you don't need to gently caress with cert differences across environments. I like the idea of doing everything in rust but also think it's folly when there are dedicated and proven drop in solutions that cover all the edge cases too. Header parsing, load balancing, websocket upgrade rerouting, tls termination, cipher suites/support and preferences... One could implement all this in rust but it's very SEP to me, especially cryptography stuff. SSL is a deployment hurdle, not an application coding one. Ranzear fucked around with this message at 02:31 on Sep 19, 2022 |
# ? Sep 19, 2022 02:18 |
|
Got good news for you about rustssl and it's increasingly common use
|
# ? Sep 19, 2022 02:39 |
|
Yeah, not saying it's unhealty or anything to do it yourself for a one-off nonscale project, caveats galore, just that it's better left as somebody else's problem if possible. Terminating SSL at a proxy layer before load balancing or even just domain level routing is too bulletproof to give up. Not having to reload or even restart your rust app just because certbot fired off this morning is nice too. Edit: You must mean rusttls btw. I wanted to run it on some game server socketing but then decided much the same to let it be SEP and just run websockets. Long have aged well jokes about rolling one's own crypto in PHP but this really is just a few steps removed with all the little nontrivial stuff like application layer access to certs (pwn the app and pwn the whole domain, how much do you trust your own code?) Maybe I'm paranoid. Maybe their code never sees the public facing web. Installations that try to manage their own certs are a giant pain in my rear end (looking at you, GitLab!) It's a very linux backend environmental perspective rather than a rust development perspective. If one running both Node and rust, there's even more reason for centralizing one's certs with a proxy termination service. Ranzear fucked around with this message at 03:15 on Sep 19, 2022 |
# ? Sep 19, 2022 02:51 |
|
Ad a compromise, maybe don't handle certs in-process and use a proxy/load balancer tier for TLs termination, but also write the proxy in rust.
|
# ? Sep 19, 2022 11:32 |
|
|
# ? May 27, 2024 02:48 |
|
kujeger posted:Sounds like cargo vendor would be helpful I never actually posted my reply but that lets me revise. The vendor command recursively gives me everything which wasn't what I wanted. What I was hoping that I could get the Debian names of everything I have to put in for a Debian package of my program. That should be a 1:1 translation of my Cargo.toml build dependencies but I kept getting snagged with subdependencies. That is, I needed error-chain, but I'd get whacked for missing the backtrace crate, for example. I was told a solution from somebody on #debian-rust and it's probably worth knowing for somebody here. If you don't actually have specific features you are requesting from the dependency, you should use "default" for the Debian package in the package's build dependencies. That should resolve the subdependencies. So my Debian control file should not list a dependency for error-chain as librust-error-chain-dev, but instead as librust-error-chain+default-dev. I haven't verified this yet because I need to set up a new, reusable schroot for build testing.
|
# ? Sep 20, 2022 18:43 |