HN user

thatoneengineer

185 karma
Posts5
Comments31
View on HN

Same. Gutsy bet to make in the face of Fable / Mythos, but the multimodal quality is at least a promising technical/ product story to tell. Everyone knows throwing Opus at everything is wasteful and domain expertise should live in the weights eventually; the question is whether foundation model scaling will slow down enough soon enough for that to matter.

Or maybe this is just a warm-up / stopgap and Thinking Machines is betting on finding the next architectural breakthrough that lets it compete with the big foundation models?

Space is big and still very hard to get to. A kilogram of payload in orbit costs several times as much as a kilogram of silver on earth, even after SpaceX's aggressive scaling of capacity. No one's going to be spending that kind of money and effort carelessly. I was more worried about SpaceX becoming monopolistic, so I'm encouraged to see this deal.

Don't project your worries about pollution on Earth-- which is a much bigger problem!-- onto space industry which is at a much much earlier stage. The "burning-up" thing sounds extremely speculative, like you're looking around for reasons to dislike this. Space is exciting and inspiring-- and yes, that includes commercial uses, since realistically we couldn't afford to expand science or exploration in space much otherwise!

You could have said that about any successful technology ever! But for some reason everyone is anxious to say it about AI while being extremely vague about the benefits. (This is especially funny in the mouth of VPs and the like: "we're not sure what AI means for us, but we urgently need to adopt it so we don't fall behind!") If you want me to get deeper into AI tell me what it'll do for me, don't try to scare me with vague FOMO.

I'm an early adopter of AI products myself, but I'm always disgusted when I hear this kind of case being made for them. It's fear-mongering, plain and simple. The cloud, mobile, even crypto sounded like "join us in this exciting new world" at their most hyped. Why does AI so often sound like "get on board or you'll be obsolete"?

If the author really is right, that we're heading for a world with a cutthroat binary divide between the adopters and the non-adopters, then I know in my gut which side I want to be on, and it's not his.

Telescope Ranchers 1 month ago

Why do people get into birdwatching?

It's a hobby, there doesn't need to be much in the way of novel "data" for it to be rewarding. Though considering this guy found a nebula I wouldn't be surprised if there was some. The universe is big (citation needed) and good hobbyist telescopes are quite powerful; you have a lot of sky to explore and could easily be getting the best images ever of any particular patch of it.

Telescope Ranchers 1 month ago

I'm sure it's a lot of work for him, mostly maintenance and cleaning. Also it sounds like the remote operation hardware and software are provided by him-- that can't be trivial and probably means he doesn't break even on a given telescope for a few months at least. Plus whatever it costs him to recruit new customers.

I bet he makes a good living on his labor and whatever capital he has tied up in the land, but it doesn't sound like an easy business.

I stopped reading after the first sentence. Calling something "inherently political" is a self-fulfilling prophecy and intentionally so. It consistently turns out to be an attempt to lay the groundwork for expropriation. No one called the Internet "inherently political" until people built stuff there that other people wanted to control.

Shout out to the apparently large class of programmers who think LLMs make it okay not to understand their own code, yet react with horror when someone suggests porting it to Go or Rust.

If you like this kind of thing, try reading Star Maker by Olaf Stapledon. Similar themes, full novel, even older. It makes for interesting reading in that it more obviously represents a "path not taken" by science fiction (and by science?!) but still has that early-sci-fi spirit of fundamental curiosity.

What article is he referencing in the fourth paragraph? The New Yorker one? I got the impression that it was careful in its reporting and by no means one-sided.

Seems pretty sleazy for him to associate that (based on no evidence!) with the violent attack.

First impressions: LOL, the blunt commentary in the HN thread title compared to the PR-speak of the fb.com post.

Second thoughts: Actually the fb.com post is more transparent than I'd have predicted. Not bad at all. Of course it helps that they're delivering good news!

This very closely resembles my own experience, right down to the timeline.

I don't have an answer, but just seeing this thread has been cathartic for me.

Some of the options I'm considering (all speculative):

- It's okay to be a "hired gun" and switch companies every few years just to ensure you stay interested. Some people's minds are stimulated by novelty and learning; that's not a bad thing! In fact some of the engineers I most respect work as consultants not traditional employees.

- Try working at a more "stodgy" company. Your average Fortune 500 employs more developers than most unicorns and is probably a decade behind the curve in terms of technology-- maybe you can go to one of those, take it easy, and be a hero.

- If it's an option financially, "hire yourself" for a few months to go do a passion project-- hobbyist app? major OSS improvement? creative endeavor?-- and see how it feels.

Ideally, if you can convince yourself something cannot happen, you can also convince the compiler, and get rid of the branch entirely by expressing the predicate as part of the type (or a function on the type, etc.)

Language support for that varies. Rust is great, but not perfect. Typescript is surprisingly good in many cases. Enums and algebraic type systems are your friend. It'll never be 100% but it sure helps fill a lot of holes in the swiss cheese.

Because there's no such thing as a purely internal error in a well-constructed program. Every "logic error" has to bottom out in data from outside the code eventually-- otherwise it could be refactored to be static. Client input is wrong? Error the request! Config doesn't parse? Better specify defaults! Network call fails? Yeah, you should have a plan for that.

Prototaxites 7 months ago

https://en.wikipedia.org/wiki/Prototaxites has more context. Tree sized and shaped living thing that wasn't a plant, which probably fed and reproduced like a fungus but per this latest research wasn't a fungus either, by far the largest known organism on land up to that point, in a time when land animals barely existed. Unsettling!

One does not simply "get Rust performance".

Rust can go that fast because of guarantees its compiler enforces about what the code is doing, that JS emphatically doesn't.

By all means build your tooling and runtime in Rust if it helps, but "you can write high-performance code in JS with no Rust-like constraints" is fundamentally a nonsense pitch.

I disagree. Right now, feedback on correctness is a major practical limitation on the usefulness of AI coding agents. They can fix compile errors on their own, they can _sometimes_ fix test errors on their own, but fixing functionality / architecture errors takes human intervention. Formal verification basically turns (a subset of) functionality errors into compile errors, making the feedback loop much stronger. "Come up with what software we need better than us in the first place" is much higher on the ladder than that.

TL;DR: We don't need to be radically agnostic about the capabilities of AI-- we have enough experience already with the software value chain (with and without AI) for formal verification to be an appealing next step, for the reasons this author lays out.

Aside from just being immensely satisfying, these patterns of defensive programming may be a big part of how we get to quality GAI-written code at scale. Clippy (and the Rust compiler proper) can provide so much of the concrete iterative feedback an agent needs to stay on track and not gloss over mistakes.

Nah, it reads like the normal logic behind the consulting model for open source monetization, except that Bun was able to make it work with just one customer. Good for them, though it comes with some risks, especially when structured as an acquisition.

The unwrap: not great, but understandable. Better to silently run with a partial config while paging oncall on some other channel, but that's a lot of engineering for a case that apparently is supposed to be "can't happen".

The lack of canary: cause for concern, but I more or less believe Cloudflare when they say this is unavoidable given the use case. Good reason to be extra careful though, which in some ways they weren't.

The slowness to root cause: sheer bad luck, with the status page down and Azure's DDoS yesterday all over the news.

The broken SQL: this is the one that I'd be up in arms about if I worked for Cloudflare. For a system with the power to roll out config to ~all of prod at once while bypassing a lot of the usual change tracking, having this escape testing and review is a major miss.