frontpage.
newsnewestaskshowjobs

Made with ♥ by @iamnishanth

Open Source @Github

fp.

Rust cross-platform GPUI components

https://github.com/longbridge/gpui-component
129•xvilka•3h ago•47 comments

Recall for Linux

https://github.com/rolflobker/recall-for-linux
242•anticensor•5h ago•86 comments

Don't forget these tags to make HTML work like you expect

https://blog.jim-nielsen.com/2025/dont-forget-these-html-tags/
53•FromTheArchives•2h ago•23 comments

Microsoft needs to open up more about its OpenAI dealings

https://www.wsj.com/tech/ai/microsoft-needs-to-open-up-more-about-its-openai-dealings-59102de8
83•zerosizedweasle•1h ago•45 comments

Should LLMs just treat text content as an image?

https://www.seangoedecke.com/text-tokens-as-image-tokens/
37•ingve•6d ago•33 comments

Geoutil.com – Measure distances, areas, and convert geo data in the browser

https://geoutil.com
54•FreeGuessr•6d ago•7 comments

WorldGrow: Generating Infinite 3D World

https://github.com/world-grow/WorldGrow
35•cdani•3h ago•21 comments

Artifact (YC W25) is hiring engineers in NYC to build modern ECAD

1•antonysamuel•53m ago

Why I'm teaching kids to hack computers

https://www.hacktivate.app/why-teach-kids-to-hack
106•twostraws•4d ago•39 comments

You are how you act

https://boz.com/articles/you-are-how-you-act
97•HiPHInch•1h ago•58 comments

How I turned Zig into my favorite language to write network programs in

https://lalinsky.com/2025/10/26/zio-async-io-for-zig.html
253•0x1997•12h ago•90 comments

Show HN: Write Go code in JavaScript files

https://www.npmjs.com/package/vite-plugin-use-golang
84•yar-kravtsov•7h ago•25 comments

What Happened to Running What You Wanted on Your Own Machine?

https://hackaday.com/2025/10/22/what-happened-to-running-what-you-wanted-on-your-own-machine/
128•marbartolome•4h ago•53 comments

Corrosion

https://fly.io/blog/corrosion/
19•cgb_•4d ago•5 comments

If your adversary is the mossad (2014) [pdf]

https://www.usenix.org/system/files/1401_08-12_mickens.pdf
148•xeonmc•4h ago•97 comments

Canada Set to Side with China on EVs

https://www.thewirechina.com/2025/10/26/canada-set-to-side-with-china-on-evs/
32•eatonphil•1h ago•21 comments

You already have a Git server

https://maurycyz.com/misc/easy_git/
572•chmaynard•1d ago•378 comments

Show HN: MyraOS – My 32-bit operating system in C and ASM (Hack Club project)

https://github.com/dvir-biton/MyraOS
201•dvirbt•16h ago•43 comments

Structure and Interpretation of Classical Mechanics (2014)

https://tgvaughan.github.io/sicm/toc.html
49•the-mitr•8h ago•16 comments

Unexpected patterns in historical astronomical observations

https://www.su.se/english/news/unexpected-patterns-in-historical-astronomical-observations-1.855042
6•XzetaU8•3d ago•0 comments

Sandhill cranes have adopted a Canada gosling

https://www.smithsonianmag.com/science-nature/these-sandhill-cranes-have-adopted-a-canadian-gosli...
111•NaOH•4d ago•26 comments

An overengineered solution to `sort | uniq -c` with 25x throughput (hist)

https://github.com/noamteyssier/hist-rs
80•noamteyssier•4d ago•55 comments

Why JPEG XL Ignoring Bit Depth Is Genius (and Why AVIF Can't Pull It Off)

https://www.fractionalxperience.com/ux-ui-graphic-design-blog/why-jpeg-xl-ignoring-bit-depth-is-g...
72•Bogdanp•4h ago•42 comments

Ken Thompson recalls Unix's rowdy, lock-picking origins

https://thenewstack.io/ken-thompson-recalls-unixs-rowdy-lock-picking-origins/
185•dxs•19h ago•31 comments

Sphere Computer – The Innovative 1970s Computer Company Everyone Forgot

https://sphere.computer/
73•ChrisArchitect•3d ago•7 comments

Are-we-fast-yet implementations in Oberon, C++, C, Pascal, Micron and Luon

https://github.com/rochus-keller/Are-we-fast-yet
71•luismedel•13h ago•19 comments

A definition of AGI

https://arxiv.org/abs/2510.18212
247•pegasus•18h ago•400 comments

We saved $500k per year by rolling our own "S3"

https://engineering.nanit.com/how-we-saved-500-000-per-year-by-rolling-our-own-s3-6caec1ee1143
243•mpweiher•15h ago•191 comments

A bug that taught me more about PyTorch than years of using it

https://elanapearl.github.io/blog/2025/the-bug-that-taught-me-pytorch/
402•bblcla•3d ago•75 comments

Feed the bots

https://maurycyz.com/misc/the_cost_of_trash/
243•chmaynard•1d ago•171 comments
Open in hackernews

Rust cross-platform GPUI components

https://github.com/longbridge/gpui-component
126•xvilka•3h ago

Comments

nu11ptr•2h ago
This looks to be one of the most complete Rust UI creates (in terms of available widgets/components), but unfortunately has almost no usage (yet). I do see their docs are coming along now. Another very complete one is fyrox-ui used by the fyrox game engine: https://crates.io/crates/fyrox-ui. Again, not really used/known outside of fyrox.

The Rust UI scene is maturing, but the most popular options (iced, egui, dioxus, slint, etc.) aren't even the most complete component-wise atm as far as I can tell.

UPDATE: This honestly looks incredible and makes huge strides in the Rust UI landscape. You can run an impressive widget gallery app here showing all their components:

https://github.com/longbridge/gpui-component/tree/main/crate...

Just "cargo run --release"

airstrike•1h ago
> The Rust UI scene is maturing, but the most popular options (iced, egui, dioxus, slint, etc.) aren't even the most complete component-wise atm as far as I can tell.

I think part of the issue is that they're still changing so much as we speak. But there's real momentum here and n=1 but I've been able to build incredibly rich, enterprise-ready UI with Rust today.

nu11ptr•1h ago
> I've been able to build incredibly rich, enterprise-ready UI with Rust today.

Which UI crate did you use? The word "enterprise" caught my eye. So far I haven't found a Rust UI crate that I found rich enough, so I'm curious your experience.

galangalalgol•1h ago
I think you'll find two definitions of enterprise ready. People who make UIs and are comparing a UI crate to see how it stacks up, and people who write business logic in rust and only care that they were able to make a gui work without switching to some other language. I would put my org in the second situation. Someone bought the thing and didn't complain so good enough I guess. We were using egui.
nu11ptr•1h ago
Ahh, gotcha. Yeah "enterprise" to me meant: "I can write/maintain a UI rich/polished enough to pass as a 'shrink wrapped' app to my end users".

Thanks for the reply.

airstrike•54m ago
FWIW that reply was from a different person :D

In my case I did mean "I can write/maintain a UI rich/polished enough to pass as a 'shrink wrapped'"

galangalalgol•16m ago
The notion of shrink wrapped software dates us I think? But to that end, I have elements of so many different native looks jumbled around in my head all the way back to amiga workbench (deluxe paint was the best), that anything without really obvious flaws like off centered text or unresponsive buttons feels shrinkwrappable to me. By my standard any of these looks is enterprise ready. I remember someone at MS looking at a gui made by a team my friend was on and mocking it for looking like it was out of tron with saturated colors on a black background in high contrast instead of "modern" 3d grey buttons. It looked a lot more like the linked UI than anything MS was producing at the time. So there is the fashion aspect of it. You want to stand out, but not too much. I think that is the aspect I'm unable to judge. If everything is in the first or second place I look, I just won't care.
airstrike•55m ago
I used `iced` but admittedly I also used a lot of elbow grease. Custom Theme, custom widgets and lots of passion to get it to look Just Right.
nu11ptr•39m ago
Cool. Any publicly available source code? If not, any screenshots at least? I'm curious as what Iced is capable of (with extra widgets/themes/etc. like you mentioned).
nicce•1h ago
> UPDATE: This honestly looks incredible and makes huge strides in the Rust UI landscape. You can run an impressive widget gallery app here showing all their components:

> https://github.com/longbridge/gpui-component/tree/main/crate...

> Just "cargo run --release"

Very impressive! Only thing I am concerned over is that it uses around 900 dependencies. But I don't know whether it much for GUI applications.

nu11ptr•47m ago
That did seem excessive to me as well. I do worry about the DX of trying to work on an app with this. After each edit, I would expect a solid compile time to simply try your work.
nicoburns•21m ago
I don't think GPUI has it integrated yet, but Dioxus's Subsecond tool [0] implements binary hot-patching for Rust apps which can help alieviate this problem.

The other thing you can do (which is popular in the Bevy community) is to compiile the "core runtime" into dynamic library. Then you don't need to recompile that set of crates for incremental builds.

[0]: https://github.com/DioxusLabs/dioxus/tree/main/packages/subs...

nu11ptr•13m ago
> The other thing you can do (which is popular in the Bevy community) is to compile the "core runtime" into dynamic library. Then you don't need to recompile that set of crates for incremental builds.

I'm curious as to what this means exactly. Are you saying keep the UI stuff in a separate crate from rest of app or ???. And just a separate or an actual dynlib? (wouldn't that imply C ABI? would make it a pain to interface with it)

matu3ba•28m ago
Since you think the UI scene is maturing: Where do I find 1. design docs and 2. debugging infra docs (Validation, Testing, Stepping, Logging, Tracing, Recording, Scheduling, Reversal Computing as typical ones) and/or how to apply them ?
unwind•2h ago
That showcase application (other than Zed) looks awesome, but the very fancy-looking home page [1] fails to have a one-liner explanation of, uh, what the application does. Please consider fixing.

[1]: https://longbridge.com/desktop/

nicce•1h ago
I guess they expect that most people come there from the top level domain. (https://longbridge.com)
kennydude•2h ago
Looks great for those using Rust - however I do wonder how well this works, if at all, under screen readers and other accessible tech?
Oxodao•1h ago
my #1 question each time I see a new UI framework
jacquesm•1h ago
"Let's get the volume first, then worry about accessibility"

That's the typical answer to these questions. Unfortunately, unless you bake it in from day #1 that's not so simple to fix afterwards.

jeroenhd•1h ago
Haven't tried running the code myself, but their API docs mention accessibility at least: https://longbridge.github.io/gpui-component/docs/components/...

Assuming the docs are correct, the UI controls seem ARIA compliant as long as you bother implementing the necessary descriptions and labels.

agluszak•2h ago
I find it sad that a lot of foundational open-source software is created/maintained by trading/crypto/money laundering companies. But OTOH it's great that they at least contribute _something_ to the society!
baq•1h ago
Bitcoin ethos (as in, the original 'banks are broken, let's fix this') is kinda similar to the hacker ethos ('this thing/program is broken, let's fix this'), so maybe this shouldn't be too surprising? Short term pain for long term gain etc.

(disclaimer: I think bitcoin is dumb, but the market disagrees)

nicce•1h ago
> (disclaimer: I think bitcoin is dumb, but the market disagrees)

I believe that market is quite controversial. Most people know that bitcoin is a bit dump, but they buy it regardless because they believe they profit from it when they do that as part of larger group. A very interesting social experiment with the mix of market manipulation. It is less about stability, independence or usability of the currency, but more about the opportunity of profit.

philipallstar•1h ago
I doubt that a lot of it is.
bezbac•11m ago
gpui itself is maintained by the folks at https://zed.dev.

Also, Longbridge, who seem to be using this GPUI component library for their Longbridge Pro [1] app, look to me like a regular online brokerage company. What is your issue with that?

1: https://longbridge.com/desktop/

UndyingHorse•1h ago
Why is the average binary size 10MB? Does it embed ICU data?
berkes•38m ago
> By default, Rust optimizes for execution speed, compilation speed, and ease of debugging rather than binary size, since for the vast majority of applications this is ideal. But for situations where a developer wants to optimize for binary size instead, Rust provides mechanisms to accomplish this.

https://github.com/johnthagen/min-sized-rust?tab=readme-ov-f...

nicoburns•27m ago
I can't speak for GPUI specifically, but in general for Rust UI toolkits I'm seeing about 10-15mb for an O3 build with LTO enabled and when including things like ICU data, a WGPU-based renderer, SVG rendering support, and a "full fat" async HTTP client. More minimal builds with features disabled and/or Os/Oz can bring that down to more like 5mb.

(obviously you can also take things much higher by building more functionality into your application, but that gives you an idea of the kind of "base size" achievable).

ramon156•1h ago
Although its still very vertically scoped for zed, I'm way more hyped about this UI than iced, dioxus ui, gtk-rs, etc. because of how complete it already is in an early stage.

Then again I love zed so I might be biased.

wongarsu•1h ago
Rust certainly needs more GUI component collections. There are lots of GUI toolkits, but a comparatively small number of prebuilt components you can use with any of them.

This collection looks quite useful, though the component list is mostly indistinguishable from a list of components for a web framework. The webview component is the only one that seems somewhat specific to native applications. So for something like a file-open dialog you would still have to pull in something like rfd [1] and lose styling consistency

1: https://docs.rs/rfd/latest/rfd/

patwoz•1h ago
You should always use the native file picker and not shipping your own. That’s a good thing.
nu11ptr•1h ago
Even though most UI libraries now draw their own widgets some native integration is almost always used/desired. Those integrations are typically: keyboard short cuts, native system menu (macOS), native file dialogs, and (sometimes) native context menus. I'm sure there are others I'm forgetting, but these minimal integrations are a good thing as they give the user some sense of familiarity.
filleduchaos•39m ago
Not just a sense of familiarity; you will simply never build the full spectrum of a file explorer's functionality in a custom file dialog, that would be a complete waste of engineering time. And many more users than you'd expect benefit from the fact that native file dialogs are actually full-fledged explorers. For example, I fairly often find myself quick-previewing a file to be sure it's the correct one when I select it.
berkes•43m ago
> lose styling consistency

Yes. And that is (almost always¹) a good thing.

Only the designers of an app, product-owners etc. want their app to "look consistent over platforms".

Your users want the file-dialog, window-chrome, menus etc consistent too. But for them consistent means consistent with the 20+ other applications they use on a daily base. So native.

¹ Obviously some software excepted. E.g. categories like "expert software" like Blender, AutoCAD, Photoshop/CS, where dialogs must a) be optimized for their niche workflow and b) remain consistent for that user when they upgrade their OS or move between OSes. But that's an exception. Your TODO-list app or PDF reader almost certainly is not that.

SilverSlash•1h ago
I was expecting something ugly but these actually look beautiful!
fidotron•1h ago
Is this native as in "not web" or native as in actually using native text entry and scrolling widgets? There is quite a huge difference as the Java world discovered.
nu11ptr•1h ago
Pretty sure native as in "not web". AFAIK, everything is drawn using the various GPU APIs (GPUI started with Metal on macOS, for example).
mdhb•1h ago
Same model as Flutter which is a million times more pleasant to write and mature at this particular use case which I don’t actually think Rust is well suited to generally speaking.
nicoburns•30m ago
Rust's definitely well-suited to writing the low-level infrastructure pieces (the implementations of the renderer, layout, text, etc). You really want something with fast and predicatable performance there. Whether it pans out for writing actual applications we'll have to see, but a lot of big popular applications are written in C++ which is surely less suitable.
hsn915•1h ago
I think it's native as in "native executable".

GPUI is not "native OS widgets".

meindnoch•1h ago
Native as in "not web". No OS integration.
_bent•7m ago
macOS is the only OS you can write native applications for. On Linux there are with GTK and QT two different GUI frameworks that could be considered native on some distros. And on Windows there are so many different frameworks and approaches used by MS for the shell that even a Webview could be considered native
brainless•1h ago
This looks very good from the screenshots. I will try this as quickly as I can. I have been building with egui and have tried Iced, Slint and Makepad.

I built (agentic coded) a stocks viewer app for Indian stock market data: https://github.com/brainless/Indistocks. It was a fantastic experience as to how easily I could build a GUI app.

My main product also uses egui: https://github.com/brainless/nocodo. It used to have a web app frontend and I moved to desktop app after the experiment with Indistocks. The experience has been really good, also coded with agents.

Desktop apps are fun and even on my somewhat old and slow laptop (i5 8th gen, 16 GB RAM, 2GB nvidia dedicated graphics), they are so much faster than web apps on Chrome (on Linux). I want desktop apps to make a big comeback, we could use so many old devices.

h4x0rr•45m ago
Hola, finally a good rust ui framework that's not dependent on web
h4ch1•40m ago
GPUI and GPUi components are the two things I'm watching very closely while evaluating truly native GUI development.

Still waiting to see more general use before attempting to port my Svelte UI for a Tauri application but it honestly looks incredible.

Big ups to the guy(s) at Longbridge.