Hacker News, Distilled

Immutability and Rebinding in Elixir

• Elixir variables are immutable values with rebinding: assigning x = x + 1 creates a new value and binding, old references don’t change.
• Some see rebinding and in-place mutation as equivalent at the mental model level; others stress a key guarantee: a function’s local variable cannot be changed “behind your back” by other code.
• Process dictionaries and message passing are cited as the main ways state actually changes; observing mutation always goes through explicit function calls or receives.

Comparison with Haskell, SSA, and Other Paradigms

• Haskell’s immutability is stricter: bindings can’t be reassigned; shadowing creates new scopes. Mutable references (e.g., IORef, State monad) exist but are explicit.
• Lazy infinite data structures are discussed: Haskell’s infinite lists vs Elixir’s Stream/Stream.unfold. Elixir supports similar patterns but less pervasively and less elegantly.
• Some note that compiler IRs like SSA also treat assignments as new bindings, but that doesn’t make C/C++ “immutable” at the language level.

Actor Model, Concurrency, and Serialization

• GenServers/processes are described as owning state and serializing all mutations through a mailbox, avoiding shared-memory races.
• This model is praised for predictable concurrency and local reasoning, but some find it cognitively heavier and less intuitive than mainstream mutable models.
• Comparisons are made to JS’s single-threaded event loop: serialization within handlers simplifies reasoning, though true parallelism still needs extra constructs.
• Rust and Clojure are cited as examples of “structured mutability” (ownership, atoms, etc.) that control who can mutate and when, without full immutability.

Referential Transparency and Reasoning

• Rebinding within the same scope can break simple equational reasoning; you must scan all prior lines for reassignments.
• Others argue it’s syntactically equivalent to nested let-blocks and can still support clear reasoning if used sparingly.

Performance and Memory Concerns

• Questions are raised about constant allocation and copying in immutable systems.
• Responses point to structural sharing, GC, compiler optimizations, and the fact that apparent copies may be optimized out.
• Elixir/Erlang are not the fastest for raw computation but shine under high concurrency; Phoenix’s microsecond-level latencies are given as anecdotal evidence.

Overall reaction to “do what you love” and money focus

• Some readers found the essay motivating, especially younger engineers considering entrepreneurship.
• Others saw it as out of touch with current costs of living, debt, and weak safety nets; “making a little money” is viewed as unrealistic for many.
• Several argued the piece assumes your passion is monetizable and that you’re relatively privileged.

Capitalism, Marxism, and system-level critiques

• Long subthread debates economic systems: subsistence, despotism/feudalism, Marxism/socialism/communism, and capitalism.
• One side: capitalism is the only system that “works,” Marxist attempts consistently devolve into despotism and mass misery.
• Counterpoints: historical “Marxist failures” didn’t meet Marx’s stated preconditions; others reject “never been tried” as a No True Scotsman move.
• Multiple comments advocate mixed economies: regulated markets, social protections, and focus on fighting corruption and regulatory capture.

Inequality, fairness, and taxation

• Disagreement over whether wealth inequality is an inherent flaw in capitalism or a side effect that can be managed.
• Debate on whether economic inequality is “natural” because different interests yield different pay, vs. whether that justifies people lacking healthcare, housing, and basics.
• Extended exchange on tax burdens:
  • One side cites IRS data showing top earners pay higher income tax rates.
  • Others argue this ignores unrealized gains, preferential capital gains rates, loss offsetting, and wealth concentration.
  • Some propose taxing wealth/asset growth more like income, or aligning capital and labor tax rates.

Entrepreneurship vs stable employment

• Many practical stories: some quit too early and regretted it; others validated on the side first; some built startups then returned to employment richer in skills.
• Advice ranges from “go for it while young and unencumbered” to “only jump once your startup can pay your bills” to “wait until financially secure, then pursue passion.”
• Several note PG and VCs have a vested interest in encouraging more startups, and frame the essay as a sales pitch that underplays the downside for most founders.

Passion, work, and life design

• Comments stress the difference between “passion” and viability: being 1000th-best in a field (athletics, art, pottery) often pays poorly.
• Some argue the key is aligning what you love with what the market pays for; others emphasize contentment and non-monetary richness.
• Debate over whether to prioritize adventurous “discovery” in youth vs. securing financial stability first.

Geography, class, and lived experience

• Strong split between people in high-cost U.S. cities and those in rural/smaller towns or outside the U.S. on whether average incomes can support a dignified life.
• Several highlight global and domestic poverty, weak U.S. safety nets, and medical risk as reasons money must be prioritized.

Role and Intended Use

• Many see Web Components (WCs) primarily as a distribution mechanism: build a UI element once and use it across any framework (or none), including third‑party sites and micro‑frontends.
• They are not viewed as a full application framework: they don’t solve state management, routing, or app‑level data flow by themselves.
• Best framed as browser‑native, framework‑agnostic custom elements that encapsulate structure, styling, and behavior.

Adoption and Ecosystem Dynamics

• Despite being in browsers, WCs are seen as under‑marketed and overshadowed by React/Vue ecosystems and employment incentives.
• New devs often follow social proof and jobs, not platform primitives; framework authors are frequently skeptical and see WCs as a failed or blocking experiment.

Performance and “Interop Tax”

• Critics worry about an “interop tax”: each WC library shipping its own runtime, compounding JS size and long‑term bloat.
• Supporters counter that many runtimes are small, most apps already ship far more JS (especially React), and typical WC use (few heavy components) keeps overhead acceptable.

Shadow DOM, Styling, and Isolation

• Strong split:
  • Pro: Shadow DOM gives CSS isolation, protects against host styles and name collisions, good for embeddable widgets and multi‑team systems.
  • Contra: Makes theming and global styling harder, interacts badly with Tailwind/Bootstrap, testing, scraping, browser extensions, and user CSS.
• Many WC users avoid Shadow DOM for app UIs, using light DOM only; some call Shadow DOM the most oversold part of WCs.

Developer Experience and Tooling

• Raw WC APIs are described as low‑level, verbose, and “wart‑y”; common advice is to use a helper framework like Lit or Stencil.
• Complaints include: awkward lifecycle, slots requiring Shadow DOM, form integration issues, inability to unload/reload different versions, and weak server‑side rendering/hydration story.
• Others report good experiences building apps with “light DOM WCs + small templating (e.g., lit‑html)”, valuing reduced dependencies and long‑term stability.

Good Fit Use Cases

• Embeddable widgets (chat, maps, tables, emoji pickers), cross‑framework design systems, partner/affiliate embeds, and progressive enhancement on otherwise server‑rendered pages.
• Particularly attractive where teams can’t afford ongoing framework churn or dependency hell.

Critiques and Limitations

• Some argue WCs replace one set of problems (framework lock‑in) with another (platform complexity, awkward APIs).
• Safari still lacks full WC support (no customized built‑in elements).
• A vocal minority is strongly negative, calling WCs overengineered, poorly designed for real apps, and inferior to modern frameworks’ component models.

Meta: Frontend Culture

• Thread repeatedly notes “tech tribalism”: frameworks, WCs, and related tools are treated like religions, making balanced discussion difficult.

Overall sentiment toward progressive enhancement

• Many commenters strongly endorse the guidance and wish more of the web followed it.
• Several report personal frustration that sites fail completely without JavaScript for content that could be plain HTML.
• Gov.uk is praised for clear writing, consistent design, and for prioritizing accessibility and simplicity.

SPAs vs server-rendered / multi-page apps

• Common view: most apps that are basically “forms and tables” should be HTML + CSS with minimal JS; SPAs often add huge complexity for marginal UX gain.
• Others argue SPAs are not inherently inaccessible or broken; careful implementations can preserve history, focus, back/forward, and assistive tech.
• Several say SPAs make sense when the app is offline-capable or “desktop-like” (e.g., Google Docs, graphics tools).

Accessibility, performance, and reliability

• Progressive enhancement and plain HTML “get a lot for free”: navigation, back button, refresh, error recovery, assistive tech.
• SPAs must reimplement these behaviors, and many do it poorly, leading to broken keyboard navigation, links, and form behavior.
• JS bloat, heavy dependencies, and client-side frameworks are blamed for slow load times, high CPU use, and poor experience on low-end devices.

Developer experience, complexity, and incentives

• Recurrent theme: modern frontend stacks are vastly more complex than necessary; teams spend time on tooling, builds, and dependencies rather than user needs.
• Some see frontend as a “jobs program” or CV-padding: complex stacks are chosen to stay trendy, appear “serious,” and help promotions.
• Others counter that large, evolving UIs have inherent complexity; component frameworks help with modularity, styling, testing, and state.

Government context vs private sector

• Government services must work for nearly everyone, including old devices, JS-disabled setups, and assistive technologies.
• Businesses often accept partial accessibility and chase flashy SPAs, especially for demos and internal optics.

Frameworks and alternatives

• Mixed views on React: seen as powerful but over-complex with hooks.
• Some prefer Svelte, HTMX, Alpine, Livewire, Mithril, or classic SSR (Rails, Django) as simpler, more standards-aligned approaches.
• Desire expressed for “component frameworks without SPA routing/state” and for HTMX-like capabilities baked into browsers.

Critiques of the guidance

• Some say the article overstates SPA drawbacks or feels stuck in early-2000s thinking, noting modern SSR/hydration and accessible SPAs.
• Others think the language (“should consider”) is softer than the intent, especially in a governmental context.

Nature of the cargo and level of risk

• Ship is carrying ~20,000 tonnes of ammonium nitrate, several times the Beirut 2020 quantity; some compare blast potential to a small nuclear weapon in yield, though others say actual damage would differ.
• Debate on danger: some say storage/packing makes accidental detonation unlikely unless contaminated (e.g., with fuel oil or organics) or heated in a confined fire; others stress ammonium nitrate can decompose explosively on its own under the wrong conditions.
• Several references to past disasters (Beirut, Oppau, Texas City) used to argue both “this is a genuine megabomb” and “it still requires a chain of failures or intent.”

Unusual voyage and port refusals

• Route (Russia → Norway → attempted Baltic → now Channel/Malta) is seen as odd; many ports (Norway, Sweden, Lithuania, Denmark, UK-linked) reportedly refused docking or passage due to cargo risk and vessel damage.
• Confusion over Baltic access: clarified that some refusals happened by communication before the ship physically entered the Baltic.
• Some argue the ship is simply searching for a port that will allow repairs/unloading; others note distance sailed exceeds distance back to Russian ports and find that suspicious.

Hybrid warfare vs benign explanation

• One camp argues this fits Russian “hybrid warfare”: using a damaged, explosive-laden ship to menace NATO ports with plausible deniability, paralleling sabotage, cable cuts, GPS jamming, and “disposable” agents.
• Another camp calls this speculative “megabomb” fearmongering, noting lack of exclusion zones and asserting it’s more likely a damaged freighter in a bad commercial/insurance situation.
• Middle-ground views: even if intent is unclear, Russia’s broader behavior justifies extreme caution.

Fertilizer economics and sanctions

• Ammonium nitrate is framed as both fertilizer and an energy-intensive product tied to cheap Russian gas.
• Discussion that fertilizer imports from Russia to Europe have increased for some types (e.g., urea), underlining that such shipments are normally routine and economically important.

What should be done with the ship

• Suggestions range from: keep it outside territorial waters; tow it to remote fjords; offload at sea to smaller vessels; return to a Russian port; or in extremis evacuate crew and detonate far offshore.
• Environmental impact of sinking or detonating at sea is debated; some see fertilizer release as minor, others as serious.

Nutrient Cycling and Biomass Removal

• Major concern: schemes that bury or freeze whole plants also lock away nitrogen, phosphorus, and other nutrients needed for ongoing agriculture.
• Some suggest partial processing: burn wood, capture CO₂ as carbonates, and return the nutrient-rich residue; or pyrolyze biomass so most nutrients are driven off and can be recycled.
• Others note existing agricultural practice of building humus in topsoil, but scaling this to climate impact is unclear.

Biochar and Other Biomass-Based Sequestration

• Pyrolysis to produce charcoal/biochar is repeatedly proposed as simpler and more stable than freezing: stores mostly carbon, can enhance soils, and is ancient/low-tech.
• Pushback: simple calculations suggest you’d need to convert “all plant matter several times a year” to offset emissions; scale is the core problem.

Freezing-Pile Proposal: Practical Concerns

• Structural and thermal questions: can pipes withstand the weight; can a frozen core really persist through summers; what about rain infiltration?
• Proponents argue most of the mass would remain frozen, with only a thin decomposing shell; critics worry about water percolation, loss of insulation, and long-term thaw.
• Methane and nitrous oxide from anoxic zones in the pile could be significant, possibly negating benefits; mitigation strategies are unclear.
• Risks like spontaneous combustion of wet biomass are raised.

Scale, Thermodynamics, and Efficiency

• Debate over direct air capture (DAC): some call it “thermodynamically unviable” in practice; others counter that while energy- and cost-intensive, physics doesn’t forbid it and waste heat is negligible vs greenhouse forcing.
• Photosynthesis is acknowledged as relatively inefficient compared to solar PV, limiting biomass-based approaches.
• Several comments emphasize that any biomass or DAC solution must be judged mainly by scalability and full energy/transport cost.

Alternative Sequestration Schemes

• Radical concept: convert captured carbon to silicon carbide and bury it in deserts as an effectively permanent sink; criticized as massively energy-intensive and more suitable as sci‑fi or a hypothetical doomsday device than as mitigation.
• Ocean fertilization is floated as attractive given ocean area and natural deep sequestration; others call it risky for ecosystems and physically vulnerable to storms and tectonics.
• Simpler ideas include planting fast-growing or long-lived trees, then either using harvested wood in long-lived structures or burying it under coal-forming conditions.

Renewables, Energy Growth, and Substitution

• Strong thread arguing that rapidly expanding solar/wind plus electrification (EVs, heat pumps) is the primary lever; solar is far more efficient at capturing sunlight than crops.
• Some highlight that solar additions now rival or exceed demand growth, suggesting fossil use will peak soon; others note fossil extraction is still rising and Jevons-type rebound effects remain.
• Several criticize “primary energy” metrics as misleading: electrification can cut total energy demand by 2–5× for many end-uses.

Policy, Carbon Taxes, and Equity

• Carbon taxes are widely viewed as powerful but politically difficult.
• Concerns: regressivity (hurting poorer households using dirtier energy), backlash if people are locked into high‑carbon systems, and the need for rebates or targeted support.
• Examples are given of per-capita rebates that partially offset regressivity; others argue strong taxes must be phased in gradually but that this is now late relative to climate timelines.
• Some say a tax-plus-sequestration-bounty (pay per ton reliably removed) could drive both emission cuts and drawdown.

Technology vs Behavior and Politics

• One camp: people will not voluntarily change consumption at scale; only technological fixes and price signals are realistic.
• Another camp: social and political change is essential (e.g., limiting advertising, reshaping transport and housing, diet shifts), because climate is intertwined with broader ecological damage and consumption culture.
• Several suggest a “yes, and” approach: many small and medium-size measures combined (renewables, efficiency, sequestration, policy, behavior) rather than a single silver bullet.

Jurisdiction and court’s stance on delays

• Some commenters initially assume an EU context where last‑minute filings are “punished”; others correct that this is a US case in the Northern District of California.
• Multiple comments stress the judge’s reasoning: Apple allegedly misrepresented discovery progress in status reports, then suddenly asked for more time, which is seen as a delay tactic.
• Clarification that Apple was not “punished” for requesting extra time; the request was simply denied.
• Others note that in US practice, last‑minute filing to disadvantage the opponent is common for motions and briefs, but courts are far less tolerant of last‑minute requests to bend procedure when the requesting party could and should have known the constraints earlier.
• Mention that this kind of ruling is typical of a discovery special master keeping parties in line.

Discovery scope and “1.3 million documents”

• “Document” is interpreted broadly: emails, memos, meeting notes, SMS/iMessage, chat threads—essentially any written record.
• Some are surprised such a volume is necessary for an established digital storefront; others describe it as a standard result of wide keyword searches over many years.
• One description: queries like “all communications over 10 years containing ‘epic’, ‘revenue split’, ‘monopoly’, ‘shut out competitors’,” then reviewed with a mix of AI tools and junior legal labor.

Intent, self‑incrimination, and justice theory

• One commenter questions whether such discovery is desirable, as it effectively probes what people were thinking, raising self‑incrimination and moral‑intent concerns.
• Others respond that many crimes and legal violations depend on mental state (mens rea); intent is a core part of distinguishing “wrong” from “illegal.”
• It’s noted that Fifth Amendment self‑incrimination protections apply to criminal matters; in civil cases you can be compelled to produce harmful evidence.
• Another clarification: even in civil cases you generally cannot be forced to provide evidence of your own crimes; refusal can, however, allow the court to draw an adverse inference against you.

Scope of “too much efficiency”

• Many see the core issue not as “efficiency” itself but:
  • Over‑optimizing on narrow or flawed metrics.
  • Confusing proxies (test scores, GDP, publication counts) with underlying goals (learning, wellbeing, scientific progress).
• Several argue this is better framed as Goodhart’s/Campbell’s law: once a metric is targeted, it degrades and can backfire.

Overfitting vs bad metrics

• Some agree the overfitting analogy from ML is illuminating: optimizing a proxy beyond a point yields diminishing, then negative returns.
• Others say the post conflates:
  • Overfitting (too complex a model to limited data),
  • Wrong metrics (mis-specified objective),
  • Excessive efficiency (sacrificing robustness).
• There is debate whether “too much efficiency” is even the right phrase; many see the real problem as mis-specified or static objectives.

Efficiency vs robustness and slack

• Strong theme: highly optimized systems are brittle:
  • Just‑in‑time supply chains, COVID-era shortages, global shipping disruptions.
  • Queuing theory: as utilization → 100%, wait times → ∞; you need slack.
  • Error-correcting codes and other technical systems that fail catastrophically at capacity limits.
• Slack is framed as:
  • Necessary for resilience, experimentation, and long-term survival.
  • Social/organizational analogs include “lazy” workers/ants, backup staff, mixed forests vs monocultures.

Political, economic, and social angles

• Discussion touches on:
  • Capitalism optimizing for efficiency at the firm level while system-level resilience is offloaded to turnover and bailouts, possibly creating an “inefficient Nash equilibrium”.
  • Planned economies and overcentralization as “too efficient” in theory but fragile in practice.
  • Concerns about metrics like GDP and standardized tests as overused proxies that distort education and policy.
• Some argue the cure is not more control or more metrics, but loosening control and accepting inefficiency as a feature.

Mitigations, alternatives, and open questions

• Proposed mitigations/parallels from ML and systems theory:
  • Build robustness/slack into optimization criteria.
  • Inject noise or randomness (e.g., sortition in politics).
  • Use multiple metrics, change goals over time, favor simplicity and “good enough” models.
• Skeptics note:
  • These mitigations themselves can be gamed or over‑optimized.
  • Formalizing these ideas across ML, economics, and politics is promising but historically difficult; complex human systems resist clean mathematical treatment.

Overall sentiment about Notion’s “mid‑life crisis”

• Many see the piece as playful but are unsure what concrete point it makes; they infer Notion feels older, less exciting, and chasing “sports car” features like AI and CRM.
• Several argue Notion has drifted from a clean, elegant note/wiki tool into a cluttered, “kitchen sink” platform trying to do everything.

Shift toward CRM and enterprise “anything app”

• Strong skepticism about positioning Notion as a CRM; some call it irresponsible or naive, though others say it’s workable for lightweight CRM or simple project management.
• Explanation: once big customers arrive, product roadmaps skew to their feature requests, pushing the tool toward all‑in‑one enterprise use.
• Some see this as rational market expansion (competing with Salesforce, revenue tooling); others view it as dilution of product “taste.”

AI features and privacy concerns

• Serious concern over AI integrations that send private notes to third‑party LLM providers (OpenAI, Anthropic), including accidental sends via confusing UI.
• A few users have quit Notion for more private or self‑hosted tools.
• Notion employees in the thread stress that training on customer data would be too risky, but some commenters don’t trust that this won’t change under investor pressure.

UX, performance, and technical critiques

• Complaints about latency, CPU usage (especially on macOS/Electron), and heavy JS leading to slow, distracting editing experiences.
• Mixed experiences with keyboard and mouse interactions; some find it keyboard‑friendly, others find selection and block manipulation infuriating.
• Markdown export/import is seen as lossy and unreliable.

Use cases, flexibility, and alternatives

• Fans praise flexible databases, block‑based editing, and ability to unify wiki, tasks, and light CRM; they see Notion as a powerful “hub.”
• Critics say it’s a “jack of all trades, master of none” and prefer specialized tools: Obsidian, Apple Notes, Confluence, Google Docs, Jira, self‑hosted options, etc.
• Several note that wiki‑style tools inevitably suffer from “zombie” documents and require active curation, regardless of platform.

Data model, lock‑in, and APIs

• Concern about vendor lock‑in and complex JSON API formats.
• Notion staff explain a verbose union‑like API schema chosen to aid statically typed languages; some commenters argue simpler tagged unions are feasible.

Adoption patterns and future

• Observations that Notion is very popular among students and non‑technical staff, while many developers remain skeptical or indifferent.
• Some predict another migration wave away from Notion (as happened from Evernote), while others compare its role to Excel: imperfect, but the tool “everyone can understand.”

Links and context

• Original article is from the LA Times; MSN version is used to avoid paywall, plus an archive link.
• Commenters note the current approval rate is roughly back to 2014 levels.

Reasons for faster citizenship approvals

• Article attributes the uptick to clearing a backlog that began under Trump and worsened during COVID.
• Some suggest this is partly to get cases done before a possible Trump return, when things might slow again.
• Others argue it’s not strictly partisan, pointing out the Biden administration’s general slowness on other priorities (e.g., net neutrality).
• One explanation cites increased USCIS funding, higher fees, and long-delayed digitization, plus removal of Trump-era “roadblocks.”

Comparative immigration and deportation policy

• Discussion of how Obama, Trump, and Biden compare on deportations, with emphasis on changing definitions (e.g., “encounter”) and strategic use of enforcement for negotiation leverage (e.g., “Gang of Eight,” DREAMers).
• Debate on whether the US is especially “welcoming”: it leads in absolute immigrant numbers but is around OECD average by percentage.

Economic, demographic, and housing impacts

• Several view immigration as a key US advantage and geopolitical tool versus China/Russia, helping offset low birth rates and support Social Security.
• Others stress tradeoffs: wage pressure, higher housing demand, and “brain drain” harming sending countries.
• Multiple comments tie housing crises in the US and Australia to underbuilding since 2008 and weak infrastructure investment.

Immigration systems in US vs other countries

• Contrast between points-based systems (e.g., Australia) and US family-based, lottery-heavy, more ambiguous processes.
• Some claim large-scale abuse of Australian student visas; others describe Australia’s strict and intrusive entry requirements for legitimate visitors.

Experiences with naturalization bureaucracy

• Several report very fast recent citizenship processing (on the order of months, same-day oath), with courteous officers and moving ceremonies.
• Others describe earlier experiences as slow and paperwork-heavy, especially green card stages.

Patriotism, legality, and voting power

• Mixed views on overt patriotism: some find it inspiring and inclusive; others see it as irrational or performative.
• Strong divide on expanding the electorate via immigration: one side sees voting as zero-sum and fears dilution; others argue the US historically integrates new groups, that politics can be positive-sum, and that demographic vitality requires more people.

Nature of the Mission: “Rescue” or Routine Rotation?

• Big semantic fight over whether this is a “rescue mission” or a modified, scheduled crew-rotation.
• One side: “Rescue” is overdramatic clickbait; astronauts are safe on ISS, supplies are fine, and this flight was already on the manifest, just with two seats reallocated.
• Other side: Their ride malfunctioned, their 8‑day test turned into ~8 months, and another vehicle is explicitly picking up stranded crew; that matches common and dictionary notions of “rescue” or at least “retrieval”.
• Some argue “rescue” implies imminent peril; others emphasize “distress” and confinement are enough.

Risk, NASA’s Decision, and Safety

• Starliner showed unexpected thruster behavior; NASA judged risk for crewed reentry as insufficiently understood.
• NASA still considered Starliner acceptable as an emergency lifeboat while docked, then sent it home empty.
• Several comments highlight that avoiding unnecessary crewed reentry risk is exactly why having two providers is valuable.
• Some push back on dramatizing danger: ISS is inherently risky but these extra months are not a survival emergency.

Boeing, Starliner, and Contractor Culture

• Many see this as a major embarrassment and possible death blow for Starliner: repeated anomalies, long delays, and now failing its first crewed mission’s return phase.
• Broader criticism of Boeing’s recent safety record (airliners, defense, space), “accountants running engineering,” and dependence on US government contracts.
• Others caution against reflexive Boeing‑bashing, stressing that test flights are supposed to surface problems.

SpaceX’s Role and Musk

• General consensus that Dragon provides the “proven” lower‑risk option and is now effectively the backbone of US crewed launch.
• Some praise SpaceX as “America’s space program”; others note launch providers aren’t the entire “space program”.
• Thread periodically devolves into arguments over Elon Musk’s behavior and politics; several claim that attitudes toward the word “rescue” are colored by pro‑ or anti‑Musk sentiment.

Astronaut Experience, Health, and Pay

• Disagreement over how “happy” the astronauts really are:
  • One view: veteran test pilots likely relish extended time in space, especially late in careers.
  • Counterview: they have no say once in orbit; extended exposure means more health risk and personal sacrifices (family events missed).
• Mention of bone loss, cardiovascular impacts, and radiation; concern that increased exposure can affect lifetime flight limits.
• Pay appears to be salaried with minimal per diem; no clear overtime or hazard pay consensus.

Media, Language, and HN Moderation

• Strong criticism of mainstream coverage for sensationalizing terms like “rescue,” “marooned,” “stuck in space”.
• Others reply that “rescue” is not obviously wrong given the unplanned, months‑long extension and changed return vehicle.
• HN moderators explicitly removed “rescue” from the submission title to reduce semantic flamewars and keep titles neutral.

Technical and Operational Details

• Seats for the Starliner crew are created by bumping two originally‑assigned astronauts from the Dragon flight.
• Discussion of lifeboat concepts: making do with improvised seats in a prior Dragon vs dedicated seats on the new one.
• Suit compatibility: Boeing and SpaceX suits are not interchangeable; one Dragon suit is on ISS, another comes up with Crew‑9.
• Brief note that a Falcon 9 second‑stage deorbit burn for this mission was “off‑nominal,” prompting a temporary launch pause for investigation.

Scale, Work, and Overengineering

• Many are relieved not to work at Discord’s scale, citing complexity, bureaucracy, and “promotion‑driven development,” though some enjoy the rare 5% of truly hard, creative problems.
• Several note that 177–200 nodes (now ~72) for trillions of messages feels modest, suggesting a lot of modern cloud architectures are overengineered for much smaller workloads.
• Frustration that such hyperscale problems are used as interview benchmarks for roles that will never operate near this scale.

Cassandra → ScyllaDB Migration & GC Debate

• Cassandra was described as operationally painful at large scale, especially around tombstones from heavy deletes, hot partitions, and repairs.
• Some argue Discord under‑tuned Cassandra and ran old JVMs/GC (CMS, old Cassandra) and over‑blamed GC instead of upgrading to newer collectors like ZGC.
• Others counter that Scylla’s design (C++ implementation, CPU/IO schedulers, compaction strategies like ICS, tombstone_gc modes, reverse queries) plus better defaults makes it harder to “use wrong.”
• Discord engineers in the thread say they kept the schema/partitioning, added read coalescing, and Scylla handled large partitions and tombstones much better.

Database Choices & Performance

• Debate over whether Postgres (with sharding tools like Vitess/Citus/AlloyDB) could handle this workload:
  • Pro‑Postgres side: scales to billions/trillions of rows if you design carefully; strong SQL features.
  • Skeptical side: horizontal write scaling and multi‑master replication are much harder; sharding Postgres at this scale would be elite, bespoke work.
• LSM stores (Cassandra/Scylla) are seen as better for extreme write throughput; some question choosing a DB where reads are more expensive than writes for a chat system, others note “more expensive than writes” doesn’t mean reads are slow.
• Per‑Discord‑server databases are dismissed as infeasible with hundreds of millions of servers.

Caching, Coalescing & Tail Latency

• The message service layer is compared to Varnish/Nginx techniques (request coalescing, “grace”/stale‑while‑revalidate, use_stale).
• Discord emphasizes read coalescing rather than caching: collapse identical concurrent queries to avoid thundering herds without cache invalidation complexity.

Data Value, Archiving, and Privacy

• Some question why store “trillions of shitposts,” while others note there’s real, niche knowledge mixed in and no easy way to separate “good” from “bad.”
• Concerns that Discord’s walled‑garden model prevents long‑term archiving and discoverability; suggestions to use bots/projects to mirror public support chats.
• Strong criticism of how hard it is to truly delete old messages, with worries about GDPR compliance and lack of effective user data erasure.

Centralization vs Open Protocols

• Repeated lament that centralized Discord displaced IRC/Matrix/XMPP, framed as a tragedy for openness and ephemerality.
• Counterpoint: Discord’s success is attributed to superior UX—zero‑install web client, easy onboarding, reliable voice, history, and “just works” simplicity—where open protocols suffer from clunky clients, confusing onboarding, and federation complexity.
• Long subthread on E2EE, message history, metadata, and nostalgia for the more anonymous, ephemeral “old internet,” vs the convenience expectations of modern users.

Context: UK Industry and Ownership

• Some recall previous UK semiconductor assets sold to Chinese investors and steel industry decline.
• Others note the UK still has ~23 fabs and two major steelworks converting to electric arc furnaces.
• Debate over whether losing iron-ore-to-steel capability is a strategic risk vs. sensible shift to scrap-based steel, given UK scrap exports.

What This Fab Is and Its Technology

• The acquired plant is a gallium arsenide (GaAs) III-V fab, ex-Coherent, on 6-inch wafers.
• Likely used for VCSELs/optical components (e.g., Apple FaceID), LIDAR, telecom, radar, night vision, high-speed analog/RF.
• Estimated capability around ~0.35 µm; not cutting-edge logic, but appropriate for photonics and RF.
• Some stress that older or specialized nodes can still be critical for defense systems (radar, sensors, power electronics).

Strategic Rationale vs. Skepticism

• Supportive views:
  • Buying an existing fab preserves specialized infrastructure and a skilled, security-cleared workforce.
  • Maintains sovereign capacity for GaAs parts used in fighter jets and other platforms.
  • Easier and cheaper than greenfield fab construction; governments commonly subsidize fabs.
• Skeptical views:
  • Concern it becomes a cash-burning, low-competition state enterprise with civil-servant management and political interference.
  • Marketing language linking this GaAs fab to AI, quantum computing, and 4 nm-class advances is seen by some as misleading hype.
  • Some suggest it’s more about saving ~100 jobs/pork-barrel politics than genuine AI/quantum capability.

Semantics and Regional Identity

• Long digression over “North East” vs. “North East of England” vs. “North East of the UK.”
• Disagreement whether “North East” is acceptable UK-wide shorthand or England-centric and confusing, especially to Scots and foreigners.

Wider War and Deterrence Concerns

• Several see this as part of a broader trend of rearming and onshoring critical supply chains in anticipation of larger conflicts.
• Discussion touches on:
  • Ukraine, Middle East, and potential Taiwan conflict as interconnected pressures.
  • Deterrence vs. escalation; conscription and military buildup in Europe.
  • Importance of self-sufficiency in munitions and chips highlighted by Ukraine war experience.

Definitions and Uses of “Woke”

• Thread disagrees on what “woke” means and whether it’s useful.
• Some frame it as basic empathy and awareness of structural oppression.
• Others see it as a vague insult now used to mean “anything I dislike,” especially by the right, or as shorthand for “identity politics.”
• Several complain that such umbrella terms (woke, DEI, SJW, “defund the police”) erase nuance and create fake battle lines.
• A few argue “woke” (and its predecessors) are just the latest label for a long‑running political subculture that continually rebrands.

Corporate DEI, ESG, and Representation

• Multiple comments note a visible decline in DEI job listings; proposed explanations:
  • Economic downturn and general hiring slowdown.
  • Market saturation once large firms staffed those roles.
  • Investor backlash and partisan attacks on DEI.
  • Perception that standalone DEI roles add little value.
• Others counter that DEI work can be substantial (events, mentoring, policy work) and often ties to legal/compliance risk reduction.
• ESG reporting is seen as still strong, but some want to keep it from drifting into the same culture‑war zone.
• Queer representation in ads splits opinion:
  • Some LGBTQ commenters feel targeted and commodified; call it pure virtue signaling.
  • Others welcome mainstream visibility as better than erasure, while still disliking hollow “rainbow-washing.”

Virtue Signaling, Outrage, and Echo Chambers

• Many see “wokeness” (and its right‑wing mirror) as performative: corporations, politicians, and influencers stoke outrage to gain attention or profit.
• Both left and right are accused of using inflammatory language, grandstanding, and refusing genuine policy engagement.
• Some claim people are getting better at spotting “performative outrage,” but still easily manipulated by it.

Culture War Fatigue and Institutions

• Several say people are tired of culture‑war topics, which crowd out discussion of policy, inequality, and governance.
• Schools, churches, and other institutions saw realignment during/after COVID (e.g., people leaving stricter or more “woke” spaces), but broader secularization trends are also noted.
• Some argue culture‑war fights distract from wealth inequality; others focus on hypocrisy in affluent “progressive” cities with extreme rich‑poor gaps.

Article and Data Critiques

• Some call the article “nonsensical” or “irrelevant,” arguing it tracks weak proxies and overinterprets a post‑peak dip that’s still above 2019 levels.
• Others say measuring proxy signals is imperfect but reasonable, and dismissing such analysis outright contributes to today’s polarization.
• Several complain that coverage of “woke” is more about engagement and clicks than insight.

Gentoo vs. other distros (binary, NixOS, etc.)

• Source-based distros like Gentoo struggle because upgrades are incremental: libraries get rebuilt and installed one by one, so the system can be in a “half-32-bit, half-64-bit” ABI state where core tools no longer work.
• Users describe workarounds: dual-root partitions, boot-environment–style approaches, chrooting into a freshly unpacked stage3, or using Gentoo’s ROOT variable to build an entire new userland elsewhere and then swap it in.
• Some note this ignores user-local binaries (virtualenvs, cargo builds, etc.) and accumulated config/symlink cruft, so “just reinstall” is not truly trivial.
• NixOS is cited as an example of a source-based system that avoids this by building everything in isolated stores and allowing multiple glibc versions; Gentoo lacks such atomic build/install tooling.
• Debian and other binary distros have already switched but report that it was still painful; being binary does not magically remove the complexity.

ABI, typedefs, and multi-ABI ideas

• time_t/off_t typedefs help source portability but not binary compatibility: once structs, function signatures, or protocols embed them, changing size breaks ABI.
• The core problem: you must rebuild all code that uses the type in one go, or carefully support dual ABIs.
• Various proposals are discussed: fat binaries, LFS-style dual symbol sets, linker version scripts, or library-specific “time64” variants, but these are considered a lot of work and hard to retrofit widely.
• Some argue libc should have offered better multi-ABI mechanisms; others suggest Gentoo’s design (install-while-building) needs rethinking.

Unsigned 32-bit time_t as a stopgap

• One camp suggests changing 32‑bit time_t to unsigned to push the failure from 2038 to 2106, easing migration.
• Critics note loss of pre‑1970 representation, breaking subtraction and negative intervals, and silent “teleporting” of historic timestamps into the future.
• Supporters counter that negative or pre‑epoch timestamps are rare on such systems and that upgrading signed→unsigned is easier than 32→64 bits.

Other 32-bit “bombs” and related issues

• IPv4 exhaustion is mentioned but seen as a long, gradual squeeze rather than a hard bomb, with IPv6 as relief.
• Filesystems: ext* and inode limits (32‑bit inode numbers) can also bite; newer filesystems use 64‑bit inodes, but compatibility issues exist with 32‑bit apps.
• off_t/large-file support had similar ABI issues, but less pervasive than time_t.

Static vs shared linking

• One suggestion: build all new 64‑bit‑time binaries statically to avoid ABI mixing.
• Pushback: static linking explodes update sizes, RAM/disk usage, and rebuild cost, especially for large libraries (GUI toolkits, Chromium-like stacks) and embedded 32‑bit systems.

Broader OS experience and design reflections

• Some OSes (FreeBSD, OpenBSD) chose 64‑bit time_t early, especially on amd64, avoiding this transition later; Linux on 32‑bit is paying that technical debt now.
• There are calls for better ABI metadata in ELF and for clearer separation or consolidation of “stable” user/kernel boundaries via libc, but no consensus on practicality.

Focus of model improvements: compute, data, and techniques

• Several comments argue that increased compute is the main current driver of frontier model gains, enabling more experiments, larger runs, and advanced techniques (e.g., RL-style “reasoning traces,” synthetic fine‑tuning).
• Others note that human feedback is itself a training technique, and architectures, data curation, and training methods all matter alongside compute.
• There’s debate on allocation of R&D among data, architecture, training, compute, and “other,” with a strong short‑term bias toward compute.

Human trainers, data quality, and synthetic data

• The thread pushes back on the idea that “smarter trainers” alone explain progress; better architectures, techniques, and filtering (e.g., pre‑filtering junk data) are emphasized.
• Some expect the “human‑labeled data is better” argument to weaken as synthetic data and better annotation tools improve.
• A detailed anecdote from an AI trainer describes creating reasoning‑heavy benchmark questions; many “failures” of models were mundane (outdated info, tokenization issues), and models were often better than project organizers at spotting contradictions.

Capabilities, limitations, and evaluation

• Many see current AI as augmenting and redistributing human expertise rather than replacing it.
• Several complain that people fixate on failures and “hallucinations,” while others insist that occasional correctness doesn’t mean a system truly “can do” a task, given unpredictable errors.
• IQ tests and puzzle‑style word problems are discussed as highly “learnable,” not reliable measures of deep intelligence.
• Benchmarks that demand nuanced, framework‑dependent answers are seen as inherently tricky to automate.

Economic and ecosystem trends

• Foundational models are seen as on a path to commoditization; differentiation will come from domain expertise and applications (e.g., dev tools, cybersecurity).
• Some worry that giant data centers and compute budgets will make meaningful startup competition physically impossible.
• Others see large opportunity in domain‑specific tools and synthetic data generation, especially where experts can script data generators.

Ethics, bias, and law

• Multiple comments stress that AI systems inherit human flaws: racism, misogyny, and structural limitations of law and institutions.
• Removing biased training data is viewed as necessary but insufficient; many domains have no clear, perfectly mechanizable ground truth.

User data, privacy, and opt‑out

• Some users resist using free tools (e.g., chatbots) over fears their contributions will be used to train models, especially if they’re also paying.
• There’s debate about corporate promises not to train on user data: some see such assurances as reputationally binding, others as unverifiable and economically tempting to break.
• Policies differ by provider and product; what data is actually used for training remains somewhat unclear.

Human intelligence, expertise, and “hallucinations”

• Several comments argue that many humans, including degree‑holders, fail at basic critical thinking or trick questions, so AI mistakes shouldn’t be held to a higher bar than ordinary human reasoning.
• Others counter that degrees don’t equate to “smart,” and that much of human “intelligence” is accumulated cultural knowledge and search, not novel insight.
• This leads to discussion of “general intelligence” as socially defined and heavily dependent on prior learning and collaboration.

Prompting skill and user experience

• Frequent users report that prompt craftsmanship substantially affects output quality (e.g., linear structures, constrained outputs).
• Prompting is getting both “smarter” and more tedious; there’s interest in tools that automate meta‑prompting.
• Some perceive models as getting “dumber” over time, possibly due to cost‑cutting, outdated training data, or contrast with initial novelty, though this is speculative and unresolved in the thread.

Scope of Legal Protection (GDPR, UK GDPR, HIPAA, etc.)

• Major debate over whether and how GDPR/UK GDPR applies to 23andMe as a US company.
• Several argue GDPR applies based on targeting EU/UK residents; others note enforcement against non‑EU entities is weak and cross‑border data transfer to the US is legally shaky.
• UK has “UK GDPR,” similar but perceived as less aggressively enforced.
• Some note 23andMe itself claims GDPR applicability for EU customers.
• HIPAA is repeatedly called out as irrelevant here: 23andMe isn’t a covered healthcare entity; HIPAA also hasn’t prevented large medical data breaches.
• US genetic nondiscrimination laws (e.g., against insurer use of genetic info) are mentioned, but people doubt their long‑term political durability.

Data Retention, Deletion, and Breaches

• Users discuss GDPR/CCPA/other rights and tools to request deletion, but many are skeptical anything is fully erased, especially for a struggling company.
• 23andMe reportedly keeps DNA, sex, and DOB to comply with lab regulations; posters question whether law truly requires this or if it’s self‑serving.
• Concern that “deletion” often just means removing user access, not wiping all copies or backups.
• Past major breach (millions of ancestry profiles) is cited; many assume data is already in broker or dark‑web ecosystems.

Risks and Potential Misuse

• Fears: insurance discrimination, future rollback of protections, use by law enforcement, wrongful convictions via partial DNA matches, data sales to opaque analytics firms.
• Some worry about future capabilities like designer pathogens targeting individuals, families, or ethnic groups.
• Others are more sanguine: government likely has or will get everyone’s DNA anyway; name/face already enough to persecute; benefits (health markers, ancestry, relatives) outweighed risks for them.

Familial and Ethical Concerns

• Strong resentment from some toward relatives who submitted DNA, since shared genetics allows inference about non‑participants, including “shadow” profiles.
• Debate over whether your genome is purely “your” data versus a shared family resource that can harm others.

Technical Aspects & Business Reality

• Clarification that standard 23andMe uses genotyping (≈1M variants), not full sequencing; nonetheless, imputation can infer much of the rest.
• Some speculate samples are retained and could be fully sequenced later as costs fall.
• Others doubt the data’s long‑term commercial value, suggesting acquisitions may find it less useful than hoped.

What “creole” means and whether English qualifies

• Several comments stress that “creole” is both a sociohistorical and structural label, originally used to legitimize colonially marginalized languages.
• Some argue calling English a creole stretches the term so far it becomes meaningless, or risks erasing that history.
• Others see value in highlighting creole‑like phases in English to show creoles are fully “real” languages, though not all agree English itself should be labeled a creole.
• One view: it’s largely a terminological fight; the historical facts about English’s mixing and simplification hold regardless of the label.

Origins and evolution of English

• Common narrative: Old English and Old Norse contact simplified inflection and grammar; later Norman French dominance injected large amounts of French vocabulary into an English grammatical base.
• Some suggest focusing on “creolization events” during early Middle English rather than a binary creole/non‑creole label.
• Comparisons are drawn to French, Sicilian, and other European languages that are also products of multiple conquests and language layers.

Defining a “word” and linguistic units

• Long subthread notes linguists lack a single, cross‑language definition of “word.”
• Regex jokes illustrate that space‑based heuristics fail for languages like Japanese and Chinese.
• Different notions of atomicity (lexical, syntactic, phonological) conflict: idioms, clitics, contractions, prefixes, and compounds all blur boundaries.
• Some propose “unit of semantic meaning,” but concrete tests break down across languages.

Germanic vs Romance character of English

• One claim: only ~¼ of English dictionary entries are Germanic, ~½ are Latin/Romance; others respond that high‑frequency core vocabulary is overwhelmingly Germanic.
• Debate over whether English aspect (e.g., “I played / have played / was playing”) makes it more Romance‑like; counter‑arguments note similar constructions in Germanic languages, so classification remains unclear.

Language, identity, and politics

• Multiple comments emphasize that linguistic categories (creole, word, language family) are messy, contested, and entangled with race, colonialism, religion, and national politics.
• Some object to “post‑colonial” politicization of creole studies; others say the term is inherently bound to those histories and can’t be purely “scientific.”

GDPR, fines, and what counts as a “breach”

• Incident stems from passwords stored in readable form since 2012, discovered and handled around 2019, after GDPR came into force.
• Fine is for multiple GDPR violations: inadequate technical measures, and failing to notify and document the breach promptly.
• Some think €102M is low vs the theoretical 4% of global turnover; others note regulators rarely use the maximum and factor in self‑reporting and perceived impact.
• Strong debate over whether this is a “breach” or just a “control failure”:
  • One side: internal access to plaintext passwords is inherently a personal data breach under GDPR’s broad definition and creates a “reasonable expectation” of misuse.
  • Other side: without evidence of unauthorized use or harm, calling it a breach is overreach and weakens GDPR’s credibility.

Nature and severity of Meta’s failure

• Many highlight that passwords were likely logged accidentally (e.g., debugging, middleware, crash dumps) rather than intentionally stored unhashed.
• Others argue “no intent” is irrelevant; if someone noticed and cleanup was deferred, it effectively became intentional.
• Concern over impact beyond Meta accounts due to widespread password reuse (e.g., employees or insiders accessing users’ other services).

How large organizations end up here

• Descriptions of big‑org realities: legacy systems, unclear ownership, massive logs never reviewed, over‑permissive access (“just give them everything so work gets done”).
• Some blame culture and management: security tickets deprioritized, focus on closing tickets vs fixing root causes, “compliance theater” over true security.
• Counterpoint: it’s still negligent to accept known dangerous patterns (e.g., unsecured core dumps, plaintext logs) just because systems are complex.

Developer competence, hiring, and security culture

• Multiple commenters say many developers don’t understand basic security (password handling, PII in logs, PCI/PII rules), and managers don’t incentivize learning.
• Others argue competent engineers should know relevant regulations; security questions should be part of hiring, especially for sensitive systems.
• Recurrent theme: logging middlewares and support channels (email, chat, phone) are common, underestimated vectors for leaking secrets.

Views on EU regulation and incentives

• Some see GDPR fines as necessary to create real incentives, since otherwise companies “don’t care.”
• Others view GDPR as burdensome “import tariff” or legal minefield that pushes smaller sites to block EU users.
• Disagreement over how “big” and indispensable the EU market is, but consensus that large tech firms will generally comply rather than exit.

Overall reception

• Many commenters find the demo stunning, “National Geographic”-level, and the best real‑time ocean they’ve seen.
• Several emphasize how remarkable it is that this runs interactively; effects that once took days of offline rendering now update in real time.
• Some want it as a lock screen or ambient display and note it strongly increases their interest in graphics and Godot.

Visual realism and perceived issues

• Multiple people with sailing or coastal experience say the waves look too steep, tall, and pointy, more like mountains or syrup than water.
• Critiques include: lack of breaking waves, overly sharp crests, foam shooting straight up instead of curling, missing darker wind‑patch patterns, and high‑frequency ripples riding unrealistically on longer swells.
• Others say that at a glance it’s convincing, especially the swell motion, though still in the “uncanny valley.”
• Clarification is given that this targets open‑ocean swell; breaking and spray are post‑effects, not fully physical.

Technical approach (FFT, spectra, Gerstner)

• The approach uses inverse FFT: generate wave spectra in frequency space, then transform back to get a time‑domain surface.
• Commenters note this is based on 20‑year‑old ocean‑simulation research, now just done in real time.
• Discussion contrasts FFT‑based oceans with Gerstner (trochoidal) waves: Gerstner is simpler and cheaper, FFT more physically grounded.
• Several highlight that this is linear superposition; it breaks down for very large, nonlinear or rogue waves and does not model full CFD phenomena like vortices.

Engine, implementation, and performance

• Godot is praised as open source with a strong community; some say switching to it unlocked long‑stalled projects.
• The project is a standard Godot project; users report it runs impressively on their machines.
• One comment notes the main mesh is ~330k vertices; foam particles might be optimizable by emitting only where foam density is high.

Interaction with objects and gameplay

• A key limitation raised: FFT grids make local interactions (ships cutting waves, reflections from obstacles, shoreline effects) difficult.
• Linked papers suggest combining FFT with convolution‑based methods; others suggest gameplay hacks via sampling the heightfield and adding particle effects.
• Some worry this may limit use to background oceans rather than tightly interacting gameplay.

Learning, math, and motivation

• Questions about the math lead to explanations referencing Fourier transforms, signal processing, and understanding time vs frequency domains.
• Several commenters reflect that projects like this rekindle interest in “fun” graphics work versus routine application glue code, with encouragement to pursue such explorations gradually.