badtuple

Honestly, same. I spend most of my time on Lobste.rs, private blogs, and chat communities rather than HN for this reason. I check in every so often out of habit and can catch some business news here or there...but the joy, growth, and curiosity have moved to smaller bastions specifically to avoid the slop and its glorification.

I've worked with many people over the years. A bunch of product people have struck out to make their own thing now that they can get a feedback loop going. I just keep in touch with people. They know my services are available, so if they have a need they reach out.

The greatest asset in this type of work is genuinely liking people, being good at what you do, and keeping in touch. My email is easily findable for a reason.

I've already done a handful of these gigs for early vibecoded products that had collapsed in on themselves. The scope of work was to stabilize the product and only make existing features work.

The issues have all been structural, not local. It's easier to treat it like a rewrite using the original as a super detailed product spec. Working on the existing codebase works, but you have to aggressively modularize everything anyway to untangle it rather than attack it from the top down.

All of these projects have gone well, but I haven't run into a case where a feature they thought was implemented isn't possible. That will happen eventually.

It's honestly good, quick work as a contractor. But I do hope they invest in building expertise from that point rather than treating it like a stable base to continue vibecoding on.

Interfaces can still be expressed using vtables. You just have to write the vtable yourself rather than have the language do it for you.

Also, Zig's tagged unions (enums with payloads in Rust) are really ergonomic and often what you want instead of interfaces. Alot of languages that use interfaces simply don't expose a good way of doing it so everyone reaches for interfaces by default. But if you don't need an actual interface then this way you don't even have to pay the cost of runtime dynamic dispatch.

That is one theory of creativity. It is extremely far from proven.

Does your opinion change if they use it to train a commercial program to do a similar task?

Ideally you'll be working with the investors and leveraging their expertise and connections. If you're choosing an investor that you'll be working with for years, it's worth looking for things in addition to money.

Something akin to interfaces, but weaker. Right now people roll their own vtables or similar, and that's fine...I actually don't expect these to be added. But because of Zig's commitment to "everything structural is a struct", a very very simple interface type would likely end up being used more like ML's modules.

The need for this jumped out at me during Writergate. People had alot of trouble understanding exactly how all the pieces fit together, and there was no good place to document that. The documentation (or the code people went to to understand it) was always on an implementation. Having an interface would have given Zig a place to hang the Reader/Writer documentation and allowed a quick way for people to understand the expectations it places on implementations without further complications.

For Zig, I don't even want it to automatically handle the vtable like other languages...I'm comfortable with the way people implement different kinds of dynamic dispatch now. All I want is a type-level construct that describes what fields/functions a struct has and nothing else. No effect on runtime data or automatic upcasting or anything. Just a way to say "if this looks like this, it can be considered this type."

I expect the argument is that it's unnecessary. Technically, it is. But Zig's biggest weakness compared to other languages is that all the abstractions have to be in the programmer's head rather than encoded in the program. This greatly hampers people's ability to jump into a new codebase and help themselves. IMO this is all that's needed to remedy that without complicating everything.

You can see how much organizational power this has by looking at the docs for Go's standard library. Ignore how Go's runtime does all the work for you...think more about how it helps make the _intent_ behind the code clear.

I was also curious what direction the article was going to take. The showcase is cool, and the features you mentioned are cool. But for me, Zig is cool is because all the pieces simply fit together with essentially no redundancy or overloading. You learn the constructs and they just compose as you expect. There's one feature I'd personally like added, but there's nothing actually _missing_. Coding in it quickly felt like using a tool I'd used for years, and that's special.

Zig's big feature imo is just the relative absence of warts in the core language. I really don't know how to communicate that in an article. You kind of just have to build something in it.

Sure. That's pretty acidic wording, but I think it's fair to say they want more consumer market share and lock-in helps that.

The original post's point was that by being more open they would encourage more software to be built for their platform. That would create more demand for their products from consumers.

We've diluted the term AI before. Eventually the hype will wear off and we'll call them LLMs, just like what happened to all the previous versions of machine learning or various expert systems.

Vending Machines used to be called robots. Then they stopped seeming magic.

The only thing that works for me is separating things into very distinct "realms" and only having one realm open at a time. No exceptions.

For example one realm is for communication. Slack, Browser, Email, and Calendar can be open. Nothing is really a distraction from anything else here. I'm just being "at work" and communicating in this mode.

Another is for coding. Literally the only things open are vim and a terminal. NO browser and NO Slack. If I need documentation then I didn't design well enough, and design is it's own realm. I should know the libraries I'm using, and anything else is easily handled by vim's autocomplete/intellisense or navigating to the code.

The other two explicit realms are Writing and Design/Planning. There are more adhoc ones, but I really try to avoid adhoc-ness.

Switching realms is a hassle and requires super deliberate action. This means I can't just randomly switch between tabs and code and Slack and email and social media and just...kinda looking at things? That was my main problem. It was too easy to "move" and so I could never stop moving and somehow the entire day was gone. At no point was I goofing off, but my day just disappeared.

The only issue is that work people really really want my dot to be green on Slack at all times. They even give me the room to be on my own, but literally just having Slack open is a weird attention drain and I don't really know how to convey that. This leads to me getting most of my work done after hours and working way too long :/

It's hard enough to view the content I want to see when everyone has "smart" content feeds shoving ads in my face. I work hard to isolate what I look at on Amazon from what I see on YouTube so marketers don't ruin the little bits of the web I'm able to enjoy intentionally. Creating cross-site bleed of account information behind the scenes just makes everything worse for the user who can no longer drive your app...they just have to plop in and let it drive them.

You handwaved the idea of consent by saying it's "clear" to the user. But if there isn't a way to opt out then consent isn't addressed at all.

They didn't say all engineers, and I certainly wouldn't assert that. But I've definitely seen it personally at 2 early stage startups, a moderate-ish size business, and a Fortune 100. Just a handful of people, but they were very open about it. Those around them simply participated in the conversation and didn't judge.

It was never framed as "abuse." It was talked about very casually as a tool to get more work done, and they deliberately sought out an ADHD diagnosis for access.

I'm in no way judging. They DID get a diagnosis and are using it as treatment. The reason it's relevant is because _they_ talked about it as a tool to get more work done, or a way to be "on" after a late night. Not as part of treatment. But there are tons of reasons why that could be, none of which can be assumed.

I guess that's kind of the point. You don't have to choose to be that kind of grown up.

It seems like the point being made is that because an LLM lives within the universe and can't store the entire universe, it would need to "reason" to produce coherent output of a significant length. It's possible I misunderstood your post, but it's not clear to me that any "reasoning" isn't just really good hallucination.

Proving that an AI is reasoning and not hallucinating seems super difficult. Even proving that there's a difference would be difficult. I'm more open to the idea that reasoning in general is just statistical hallucination even for humans, but that's almost off topic.

Any model that trivially depends upon statistics could not do causal reasoning, it would become exponentially less likely over time. At long output lengths, practically impossible.

It's not clear to me that it _doesn't_ fall apart over long output lengths. Our definition of "long output" might just be really different. Statistics can carry you a long way if the possible output is constrained, and it's not like we don't see weird quirks in small amounts of output all the time.

It's also not clear to me that adding more data leads to a generalization that's closer to the "underlying problem". We can train an AI on every sonnet ever written (no extra tagged data or metadata) and it'll be able to produce a statistically coherent sonnet. But I'm not sure it'll be any better at evoking an emotion through text. Same with arithmetic. Can you embed the rules of arithmetic purely in the structure of language? Probably. But I'm not sure the rules can be reliably reversed out enough to claim an AI could be "reasoning" about it.

It does make me wonder what work has gone in to detecting and quantifying reasoning. There must be tons of it. Do we have an accepted rigorous definition of reasoning? We definitely can't take it for granted.

Honestly, on a non-toy project, build times with cgo are _brutal_. I agree with you usually, but when a build time on a beefy computer switches from under a second to >1min you notice it.

Linters and IDEs get slow when they check for errors, tests run slow, feedback drags, and all your workflows that took advantage of Go's fast compile times are now long enough that your flow and mental context disappear.

I'm way more lenient with other languages since the tooling and ecosystem are built around long build times. Your workflows compensate. But Go's tooling and ecosystem assume it compiles fast and treat things more like a scripting language. When that expectation is violated it hurts and everything feels like it's broken.

I'm curious about this too, but haven't been able to figure it out. I want to do some extremely basic detection on user specified videos and it'd be really slick to do it entirely in the browser.

Unless someone has a trick I haven't thought of though, I think I'll have to download it first which isn't nearly as cool :/

He's an adult, let him make his own choices.

Surely this changes depending on the individual giving/receiving? Regardless of intent you have people who would prize both.

I've never worked in a place that had them, but I do know an individual who views it as a source of pride to collect as much as possible from peer bonuses. According to him it's not about the money, it just helps ease impostor syndrome since it's quantifiable and therefore suddenly the only "real" feedback he gets. Since it's quantifiable it renders any soft feedback he gets from his manager worthless in comparison.

Not saying that's common, just saying that's just one of what must be many many interpretations of the incentive structure.

Does anyone have an example of a codebase that uses Design By Contract to an extreme extent? You really only get a sense of the power of patterns like this when you see that power abused. I've greatly enjoyed writing 2 very small codebases in that style...but that doesn't mean I did it well or that it'd hold up after years of maintenance from a revolving door of developers.

Since this thread is very general, I'd like to specifically request anything that'd help one dive into Model Theory. Everything I've found labeled introductory is very dense, and I feel like I'm missing some prereqs it assumes. It's not easy to know what those are though.

I guess one question I'd have is why you think your brain is "operating properly". It's definitely perceiving and constructing a narrative out of those perceptions, but that happens differently for every brain and it really doesn't seem like there's a perfect version of it that's "correct".

If you're willing to accept that you can't really rank or judge modes of mental experience quantitatively on some kind of non-relative scale (which would require access to a "reality" outside yourself), then it shouldn't be too much of a leap to say messing with how it functions within tolerable bounds could be more of an optimization (or equal but just different) to your experience.

This had absolutely nothing to do with the article. Why did you decide to spend your time bashing something you don't use unprompted?

Agreed. I'm going on strike.

I would definitely do so.

I'm a single person who isn't looking to start a family, so I don't really use most of the money I make. It'd give me time to work on my more esoteric/mathy/experimental programming projects that I enjoy. At this point in my career getting job offers is pretty easy, so I wouldn't take a pay cut for no reason...but trading back time sounds super fair.

Of course, I'd have to talk to the company to make sure we agree on what the boundaries and expectations are. Just like with the current 5 day set up, ambiguity can easily be taken advantage of or lead to unexpected outcomes for both parties. That's not a reason to be hesitant, it's just a reason to be explicit and make sure everyone is upfront about discussing it maturely from the outset.

Like others, I've worked at a company who had fridays off in the summer and it really didn't hinder productivity at all. We just planned accordingly.

Does it work if you run `cargo clean` and then `cargo clippy` again? Clippy runs it's lints in an early pass of the compiler/checker. Many IDEs/editors will automatically `cargo check` under the hood to grab errors. Then when you run `cargo clippy`, that part of the compilation is already cached and so clippy doesn't give you any output :(

To my knowledge (it's been a while since I looked) fixing this behavior is blocked on cargo stabilizing something and has been for literal years.

That point of frustration aside, it's worth it...Clippy is an absolutely amazing piece of software. Both for pedagogy and normal development.

EDIT: Just dug up the issue. If you're on nightly you can use `cargo clippy -Z unstable-options` to avoid the clean/rebuild. Hopefully stuff gets stabilized soon. Here's the issue for reference: https://github.com/rust-lang/rust-clippy/issues/4612

Why can't they?

I guess one question is if you can tell the difference. Without reading the book from the youtuber, how would you know you wouldn't like it and it's not just prejudices getting in the way of you giving it a chance? If we can't tell then I'm not sure whether the site being able to makes any difference.

That's awesome! Thanks for the new framing of the algorithm.

Lamport's reply seems unnecessarily dismissive. It's true that different framings and analogy are "weaker" than rigorous understanding. But they are also pathways to it! Digging into something complex is hard, and having a mental model of which pieces interact together and why is one way to make it approachable enough to actually get into the proofs and the rigor.