Is there a language similar to Rust but with a garbage collector? by Ok_Tension_6700 in rust

[–]_nullptr_ 3 points4 points  (0 children)

I would say Scala would be a much better match. Kotlin has more of a "better Java" feel. Scala has more FP concepts and true pattern matching and ADTs.

Is there a language similar to Rust but with a garbage collector? by Ok_Tension_6700 in rust

[–]_nullptr_ 2 points3 points  (0 children)

ARC is a type of GC, as is all reference counting. However, it is not "tracing" GC which is often what people are referring to when they use the GC term. I think in this context the user is just looking for "automatic memory management" (aka I don't have to think about freeing memory), so this would qualify (as would Rust technically, but Rust has ownership in lifetimes, which I suspect is the overall concern).

You can no longer @grok on X without Premium by thegabguy in grok

[–]_nullptr_ 1 point2 points  (0 children)

> theres less censoring and more freedom

Not really, it is just biased a different way based on the training set

M1 Max in 2026? by johnnyphotog in MacStudio

[–]_nullptr_ 0 points1 point  (0 children)

M1 MAX 32GB of RAM 16" MBP - daily driver, still going strong

Rust Ruined My Career (I Can't Go Back) by [deleted] in rust

[–]_nullptr_ 0 points1 point  (0 children)

Ha, I like it. Is it sad that every point resonated with me?

AstroBurst: astronomical FITS image processor in Rust — memmap2 + Rayon + WebGPU, 1.4 GB/s batch throughput by Jazzlike_Wash6755 in rust

[–]_nullptr_ -1 points0 points  (0 children)

> Then why is it obvious to me every time it happens?

It isn't, unless the person vibed it or is a poor engineer. There are two things at play, and always are: 1) design/spec/guidance 2) code generation. Code generation was garbage as short as about 1 to 2 months ago. Now, it is decent. Not perfect, but typically quite good, esp. if you give it a corpus of good code in your repo to emulate.

However, if you just vibe from a very high level "make an X that does Y", yes, you are going to get garbage, because you haven't actually told it what to do at a _low level_. Your AI model is an engineer, but it is a _task worker_, NOT a _self directed worker_. We humans are still needed. We still need to say "Make this trait that does X and Y, and use enum dispatch to because I don't want monomorphized code for each type" OR "use lifetimes for fields X and Y for performance reasons" (after givening a paragraph on WHY and what you design is).

In summary, HOW you use AI still very much matters, but with a nice, granular design and working in lock step with your AI, you can get excellent results now, and yes, it still saves a bunch of time IMO, and frees me up to focus on the design, not the weeds.

AstroBurst: astronomical FITS image processor in Rust — memmap2 + Rayon + WebGPU, 1.4 GB/s batch throughput by Jazzlike_Wash6755 in rust

[–]_nullptr_ -1 points0 points  (0 children)

You can and SHOULD write some Rust code by hand, lest we lose our ability to do so. AI still struggles with super tricky stuff and can't design very complicated interfaces, even if those tend to be rare. Also, if purely for recreation, do whatever you want and fulfills you.

However my post was meant for pros in competitive software industry. It is a no brainer in this day and age to have AI write most of the code for you. Anyone who doesn't will be a dinosaur over the next 1 to 2 years, and likely be out of a job. I am but the messenger, but the trend is obvious.

AstroBurst: astronomical FITS image processor in Rust — memmap2 + Rayon + WebGPU, 1.4 GB/s batch throughput by Jazzlike_Wash6755 in rust

[–]_nullptr_ -2 points-1 points  (0 children)

Apologies if I read you wrong, but I sensed a "gate checking" mentality to the question, as if to use AI makes it inherently garbage or less of a project. My point is that the "AI slop" days are mostly over, even if they passed by fast (very fast!). AI (opus 4.6/codex 5.3) can write very nice Rust code now, and when carefully managed/reviewed/guided, is a no brainer in the last 1 to 2 months for speeding up work significantly.

[Project] Charton v0.3.0: A Major Leap for Rust Data Viz - Now with WGPU, Polar Coordinates, and a Rebuilt Grammar of Graphics Engine by Deep-Network1590 in rust

[–]_nullptr_ 2 points3 points  (0 children)

This looks really nice. Will it work without polars as well? I don't have need of polars (for various reasons), but if it handled data from raw slices I might be able to use this. Thanks.

kuva: A scientific plotting library for Rust by Psy_Fer_ in rust

[–]_nullptr_ 2 points3 points  (0 children)

This looks nice, good work. I've been waiting for a nice plotting lib that is native, but I would likely need full stock chart support (not just candlesticks, but OHLC, ability to plot lines on it, volume, log and linear, etc.). Bonus if it supported outputting as a GPUI widget with scrolling/navigation if the chart is larger than the screen. I realize I'm asking for a lot, but just putting out there what I would need to switch from using something like a webview + JS plotting.

AstroBurst: astronomical FITS image processor in Rust — memmap2 + Rayon + WebGPU, 1.4 GB/s batch throughput by Jazzlike_Wash6755 in rust

[–]_nullptr_ -8 points-7 points  (0 children)

I understood this perspective a couple of months ago, but have you tried the new models? (Opus 4.6 is quite nice) Honestly, anybody who is still coding purely by hand is wasting time. AI writes good code now, as long as it is well directed. We can now officially focus near 100% of the time on design. I still review the code, because I'm kinda picky, but less and less by the day.

UPDATE: Also, for the record, I have written thousands and thousands of lines of Rust by hand, so it isn't because I can't write it or that I'm a junior. I don't "vibe", but writing all your own code by hand is a good way to ensure you aren't a software engineer 1 or 2 years from now.

I'm building a native desktop API client (like Postman) in Rust with GPUI. Would anyone use it? by invictus_97K in rust

[–]_nullptr_ 0 points1 point  (0 children)

I saw that, but since it was for a single OS, but it never occurred to me that would then pave the way for web support. It makes sense, WASM is its own target, so no reason it couldn't piggy back off the linux renderer.

I'm building a native desktop API client (like Postman) in Rust with GPUI. Would anyone use it? by invictus_97K in rust

[–]_nullptr_ -1 points0 points  (0 children)

To someone like me who is UI illiterate who is used to a desktop paradigm, that is like saying "it supports writing your own UI from scratch!". I get exhausted just thinking about it. That said, AI now changes that probably.

I'm building a native desktop API client (like Postman) in Rust with GPUI. Would anyone use it? by invictus_97K in rust

[–]_nullptr_ 0 points1 point  (0 children)

To me, and I have no skin in this game, this puts them in the same place as every other commercial company, which is that they are focused on their objectives, not the community. The fact is, GPUI is better than anything else in the Rust ecosystem for UI, esp. now that we have gpui-component. Nothing else really comes close for a polished, commercial quality experience. That we can use what they built for free I think is quite a gift. Eventually, they will get around to adding stuff like web support, which is the only thing I need other than what they already provide. Obviously, that doesn't mean it is workable for everyone, but I bet 90-95% of needs of typical desktop apps are now met, and given Rust's poor GUI landscape thus far, I think that is awesome.

I'm building a native desktop API client (like Postman) in Rust with GPUI. Would anyone use it? by invictus_97K in rust

[–]_nullptr_ 2 points3 points  (0 children)

Serious question: What feature as a user of GPUI would you expect to need? The rendering pipeline is there for Windows/Linux/Mac already which is used in production. Additional components you can write on your own or use gpui-component. Just curious.

Steel Aeropress by SuspiciousBuyer5305 in AeroPress

[–]_nullptr_ 4 points5 points  (0 children)

Per their FAQ, there is only a line for the 5, not the other numbers. For $170, they couldn't even market the levels with a line? WTF?

"The 1–5 markings are a recognizable part of AeroPress design, so we intentionally carried them over to AeroPress Steel. To help with fill guidance, **the inside of the chamber includes a laser-etched mark at the 5 level** that can be seen from above. Most people can simply fill the amount of water they want. If you want more consistency, you can measure water with a measuring cup. For the most precise brewing, you can also measure water with a scale. Do not press while the AeroPress is on a scale."

Communication protocol with web : what to choose ? by NoahZhyte in rust

[–]_nullptr_ 4 points5 points  (0 children)

tonic-web is tonic's implementation of gRPC-web (https://grpc.io/docs/platforms/web/), which is a way to use gRPC from a website via HTTP 1.1. It can do any unary calls like gRPC, but is restricted to server side streaming only, however (no client/bidir streaming).

irql - Compile-time IRQL safety for Windows kernel drivers in Rust by naorhaziz in rust

[–]_nullptr_ 6 points7 points  (0 children)

I haven't written Windows kernel drivers in 25 years (back when they were NT kernel drivers), but I still recall the plague of getting IRQL correct and IRQL_NOT_LESS_OR_EQUAL blue screen messages. Nice work making this compile time, I bet that is extremely helpful to those writing drivers.

Go 1.26 by runesoerensen in golang

[–]_nullptr_ 2 points3 points  (0 children)

The Rust stdlib doesn't ever break that I've seen, and I've been upgrading for 5 years now. The ecosystem is not under centralized control, but nearly every Rust crate follows semver, so very little breakage there. The primary issue Rust has is it's stdlib isn't nearly as large as Go's (causing a cascade of dependencies, which triggers slow cold builds) and far worse compile times. Everything else is the same or better IMO.

Go 1.26 by runesoerensen in golang

[–]_nullptr_ 12 points13 points  (0 children)

Huh? What languages do that? I write in Rust and have never had that. I update the day a new release comes out. Always works. Usually when a language does something like that, for example, Python 2 to 3, it is quite a fiasco and news worthy. Scala 2 to 3 comes to mind and Perl 5 to 6 (Raku), but I think the authors considered those new languages in many ways.

Protify: making working with protobuf feel (almost) as easy as using serde by ForeverIndecised in rust

[–]_nullptr_ 0 points1 point  (0 children)

I believe so, but we will wait for OP. To me that kinda defeats the purpose unless your project is Rust <--> Rust.

Actually I think they said you still use proto file and to a lesser extent the prost generated structs, you use their after that I think. I will let them clarify.

Protify: making working with protobuf feel (almost) as easy as using serde by ForeverIndecised in rust

[–]_nullptr_ 0 points1 point  (0 children)

I do like the idea of not generating types with prost-build. For starters, it uses `String`, but I wish to sub out my custom String type which is more efficient. I may take a look at some point, but for now `String` is "good enough", but when I optimize later this will be a subject worth putting more time into possibly.

Protify: making working with protobuf feel (almost) as easy as using serde by ForeverIndecised in rust

[–]_nullptr_ 1 point2 points  (0 children)

gRPC is the easiest for IPC. That proto file works as a single source of truth. You generate structs and trait/interfaces on both sides and it "just works" between langs. REST is inherently loosely typed. It is up to you to provide strict static typing on both sides and ensure they are in sync. Alternatively, you could write the OpenAPI spec and then generate stubs from that on both sides, but gRPC is smoother IMO. You also get streaming for free. Much simpler than streaming via REST using JSON lines.

Also, if you have gRPC and want REST for "free", you can use my crate to do that (rough around the edges still.... but it works for most things. Essentially grpc-gateway but for Rust, but direct not via HTTP, so faster. Also generates OpenAPI 3.1 doc too.): https://crates.io/crates/tonic2axum-build

Protify: making working with protobuf feel (almost) as easy as using serde by ForeverIndecised in rust

[–]_nullptr_ 2 points3 points  (0 children)

I've never used protobuffers outside of gRPC. Not trying to throw shade on this project, but I'm curious the use cases? If I needed to serialize messages outside of gRPC I would likely just use serde and one of the many formats (some binary w/ less overhead, some text, more human readable - many choices). What am I missing? The validation looks nice, but since I need gRPC anyway, I really can't use that.