hardwaresofton

> Thank you for doing God's work. I wish I'd bought a Firefox phone - I would have been burned, but some people need to be for us to get anywhere. I tried to make up for it by buying an early generation FrameWork laptop.

Good news, it’s not too late, I still have 2 FX0s and 2 others (jk but if you’re in Tokyo maybe not jk)

Also not sure I was doing God’s work, the second app (PWA) I made for FirefoxOS was a Tinder clone using their undocumented API

And definitely no problem with people not buying, not everyone is a first adopter and that’s fine (I’m not either).

That said a slightly too large phone is probably not a high price to pay for appreciably more freedom, just my 2c

> The comments here are awful. What happened to “Hacker” news?

It’s funny because excessive negativity is peak HN (see: Dropbox post) but yeah, it’s amazing how many people are focused on how this couldn’t/doesn’t work than got it could/does.

I bought 4 Firefox phones, am itching for hardware that I truly own in the age of AI, and I’m ready to be hurt again.

This kind of thing is what I come to HN for.

This guy did a 6 year multidisciplinary grind to produce a stunning consumer product. Exemplary

Interesting because the repo only lists a MIT license, with no mention of those requirements. IANAL but those license terms don't seem to be anywhere in the software repository.

https://github.com/basecamp/once-campfire

Supabase consistently delivering massive value to the postgres ecosystem

Dear OP, start a high quality AI code YouTube/Twitch/Substack and you’ll do more “devrel” than they ever could.

If it’s really your favorite thing, your content will be world class.

If you do this, I’ll be your first paid sub. Get in the arena, OP (and maybe don’t quit your day job until you’ve gained much more steam! :)

TIL: https://www.emacswiki.org/emacs/ArtistMode

OP should really mention that they made stackerror. I couldn’t shake the feeling that this read like an ad for stackerror… and of course the author is the crate writer. This feels somewhat disingenuous without a disclaimer that you wrote the lib and there are other ways.

The general advice is good (except for the awkward use of std error), so for anyone who wants to know what rustaceans are actually using:

- std error when it’s required

- anyhow for flexibly dealing with large classes of errors and rethrowing (often in bin crates or internally in a lib crate ), use anyhow::Context to tag errors

- thiserror for building and generating custom errors (in a lib crate)

- miette/eyre for more advanced features

Watch out for exposing error types in public API because then you are bound to push a breaking change if the upstream does.

Anyhow will probably never have a v2 at this point IMO, the entire Rust ecosystem might have to rev!

[EDIT] dont want to suggest that people avoid stackerror, just want to show what other ecosystem projects there are! stackerror seems to fit the hole of anyhow.

Personal attacks like this have no place on HN.

> Contributions to the Zig language or contributions to software using Zig (the latter is the one the post is about as I understand)?

Yes.

I think a contributor that really wanted to help the ecosystem would start in the stdlib and then start moving outwards. Even if it was LLM-assisted, I think it could be high value.

IIRC Loris already has an engine for building websites with Zig, but making sure that every Zig library has docs (similar to rustdocs) might be a great start. It is incredibly useful to have a resource like rustdocs, both the tooling and the web sites that are easily browsable.

Again, maybe everyone in the Zig ecosystem just has amazing editor setups and massive brains, but I personally really like the ease of browsing rustdoc.

> If so, I believe Zig will stay within a niche. Lower entry barriers allow "script kiddies" to easily start withe language, and they eventually will become leading engineers. Only a few people tend to go straight for the highest practice without "playing around". IMHO the reason, why PHP got so popular (it was not good back then, just very very easy to start with).

I agree, but I'd add that the niche they're aiming for is systems programming, so they're probably fine :). The average hacker there is expecting C/C++ or to be near the metal, and I think Zig is a great fit there. They're likely not going to convince people who write Ruby, but it feels reasonable for C hackers.

Also I want to just be clear that I think Zig has a lot of motivating factors! They're doing amazing things like zig cc, unbelievably easy, "can't believe it's not butter" cross-compilation, their new explicit/managed I/O mechanism, explicit allocators as a default, comptime, better type ergonomics. It's a pretty impressive language.

On the one hand, I totally get that pre 1.0 is the wild west (somewhat) and should be. The team is right in jealously guarding their ability to make changes.

That said, others have pointed out that writing documentation and tests helps improve quality quite a bit, and in this case it would also increase usability. I think I'd agree with this stance, but there is no way I could make the statement that even most of the code I've written for public consumption had excellent documentation or examples. So I've got no leg to stand on there, just the armchair.

> And I would argue, writing good, simple, clear, detailed documentation is actually harder than writing code itself.

All the more reason why it must be done! A little silly but from my armchair maybe it's one of those "start with the interface you want and work backwards", but the problem is that approach can be at odds with mechanical sympathy and we know which side Zig lands on (and arguably should land on based on it's values).

This is a good point, but one could make a point for the usefulness of documentation in “thinking like a user” which is a valuable exercise.

I do very much prefer moving fast though, so I get it, docs-later is obviously a very valid way of doing things.

If someone is excited about Zig and wanted to make a difference I guess it’s now obvious where they could have outsized impact!

Yeah, thinking about this attitude positively, maybe it’s a feature — if only hard core people can comfortably figure it out, you get higher quality contributions?

Not trying to imply that’s an explicit goal (probably instead just a resource problem), but an observation

I'm not a Zig PM but the first obvious fix for the issues the OP wrote about is to write better documentation, including usage examples (the more the better, almost to a fault). Also doubles as a good time to reflect on whether the user is having to do too much.

If the tradeoff was absolute performance/avoiding introducing load-bearing performance-lowering abstraction I think that goal was achieved, but DX may have gone out the window.

Yeah sounds like those SaaSes have a broken funnel/aren't doing a good job, because customers are still annoyed. Being second to market doesn't mean you can't be best!

> If anything, someone should just make an AI that sucks in all the things she mentioned and add it to the NPO's pages. As she mentioned, most NPO work is just marketing and fundraising, and hopefully a little bit of doing some of the work you started it for.

Mitchell is definitely a he, but yeah it sounds like most people don't want to do the marketing and fundraising, and I don't think AI is ready to take that on quite yet.

He notes specifically about how interacting with humans is a valuable part of the experience, sounds like they need better automated management/coralling of existing resources, not necessarily AI.

Sounds like a SaaS offering waiting to be built

Thanks! Yeah CPP reference is what I tend to find on the internet, but quite surprised there isn't something a bit more "modern" that combines all these.

Searching also revealed some good university guides, the standards, ETC -- just very surprising that people doing day to day work with C are fine with that tooling-wise, though of course people have jump-to-definition so maybe reading header files is "good enough".

Where does everyone browse the C standard library, posix library, and separately glibc?

Is there any really nice listing/walk through these standard libraries/rustdoc like website?

Does everyone just dig through header files and man pages all day?

I did click that -- it didn't have it listed either...

I think I wasn't clear, I wanted to know which database system people were using (i.e. Postgres, Mongo, etc). You can't even run Postgres in a container without a password these days, how could someone do a whole production deployment without a password.

Why is the database not named?

> I'd argue this is also down to the debug memory allocators in Zig which run a bunch of checks for things like use-after-free. Again, one of the nice things about Zig is that debug mode isn't dramatically slower than release so you're not inclined to turn it off too soon.

Ah another good point -- also excited for what opens up with regards to this approach with managed/explicit I/O. Pretty obvious that permutation testing of async behavior gets unlocked which is nice. The equivalent in Rust would be loom.

> However, one thing that does shock me is that no "reference to stack allocated thing escapes" errors existed. Zig does not help you very much on this front, and I'm stunned that none existed.

TIL -- is everyone just bolting on asan here and sticking to the clang backend for now?

Hopefully the zig strike force will drop by.

Agreed, I really like Zig's explicit allocation (and to be fair, lots of people from Rust like it too[0], it's just such an insane lift that who knows when it will stabilize)

The new "managed" async strategy (I was previously mistaken thinking it was the same as sans-io) is also really intriguing IMO, and feels like a fantastic balance (people in Rust are doing this too, but for the unrelated reason of trying to support various async runtimes).

[0]: https://github.com/rust-lang/rust/issues/32838

> All of that said, there are patterns that will just be harder to reason about in Rust, mostly with self-referential things, and if you area already used to using them a lot, this can be a hassle. If you're used to smaller data structures and data-oriented programming, it will be a lot easier.

Also an underrated chance to be forced to learn about Arenas, most of the time.

1)

Yeah, not everyone is mitchellh -- I'd argue that his intuition was right (expecting to find more issues), there's a reason we don't all write C.

That said, it's great to hear that others are having success with Zig and aren't writing very many bugs.

> To me, the tradeoff of a demonstrably small number of bugs in a system software language in return for the demonstrably faster developer velocity (Zig compiles WAY faster than Rust, Zig wraps C/C++ libraries way easier than Rust, Zig cross compiles way more easily, etc.) is a decent tradeoff for my use cases.

Reasonable points! This is one of the reasons I have on my list to consider Zig at all (that and wanting to write more C), it seems people that like it are wonderfully productive in it.

I really like a lot of the design decisions and watch the streams than Andrew and Loris, Tigerbeetle folks and others do to see the decisions they make. Their managed IO approach is certainly interesting and quite powerful.

Dislike some small petty syntax things (whyCamelCaseFunctions()!?), but that's a me thing.

> For me, programming is about corralling motivation more than anything else. Rust saps my motivation is ways that Zig does not.

Agree with this, anecdotally.

> I love what the Oxide folks are doing. Having someone pwn your big server because of a memory bug? Yeah, I'd reach for Rust in their use cases. Or, if I'm handling credit cards, I'll have a very different set of tradeoffs that swing against Zig. (Although, in that case, I'll probably reach for a GC language in that case so that I don't have to think about memory management at all.)

Yup, Typescript works for me here, and usually the hard parts are offloaded to an external service anyway (e.g. Stripe)

> Zig is simply a much smaller language than Rust. I use Zig because my brain isn't big enough for either C++ or Rust. > > I'm not a 10x programmer, but I still want to get stuff done. Zig and C enable me to do that without bending my brain.

I wouldn't put Rust and C++ in the same league there as far as brain size requirements, but point taken!

Other WAY more qualified people already responded and elucidated on the initial origins of Rust (it used to have a garbage collector!), but I can at least add this:

The definition of "same niche" is doing a lot of heavy lifting.

There's a marked difference between what these tools became and the impression of them along the way and the axes along which they were compared in actuality. In the simple "I need to build a backend" conversation, Rust and Go were comparable long after Rust changed to a "real" systems language -- I'd go as far as to say people still compare them to this day (and Go probably wins that larger niche for many contextual reasons).

I think the point is partially reflected in your own statement -- there are many axes along which Go is not a Java replacement, and is not a Python replacement either. The definition of the "niche" vastly changes the answer.

For example, if you pick the right niche (e.g. HFT) Java meaningfully outperforms Go because high performance Java is... actually high performance -- those millions of man years into the compiler, runtime, etc produced progress. That said both of those languages get trounced by the FPGAs and custom hardware in the end.

I'm not convinced it was always wrong to compare Rust and Go, but the modern understanding of how different they are today is definitely better/I am glad they're more separated/more people know not to directly compare them.

I really feel for new languages that have to compete with Rust.

It’s probably easier than it’s ever been to create a high quality new language but to get as good as Rust has become just takes so much time and collective effort that it can be out of reach for most ecosystems/groups of builders. Getting the language features just right (and including novel stuff) is just the beginning.

Remember when Rust and Go were comparable? Feels like forever ago when they both just looked like “new systems programming languages” a we know how that turned out.

For example Zig is probably the most impressive new language, and it’s got a ton of awesome stuff but the chance that I’m going to adopt it over a language with often comparable performance that is ALSO much safer? Rounds to zero.

Maybe some day I’ll have the brain cells and skill to write code in zig and be confident I’m Not introducing a whole class of gnarly bugs, but it seems like I should just focus my limited brain power on writing high quality Rust code.

See:

https://github.com/neondatabase/neon

The future continues to be AGPL:

https://vadosware.io/post/the-future-of-free-and-open-source...

Well we call them browser agents for a reason, a sufficiently advanced browser is no different from an agent.

Agree it will become a battleground though, because the ability for people to use the internet as a tool (in fact, their tool’s tool) will absolutely shift the paradigm, undesirably for most of the Internet, I think.

I do wonder how much hand wringing there is around tools like uv. The perf of Rust with the usability of python if everyone just ignores the binary blobs and FFI involved.

I personally think uv is a huge brightspot in the python ecosystem and think others will follow suit (i.e other langs embedding rust in tooling for speedups). Wonder what the rest of the ecosystem thinks.

Maybe the uv approach is really the best of both worlds — pythons dx with rusts rigor.