Recent submissions

Comment · 6 months ago
I’m sort of confused on what prediction markets are going for? Polymarket here said they referred this to the DoJ and are trying to catch users using such insider info, but trading on insider info is the whole point of these markets is it not?

They bill themselves as providing accurate predictions, but the accuracy of those predictions is predicated on incentivizing (financially) users with non public info to share it.

They should probably pick a lane- is it gambling or is it incentivized insider trading for public good (accurate predictions)?

Comment · 10 months ago
This article seems to conflate strong type systems with functional programming, except in point 8. It makes sense why- OCaml and Haskell are functional and were early proponents of these type systems. But, languages like Racket don’t have these type systems and the article doesn’t do anything to explain why they are _also_ better for reliability.
Comment · 11 months ago
They do actually build internal tooling! They key is that it’s actually good enough that feedback to the limited, targeted, and quickly actionable. Microsoft’s internal was immature enough that the general feedback you’d always have is “this is unusable”, which is something the teams building the tools could probably figure out themselves before making the whole company spend time beta testing the tools.

The main point is that the tools need to be of a certain quality/maturity for dogfooding to be effective.

Comment · 11 months ago
I was at Microsoft until July of this year until I left for an SF-based company (not AI though).

The difference between the two with regards to AI tool usage couldn’t be more different- at Microsoft, they had started penalizing you in perf if you didn’t use the AI tools, which often were under par and you didn’t have a choice in. At the new place, perf doesn’t care if you use AI or not- just what you actually deliver. And, shocker, turns out they actually spend a lot building and getting feedback on internal AI tooling and so it gets a lot of use!

The Microsoft culture is a sort of toxic “get AI usage by forcing it down the engineer throats” vs the new “make it actually useful and win users” approach at that new place. The Microsoft approach builds resentment in the engineering base, but I’m convinced it’s the only way leadership there knows how to drive initiatives.

Comment · 1 year ago
The only ones I can really think of are the cloud providers themselves- I was at Microsoft, and absolutely everything was in-house (often to our detriment).
Comment · 1 year ago
> it exposes that it really was never about emissions or combustion or pollution, you either wanted to control people’s freedom of movement

This isn’t the problem- the real problem is that in dense cities, transporting everyone where they want to go via private vehicles just doesn’t work geometrically- see the traffic and parking needs that grow as cities grow assuming private vehicle use only.You end up needing a more space-efficient form of moving people, namely public transit.

Comment · 2 years ago
Comment · 2 years ago
Comment · 2 years ago
To be honest, while I’m not a Tesla fanboy, I don’t think the Cybertruck deserves this hate- as a cyclist I feel worlds safer near a Cybertruck than eg an F150 (though it of course weighs a lot) because of the sloped hood design.

Do I prefer to cycle next to Honda Fits? Of course, but the cybertruck is better than a lot of other truck alternatives

Comment · 2 years ago
Comment · 2 years ago
This is not quite right - a specification is not equivalent to writing software, and the code generator is not just a compiler - in fact, generating implementations from specifications is a pretty active area of research (a simpler problem is the problem of generating a configuration that satisfies some specification, "configuration synthesis").

In general, implementations can be vastly more complicated than even a complicated spec (e.g. by having to deal with real-world network failures, etc.), whereas a spec needs only to describe the expected behavior.

In this context, this is actually super useful, since defining the problem (writing a spec) is usually easier than solving the problem (writing an implementation); it's not just translating (compiling), and the engineer is now thinking at a higher level of abstraction (what do I want it to do vs. how do I do it).

Comment · 2 years ago
Other common modes of transport that lack fixed schedule, route, or stops: - biking - micromobility (scooter-share, etc.) - walking - dial-a-ride transit options

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton