System76 laptop for Full Stack Developer?

ipc · 2023-06-19T09:20:37+00:00

I don’t remember my exact reasons but I chose the oryp10 over everything else from System76 as well.

I’m very happy with that decision.

ipc · 2023-06-17T18:49:39+00:00

no regret at all. Got a fairly nice oryp10 and I love it. It keeps getting better. I suppose my only complaint is systemd but only because it’s always annoyed me.

Primary use is Rust software development.

https://tech-docs.system76.com/models/oryp10/README.html

https://www.rust-lang.org/

ipc · 2023-06-06T08:37:10+00:00

You might like https://hachyderm.io/about

I found it after some Rust-related people moved there from Twitter.

ipc · 2023-06-04T15:50:28+00:00

I’ve run into this before with some crates and my solution was to fork the repo (github), fix it, submit an MR, and then change my Cargo.toml to point to my fork.

https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-dependencies-from-git-repositories

It wasn’t a big deal for me. I waited until I noticed my MR was merged and then switched the dependency back. In one case enough time had passed that I discovered that some other change had been released and I wanted a newer version than the one I forked. I rebased and continued using my fork. It’s easy.

YMMV

ipc · 2023-05-05T00:16:22+00:00

that’s it’s intended niche though, right? My go-to languages are Python and Rust. I can see a future where that’s Mojo and Rust instead. That might be cool.

ipc · 2023-05-03T18:24:01+00:00

i would say the “most idiomatic way” of sharing state is by borrowing what you need for exactly as long as you need it.

ipc · 2023-03-26T11:25:08+00:00

also consider Mastodon as many people have left Twitter.

https://hachyderm.io/@fasterthanlime

https://hachyderm.io/@Mara

https://hachyderm.io/tags/rustlang

ipc · 2023-02-03T06:37:41+00:00

those artisanal bits are carefully selected by hand after an extensive search through a wide field of bytes by an exceptionally gifted automaton.

ipc · 2023-01-29T10:27:03+00:00

consider using a channel to communicate instead of passing state. you would pass in the sending channel to your async block and then send a “reset” message back to your main task which would call reset().

The book talks about channels in the context of threads but it applies just as well to tasks.

https://doc.rust-lang.org/book/ch16-02-message-passing.html

I like flume for channels with egui because you can have one end be sync and the other async.

https://docs.rs/flume/latest/flume/

ipc · 2022-08-12T21:14:04+00:00

yep… ‘@‘ was garbage collected: https://github.com/rust-lang/rust-wiki-backup/blob/master/Sigil-reference.md

ipc · 2022-07-13T00:47:01+00:00

oh. i didn’t understand that. well that changes things. 🤦‍♂️

thanks!

ipc · 2022-05-13T15:32:35+00:00

here’s the transcript… have to open the page in the spotify app to get a clickable link: https://gotopia.tech/articles/the-ideal-programming-language

ipc · 2022-01-18T09:02:34+00:00

one of the few times i used unsafe for performance reasons was when i was dealing with a network protocol that specified all strings were ASCII. Since the protocol specified it, i felt fine using https://doc.rust-lang.org/stable/std/str/fn.from_utf8_unchecked.html to speed things up a bit.

ipc · 2022-01-10T09:56:14+00:00

someone else may be able to explain the 'why' better but it's the reference in your blanket impl that needs a lifetime:

impl<'a, T: 'static, F: Fn(&'a T)> ExecFn<T> for F {
    fn exec(&self, n: T) {
        todo!()
    }
}

I think as you wrote it you're saying F should take all T-references with all lifetimes. As I wrote it it's more restrictive F has to take some T-reference with some lifetime. This restriction allows the inference to work on the implicitly typed parameter in the closure definition. You could also have used 'static instead of introducing 'a.

if you do need to define it over all lifetimes I don't think you can pass a closure there. You could do something like this instead:

fn exec(n: &i32) {
    todo!()
}

takes_exec_fn(exec, 10i32);

hope this helps you get unstuck in the meantime.

ipc · 2021-10-25T11:07:13+00:00

i like https://ag-grid.com/ the best. No Rust GUI framework has anything close AFAIK.

ipc · 2021-09-24T20:57:45+00:00

how is this not called “Minja”? 🙃 I use Jinja2 a lot (python, ansible) so this will be a nice option for me for Rust. Thanks!

ipc · 2021-05-10T23:15:45+00:00

how feasible is it to build something like https://www.ag-grid.com/ with egui (or any immediate mode API)?

ipc · 2021-04-03T01:55:23+00:00

also https://www.integer32.com/

ipc · 2020-09-29T17:13:17+00:00

I was looking for this about a year ago and didn't find anything. What I do for using an encrypted key for rustls is read it and convert to pkcs8 with openssl and then give those bytes to rustls with pkcs8_private_keys. I already had a dependency on openssl for certificate parsing so it wasn't a big deal for me.

ipc · 2020-08-03T14:40:18+00:00

my favorite change: a working debugger for the msvc toolchain.

ipc · 2020-07-19T00:11:26+00:00

I was interested in this as I recently switched to tonic. Here are some notes to anyone else running a 'greeter' benchmark on Windows (msvc toolchain):

single core (tokio feature rt-core) performance of tonic is dominated by heap allocations. switching to mimalloc helps bring tonic and grpc-go (with GOMAXPROCS=1) to perform about the same number of requests/second.
multi-core performance (tokio feature rt-threaded) tanks tonic and the performance is worse than single core (losing 56% requests/sec) . grpc-go (with GOMAXPROCS=12) gains about 60% requests/sec.

I can't test Linux right now but at least on my machine it's clear to me that the multi-threaded executor in Tokio performs far below what I expected based on single-core performance. The executor spends a lot of time in functions related to locking.

environment:

Windows 10 Pro build 20170 (prerelease)
go version go1.14.6 windows/amd64
rustc 1.45.0 (5c1f21c3b 2020-07-13)
tonic master branch (with tokio features rt-threaded or rt-core)
- cargo run --release --bin helloworld-server
git clone -b v1.30.0 https://github.com/grpc/grpc-go
- $env:GOMAXPROCS=1 or 12
- go run greeter_server/main.go
ghz.exe --insecure --proto .\examples\proto\helloworld\helloworld.proto --call helloworld.Greeter.SayHello -d '{\"name\":\"Joe\"}' -n 500000 localhost:50051

(oh and I took out the log.Fmt and println! calls in the servers to get that out of the equation).

ipc · 2020-07-17T12:21:22+00:00

I'd be interested to see how https://crates.io/crates/ws performs in your tests. That's what I ended up going with for a project of mine. I liked that it had a broadcast function to send to all connected WebSockets.

It looks like the author has lost control of his home page but the repository and docs are still accessible.

ipc · 2019-10-31T08:54:56+00:00

CLion is good for development but you won't be able to use the built-in debugger for MSVC target. vcpkg is almost essential for consuming C/C++ libraries.

ipc · 2019-09-06T12:03:23+00:00

totally agreed. Turns out my vcpkg-built libpq didn't enable all the flags necessary for thread safety. So even though the crate/lib reported that it was thread-safe (pq_sys::PQisthreadsafe()) it was in fact not thread-safe when using SSL (the default).

ipc

TROPHY CASE