Hacker News, Distilled

Changing Population Structure

• Commenters note that many countries now have “rhombus” age structures, not pyramids; US graphs clearly show the baby boom bulge aging into retirement and a secondary bulge around 1990.
• Some Middle Eastern states show extreme male-heavy cohorts due to imported male labor.
• Several of the listed states (e.g., West Virginia, Maine, Vermont) are seen as cases of young people leaving and those remaining having fewer children.

Housing, Zoning, and Generational Conflict

• One camp blames high housing costs and restrictive zoning—perpetuated by older homeowners—for suppressing family formation near good jobs.
• Others push back: zoning’s roots predate boomers, and Gen X/Millennials have also failed to change it.
• Disagreement over whether “greedy elites,” general cost of living, or personal preferences are the main brake on fertility.

Economics vs. Culture in Fertility

• Some argue “nobody can afford anything,” citing housing, childcare, healthcare, and education.
• Others counter that poor countries and very rich households often have higher birthrates, suggesting culture, status, and norms (e.g., patriarchy, community support, views on motherhood) matter more than income alone.
• Several people say parenthood is a “bad deal” in a society that offers many solitary comforts and where having kids is low-status.

Immigration, Race, and Population Replacement

• One thread links low native fertility to calls for more immigration, prompting explicit debate over whether this is about labor needs or maintaining certain ethnic majorities.
• Some commenters voice anxiety about cultural change; others reject racial framing and stress that immigration is an obvious way to offset aging.

Birth Control, Technology, and “Demographic Collapse”

• A recurring argument is that widespread, reliable contraception (especially the pill) is the core driver of fertility decline, by decoupling sex from reproduction.
• Others highlight women’s education, infant-mortality improvements, and cost disease in childrearing as equally or more important.
• Views on “demographic collapse” range from existential crisis (unsustainable old-age dependency ratios) to “overblown” or even potentially beneficial population contraction.

Policy Ideas and Fairness

• Proposals include: taxing the childless more, expanding childcare and family subsidies, or even restricting access to birth control.
• Critics say it’s unjust to pressure people into decades of unwanted parenthood to prop up pensions; supporters argue non-parents “free ride” on others’ children who will support the system.
• Many note that raising multiple kids with two working parents, no extended family, and expensive childcare is simply exhausting, regardless of ideology.

What Leta Was and Why It’s Gone

• Leta acted as a privacy proxy in front of Google/Brave (and possibly others), stripping tracking while returning their search results.
• Several commenters always felt it was “on thin ice” because it apparently used Google’s API and cached results for ~30 days, likely conflicting with Google’s terms that restrict caching.
• Some speculate Google’s tightening around automated access made the service non‑viable; others see Mullvad’s shutdown as a pragmatic decision to focus resources where privacy work has more impact.

VPN/Browser vs. Search Proxy

• Mullvad suggests similar privacy can be achieved with a VPN plus a privacy‑focused browser; some find this reasonable, others argue that’s not a real replacement for a search proxy.
• Debate over whether Mullvad could simply “scrape Google via VPN” ends with concerns about IP blocking and legal/ToS risk.

SearXNG and Self‑Hosting

• Leta was popular as a backend for self‑hosted SearXNG. Its removal disappoints users.
• Public SearXNG instances are widely reported as unreliable: rate‑limited, error‑prone, or returning irrelevant/foreign‑language results.
• Self‑hosting SearXNG (often via Docker + Redis/Valkey) is described as relatively easy and more reliable, though individual providers still drop out occasionally.

Perceived Decline of Search Quality

• Multiple people report DuckDuckGo becoming intermittently “unusable,” failing even on basic queries, or drowning in SEO/AI junk. Others say it’s improved and now offers per‑site blocking.
• Many feel all search engines have degraded: more spam, AI‑generated slop, and non‑indexed niche content. Some suggest the web itself has hollowed out (forums gone, content paywalled/centralized), so there’s “less worth indexing” at all.

LLM‑Based Search: Usefulness vs. Risks

• One camp claims users are shifting heavily to LLM‑style answers; another vehemently disagrees and cites screenshots where AI overviews confidently affirm mutually contradictory claims (e.g., “NFL viewership up” and “down”).
• Concerns include:
  • “AI sycophancy” reinforcing user biases.
  • Non‑deterministic, hard‑to‑verify answers presented with undue confidence.
  • Safety risks (e.g., people doing hardware repairs based solely on AI instructions).
  • Potential to “kill websites” by diverting traffic to summaries, undermining incentives to publish new content.
• Others counter that snippets and summaries have always reduced clicks, that LLM summaries are genuinely useful for many tasks, and that responsibility for verification still lies with users.

Alternatives and Trade‑offs

• Kagi is widely praised for high‑quality, mostly Google‑sourced results, but criticized for using Yandex: some worry about indirectly funding Russia and about queries hitting Russian infrastructure.
• Brave Search gets positive reviews; a Brave employee emphasizes it now runs a fully independent index. Users like the option to disable AI summaries.
• Ecosia, Yandex via Tor, and others are also mentioned, each with privacy or geopolitical caveats.
• Several people conclude that if we want non‑enshittified search, we likely have to pay for it.

Overview and Goals

• Valdi is presented as a declarative TypeScript UI framework that renders to native views on iOS, Android, and macOS, aiming for “write once” UI with native performance and no webview/bridge.
• Some commenters are excited to see a polished internal Snap framework finally open-sourced, but others want more real-world examples, components, and screenshots before taking it seriously.

Architecture and TypeScript Compilation

• Under the hood it uses native views, conceptually similar to React Native.
• There are three execution modes for TS:
  • Interpreted JS,
  • JS bytecode,
  • AOT TS→C compilation.
• The AOT compiler reportedly supports most of TS/JS, including a limited eval, but currently trades larger binaries for modest and inconsistent performance gains; it’s described as a work in progress.
• State is handled via class-style components reminiscent of pre-hooks React.

Comparison with Other Frameworks

• Frequently compared to React Native and ByteDance’s Lynx.js: same general idea (React-style TS → native views, multiple execution modes).
• Some see Valdi’s ideas (AOT options, debugging, native bindings) as parallel to or converging with recent React Native improvements.
• Others note the lack of Swift/SwiftUI, Linux, Windows, and HTML targets as a major limitation.

Snapchat’s Track Record and Camera Tradeoffs

• Skepticism arises from Snapchat’s historically poor Android experience, especially the “screenshot of camera preview” approach.
• Multiple commenters familiar with mobile camera stacks argue that this was a pragmatic tradeoff given old Android hardware, fragmented camera APIs, and Snapchat’s need for near-zero shutter delay.

Native vs WebView vs Cross-Platform

• Large subthread debates whether frameworks like Valdi are worthwhile versus:
  • Fully native per-platform UIs with a shared core,
  • Hybrid/WebView apps (Cordova/Ionic/Capacitor/Tauri),
  • Alternatives like Flutter, Kotlin Multiplatform, Qt/QML, SwiftUI.
• Many report hybrid apps often feel “off” or sluggish, but some claim well-done WebView apps can be indistinguishable from native for many use cases.
• Several note that AI/codegen doesn’t remove deep architectural and platform constraints (e.g., App Store policies, native integrations).

UX and Ecosystem Concerns

• Opinions on Snapchat’s UX are polarized: some call it confusing, manipulative, and ad-heavy; others see it as a major UX innovator copied by nearly every social app and intuitive for younger users.
• Some worry Valdi’s codebase looks over-engineered for solo or small-team use and that in-house BigTech frameworks tend to be moving targets.
• Using Discord as the primary community channel draws criticism for being closed, hard to search, and privacy-unfriendly.

Performance & Technical Claims

• 1000 tokens/sec refers to output speed; users report code “flashing” onto the screen and workflows where waiting is more about tests/compiles than model generations.
• Cerebras and others are said to avoid quantization; commenters attribute speed to the wafer-scale chip keeping weights and KV cache in on-chip SRAM, trading high cost per token for extreme bandwidth.
• Some argue you can test for quantization by comparing benchmark performance across providers; others point out real evidence is limited and vendor claims aren’t easily verifiable.
• Lack of prefix caching is suspected (or at least not visible) given the architecture, making repeated long contexts expensive.

Speed vs Quality

• Many emphasize that raw speed transforms interaction style: more rapid refactors, UI tweaks, and “semi-interactive” workflows where an agent edits many files per call.
• Others find GLM 4.6 “smart enough but not frontier level,” often still preferring Claude/Codex for deep reasoning, complex bugs, planning, or non-mainstream domains (embedded, UEFI, some Rust/embedded HAL tasks).
• Multiple users say GLM 4.6 is roughly Sonnet-ish: sometimes better, sometimes worse; code can be messier and may need cleanup by a higher-quality model.

Pricing, Value, and Limits

• $50/month (and especially $200/month) is polarizing: for some, trivial vs dev salaries and justified by preserved focus; for others, “Herman Miller” pricing for SaaS.
• Several point out Cerebras is cheaper than some competitors on a per-token basis, but per-minute request caps and daily token ceilings are easy to hit with fast, agentic workflows.
• Some prefer cheaper options (e.g., GLM directly via other providers) or pay-per-token, questioning what Cerebras adds beyond speed.
• Plans and GLM 4.6 access briefly showed as “sold out,” and some users report recent queueing/lag before responses.

Workflows & Tooling

• Popular pattern: pair a slower frontier “planner” (Claude/GPT/Gemini) with Cerebras+GLM as a fast “executor” in tools like Cline, RooCode, OpenCode, or custom TUI setups.
• Fast models shine for: UI tweaks via voice, multi-variant component generation, quick scripting, and “AI-first” greenfield web apps.
• Limitations noted: unstable service, no/limited search or vision in some setups, frequent retries under “high demand,” and non-trivial token burn in agentic flows.

Broader Reflections on AI Coding

• Strong debate over “vibe coding” vs disciplined LLM-assisted development: many insist careful review, tests, and static analysis are essential, especially off the happy-path (embedded, novel domains).
• Several commenters report previously being skeptical of AI coding, but say extremely fast, “good-enough” models finally provided a genuine productivity shift.

Reaction to the article

• Many found the post underwhelming relative to its claim that Zig is a “totally new way to write programs.”
• Examples used (type inference, labeled breaks, basic range loops, runtime panics on bad shifts) were seen as commonplace across modern languages and not uniquely “surprising.”
• Several commenters felt the article completely missed Zig’s actually distinctive features, especially compile-time execution (“comptime”) and its metaprogramming model.

What people actually like about Zig

• Explicitness: no overloading, no hidden control flow, no implicit heap allocation. defer/errdefer are praised as simple, visible cleanup.
• Simplicity and coherence: few core concepts that compose well; relatively few “warts” compared to C++/Rust.
• Built-in cross-compilation and C/C++ interop: single toolchain, easy cross-target builds, used even just as a cross-compiler for other languages.
• Inline tests and labeled switches/loops are seen as small but pleasant ergonomics.
• New async/IO and allocator model: explicit IO/allocator objects passed around, with vtables and planned de-virtualization; seen as a clean way to control allocation and concurrency.

Comptime and metaprogramming

• Strong consensus that Zig’s compile-time execution + reflection is its real “killer feature.”
• It replaces separate mechanisms for generics, interfaces, and most macro use, while staying in one language (no macro DSL).
• Comparisons made to D and Nim (full-language compile-time interpreters) and to Rust’s macro systems; tradeoffs differ:
  • Zig: simpler, unified, but type-checking often only at instantiation.
  • Rust: more static checking and powerful syntax macros, but more complexity and dual systems.

Comparisons: Rust, C, Go, D, Odin, others

• Rust: more memory-safe but more complex (lifetimes, traits, macros). Debate over binary size: some report Zig’s .ReleaseSmall easily beating typical Rust builds; others counter with no_std and tuned Rust setups.
• C: Zig viewed as a “better C” with checked casts, slices, safer defaults, and much easier cross-compilation.
• D/Nim/Odin/Ada/Modula-2: many features touted as “new” in Zig exist there; Zig’s appeal is seen more in design restraint and execution than in novelty.

Error handling and diagnostics

• Major criticism: Zig errors cannot carry payload data; extra info must be passed via side channels or custom diagnostic structures.
• Some argue this discourages rich diagnostics in practice; others defend the separation of small error codes from heavier diagnostic channels, especially in low-level contexts.

Memory safety and philosophy

• Zig is not memory-safe like Rust; it relies on explicit patterns, debug-mode checks, and allocator discipline rather than a borrow checker or GC.
• Some see a new unsafe systems language as unjustified in 2025; others argue there is room between C and Rust for an explicit, low-magic systems language with strong tooling and ergonomics.

Scope of the FAA Order

• Order limits commercial space launches and reentries to 10 p.m.–6 a.m. local time, starting Nov 10, 2025, until canceled.
• Several commenters note the headline is misleading if read as an outright ban.
• Clarification that “local time” applies, not exclusively EST.

Local and Commercial Impact

• Residents near Vandenberg/Ventura expect more nighttime sonic booms and disrupted sleep as launches are pushed into overnight hours.
• Concern that compressing all commercial launches into night slots will be “really disruptive” around busy spaceports.

Airline Reductions and Nature of “Orders”

• Some observe that earlier FAA “orders” for 20%/10% airline reductions appear to translate into much lower actual cancellations in practice.
• Others point out the order phases in cuts (e.g., 4% then 10%) and applies only to domestic flights, so public stats may understate the percentage.

Debate over Automating Air Traffic Control

• One line of discussion argues the disruption should push the system toward automated ATC and more onboard automation, framing current human‑radio systems as inertia.
• Counterarguments emphasize:
  • ATC involves high‑pressure edge cases, emergencies, and visual checks, not just scheduling.
  • Aircraft systems, outages, non‑equipped planes, and general aviation make full automation extremely complex.
  • Existing autopilots are limited; safe automation is hard, especially when things go wrong.
• Others advocate incremental automation: text‑based clearances, data links, TCAS‑like systems, and note ongoing programs (e.g., NextGen, Data Comm, controller–pilot data link) already move in that direction.
• Cost, certification, and retrofitting hundreds of thousands of diverse aircraft are cited as major barriers.

Safety Comparisons: Flying vs Driving

• A side debate challenges the common claim that “the drive to the airport is more dangerous than the flight,” arguing per‑journey risk is closer than people think.
• Other commenters respond with fatality‑per‑mile data suggesting air travel remains substantially safer, even accounting for speed, though absolute risks for both are very low.

General/VFR Aviation Service Reductions

• The order also allows ATC to suspend optional services (flight following, radar advisories, practice approaches, parachute and “unusual” operations) when understaffed.
• Some see prioritizing commercial traffic over private/VFR activity as prudent under staffing stress.
• Pilots note these services are formally workload‑permitting even in normal times; denials may simply become more common, not illegalizing such flights.

Non‑Commercial and Military Launches

• Some criticize that only commercial rockets are time‑restricted if the issue is safety.
• Others respond that non‑commercial launches (e.g., SLS, Minuteman tests) are rare enough that excluding them likely has negligible operational impact.

Speculation and Frustrations

• A few express frustration with Florida tourism and spaceflight policy in general, sometimes jokingly.
• One commenter muses about whether launch providers might eventually weigh FAA fines vs. lost launch windows if the allowed time window shrinks further; this remains speculative and unaddressed by others.

LLMs, Languages, and the Future of Compilers

• One view: LLMs will make it easier for more companies to maintain compilers; they can help find bugs when experts are unavailable, but “compiler gurus” will still be needed.
• Counterview: LLMs will reduce the number of compilers by reinforcing a few mainstream languages and shrinking niches.
• Others argue LLMs can work with bespoke DSLs if given good specs and compiler feedback loops, potentially weakening the “ecosystem advantage” of big languages.
• Multiple commenters report that current LLMs perform much worse in less-popular languages (F#, C#, etc.) than in Python/JS, undermining some of the optimism.
• Big disagreement over “LLMs and correctness”: some say compilers demand hard guarantees and LLMs can’t be trusted; others say agent-style systems can check correctness empirically, but not formally prove it.

Career Path, Hiring, and Market Size

• Compiler engineering is viewed as a small, niche field with relatively few openings compared to web/backend roles.
• Many positions are reported to be LLVM “glue code” or maintenance of large, aging codebases rather than greenfield language design.
• Typical employers mentioned: large CPU/GPU vendors, big tech, financial firms with proprietary languages, DB/query engines, accelerator/AI toolchains, DSP and semiconductor companies, and some crypto/VM projects.
• Several note that roles skew senior and favor people with real-world systems experience. PhDs or visible OSS contributions (LLVM, GCC, Rust, Swift, GHC, etc.) are seen as strong entry paths.

Learning and Getting Started

• Commenters recommend classic texts (Appel’s books, the Dragon Book), interpreter/compiler books, and a few LLVM-focused resources, while noting many are theory-heavy rather than practical.
• Strong emphasis on open-source contributions and working on real compilers/toolchains as the best signal and learning path. Toy languages alone are seen as weak evidence.
• Advice: do “meaningful things” (OSS, meetups, blogs, possibly videos) rather than just mass-apply and grind interviews.

Reception of the Article and Meta-Topics

• Mixed reaction: some find the article encouraging and informative about a hard-to-enter niche; others criticize it as vague, self-promotional, or light on technical detail.
• Several lament the state of the job market if even a strong academic profile struggles to land such roles.
• Thread also detours into debates on whether software development is “engineering” and into naming famous “compiler rockstars.”

Author’s Past Controversy

• A sizable subthread revisits prior plagiarism allegations against the author, including a publisher’s public statement and disputed evidence documents.
• Some see this as clear, damning; others find the examples ambiguous or akin to shared tropes among similar writers. The ultimate assessment is left unresolved in the discussion.

Dunning–Kruger vs What AI Actually Does

• Multiple commenters argue the title misapplies Dunning–Kruger: the original research is about people misjudging their own competence, not about being fed incorrect information.
• Others say the DK meme has devolved into a generic insult (“too dumb to know they’re dumb”) and is being used that way against AI users.
• Several point to Gell-Mann amnesia / Knoll’s Law as a better frame: people see AI be wrong in domains they know, but still trust it in domains they don’t.

How LLMs Mislead (and Who’s at Fault)

• Strong theme: LLMs answer with high confidence, making it hard for non-experts to spot errors; this is framed as “being fooled” rather than “being a fool.”
• Some say it’s unreasonable to expect every user to reliably detect mistakes, especially when tools are marketed as search replacements.
• Others insist it’s foolish to treat any LLM output as fact and place responsibility on users to verify.

“Safe” vs “Unsafe” Use Cases

• Many see LLMs as fine for low‑stakes or “lorem ipsum” tasks: placeholder images, mock dashboards, quick scripts, game character names, boilerplate code.
• Pushback: even “small” uses (images with extra fingers, insecure dashboards) can signal sloppiness or introduce real risks.
• Several developers report huge productivity gains for refactoring, test conversion, bug-hunting, and tedious plumbing—provided you already understand the domain and review outputs carefully.

Regulation, Access, and Externalities

• One proposal: regulate AI use like vehicles, with licenses or aptitude checks. Counterargument: enforcing that would require totalitarian‑style surveillance, especially with local models.
• Some worry about environmental and societal externalities (CO₂, spam, scams, dependence on AI); others see these as outweighed by potential “civilizational payoffs.”

Debating the Science of Dunning–Kruger

• Long subthreads dissect the original DK paper: small samples, questionable tasks (e.g., joke rating), and claims it may be partly statistical artifact.
• Several note that popular DK graphs about confidence over time don’t actually match the original data and may be pop-psych oversimplifications.
• Meta‑irony is noted: misusing DK to critique AI may itself be a DK-like overconfidence about the effect.

Impact on Expertise and Power

• Some see AI as “Brandolini’s Law as a service”: it floods organizations with plausible nonsense that experts must then debunk.
• Others worry AI will let incompetent leaders bypass experts with “good enough” answers, reinforcing existing power structures and eroding real competence.

Status of the takedown & title framing

• Commenters note the videos were restored; some argue the headline is misleading clickbait without emphasizing that outcome.
• Others respond that temporary removal still matters: it can suppress content during peak interest (e.g., around Windows 10 EoL) even if later restored.

Why were the videos removed? Competing explanations

• One camp suspects corporate hostility: Microsoft benefits from limiting bypass instructions for hardware and account requirements; Google benefits from enforcing platform control.
• Another camp suggests more mundane “brigading”: mass false reports (especially under “physical harm” categories) by competitors or bad actors to demote rival channels.
• Several point out that YouTube says the actions were not automated, but many doubt this, citing implausibly fast “manual” reviews.
• Some believe noisy backlash (HN, media coverage) is why these particular videos were reinstated, while countless smaller creators likely stay banned.

Content moderation, censorship, and “risk of physical harm”

• Many mock the “physical harm” rationale as absurd for Windows 11 bypass tutorials, especially given abundant genuinely harmful content (scammy health videos targeting seniors, war footage, extremist material).
• Broader distrust: if platforms censor low-stakes technical content, commenters ask how they can be relied on for high-stakes topics (COVID, wars, human-rights abuses).
• Thread revisits earlier COVID-era moderation: some see platform intervention against disinformation as necessary; others see it as credibility-destroying overreach.
• Payment networks (Visa/Mastercard) are cited as parallel “infrastructure censors.”

Microsoft, Windows 11, and user-hostile design

• Strong resentment of Windows 11’s hardware requirements, TPM/secure-boot push, and online-account enforcement; seen as lock‑in, surveillance, and forced hardware churn.
• Some accept security arguments (VBS, TPM) but others view them as pretexts to tighten control and enable remote attestation.

User reactions: Linux, dual-boot, and bypasses

• Many describe abandoning Windows (or stopping at Windows 10) in favor of Linux desktops (often KDE, Mint, Debian, Fedora) and consoles for gaming.
• Others note practical blockers: specific games, DAWs, CAD tools, and “Linux evenings” of troubleshooting.
• Concrete bypass methods for unsupported Win11 installs are shared (custom setup commands, tools like Rufus, NTLite, autounattend generators), illustrating that information will spread despite takedowns.

Structural issues: scale, incentives, regulation

• Discussion emphasizes that YouTube’s incentives favor rapid, error-prone takedowns, weak appeals, minimal human support, and tolerance of abuse of reporting/DMCA systems.
• Some call for regulation: platform SLAs for responsiveness and correctness, or broader antitrust action against Big Tech concentration.

Recognition and legacy of VLC

• Many commenters see the award as well deserved, citing VLC’s long history of “just working” with any codec, rescuing people from painful codec-pack days and making them the family “computer expert” as kids.
• Several stress that VLC never added spyware or bloat, and that its refusal to be sold for big money is viewed as protecting users from “enshittification.”
• VLC is especially appreciated on Windows, Android, iOS, and tvOS where default players are seen as weak; it’s widely used for network playback (NAS, Jellyfin, casting) and niche formats (e.g. Opus, gapless albums).

User experience and technical merits

• Experiences diverge sharply:
  • Fans praise its clean-enough UI, rich controls, and low CPU usage, especially on older hardware where it can outperform mpv.
  • Critics describe the UI as clunky/dated, with odd defaults, over‑granular controls, and hostile responses to UX feedback (e.g. forced playlist/miniplayer removal, lack of backward frame-step).
  • One developer noted constant ~0.5% GPU usage even when idle, calling it a “detrimental flaw.”
• There’s debate over whether VLC is “just a thin wrapper around ffmpeg/libavcodec”; others point to its extensive module ecosystem as evidence it does much more.

Alternatives and changing landscape

• Many Linux users now prefer mpv (often via GUIs like Celluloid, IINA, Haruna), MPC-HC, SMPlayer, or K‑Lite + Media Player Classic, citing better UX or features.
• Some say operating systems now ship solid players and that the real “video world” has moved to platforms like YouTube, though others still routinely hit playback issues with default players.

Perceptions of the maintainer

• Personal encounters are mixed: some found him inspirational or “chill,” others describe him as condescending, aggressive to critical users, and dismissive on forums.
• He is praised as an “honorable” figure who didn’t sell VLC, but also criticized as abrasive.

Kyber project and commercialization debate

• Commenters are curious about the status of his low‑latency streaming system Kyber.
• There is a heated argument over whether pursuing dual-licensed, money-making Kyber—amid claims that “meaningfully zero” source has been released—constitutes “selling out.” Views are strongly split.

FSFE / award context

• One commenter briefly links to a critical blog post about the awarding organization; implications are raised but not discussed in depth, and the broader context is unclear.

Ads in Maps, App Store, and System Apps

• Many see ads in Maps as a clear degradation of a core, safety‑critical tool, especially in cars where distraction is dangerous.
• Others argue that map/search ads can be “useful and contextual” (e.g., restaurant specials, new venues), but this is heavily disputed; most commenters say they never want search order distorted by payments.
• App Store ads—especially competitor apps as the first result for brand-name searches—are widely viewed as scam‑adjacent and a long‑crossed “red line.”
• System apps like Settings, Music, Books, Wallet, and Apple News are criticized for nagging users about subscriptions, services, and upsells instead of focusing on the user’s own content.

User Experience vs Revenue Maximization

• A recurring theme: Apple once differentiated itself by prioritizing experience over “crapification,” especially compared to Google and Microsoft; ads erode that advantage.
• Some argue Apple is so profitable that it doesn’t need to monetize attention, and should treat Maps and similar tools as included in the hardware premium.
• Others counter that, as a public company with slowing hardware growth, Apple is structurally pushed toward services and ads, regardless of long‑term brand damage.

Debating “What Would Steve Jobs Do?”

• Many are tired of speculative “Jobs would never…” takes; people and contexts change, and 1999 Apple is not 2025 Apple.
• Others say there is continuity: Jobs explicitly rejected OS-level ads for UX reasons, and ads in Maps/App Store directly violate that principle, not just his aesthetic taste.
• There’s also pushback on founder worship: Jobs made serious mistakes, was often abusive, and Apple already crossed multiple “red lines” under him.

AI Image and Use of Jobs’ Legacy

• The AI-generated header image of Jobs is widely called out as tasteless and trust‑eroding, especially in an article about “red lines.”
• Several commenters object to putting arguments “in a dead man’s mouth” and using his likeness to fight today’s battles.

Broader UX, Software Quality, and Enshittification

• Many report macOS/iOS/iPadOS feeling buggier, more visually noisy, and less consistent, with design seemingly optimized for screenshots and marketing rather than day‑to‑day use.
• Examples include notification nags in Settings, Music/Books acting like stores first and players/readers second, and Maps/News/TV surfaces dominated by promotional content.
• This is frequently framed as classic “enshittification”: a gradual shift from delighting users, to serving business partners, to extracting from a locked‑in user base.

Privacy, Lock‑In, and Considering Alternatives

• Some bought into Apple specifically for “no ads + privacy” and feel betrayed; the combination of ads and government-compelled data sharing weakens the privacy narrative.
• Lock‑in (iMessage, media libraries, hardware, accessories) is seen as the main reason many will still stay, though more people report experimenting with Linux laptops, Android, or self‑hosted media as escape hatches.

Headline phrasing and article choice

• Several commenters objected to “is dead at 97” as disrespectful; others replied it’s standard, long‑standing American newspaper style that efficiently conveys both death and age.
• Some preferred non-paywalled obits; links to BBC and archived versions of the NYT piece were shared.

DNA structure, Franklin, and “stolen” work

• Large subthread on whether Watson “stole” Rosalind Franklin’s work.
• One side: Photo 51 and related data, taken by her student Raymond Gosling, were shown to Watson without her consent and were pivotal in confirming the double helix; she wasn’t properly credited and was belittled later, so this was essentially cheating.
• Other side: labs at King’s and Cambridge were already sharing data; Franklin’s work was one of several crucial inputs; the famous paper does acknowledge “unpublished experimental results” from Franklin and colleagues, so calling it theft is revisionist.
• Some detailed the lab politics around Franklin, Wilkins, and their director, arguing mismanagement and personality clashes, not a simple hero–villain story.
• Multiple people noted that Franklin and Crick remained close personally, which doesn’t fit the narrative of outright data “theft.”

Psychedelics and the discovery myth

• Question raised whether Crick was on LSD when the structure was found; several replies say this is mostly folklore with circular sourcing.
• Others think the LSD lore actually belongs to Kary Mullis (PCR) or to earlier “dream” anecdotes like Kekulé’s benzene ring.

Watson’s personality, behavior, and legacy

• Many describe him as an outstanding scientist and fundraiser but also a long‑term racist, sexist, and generally unpleasant person, with anecdotes from talks and Cold Spring Harbor.
• Some argue his later public comments (on race, women, etc.) rightly destroyed his reputation; others say greatness and assholery often coexist and we should separate work from person.
• Debate over whether obituaries should foreground his racism or his scientific contribution.

Gender, credit, and broader history of science

• Thread widens into whether women’s contributions are systematically erased; lists of both female and male under-credited scientists are traded.
• Disagreement over how much of the Franklin story is about sexism versus normal (if ugly) priority disputes in science.
• Strong book recommendations for The Eighth Day of Creation as a nuanced history of this period.

Race, genetics, and IQ

• One long subthread asks what, if anything, in Watson’s race–IQ views was evidence-based.
• Several geneticists and others say: race is a poor biological category; IQ tests are culturally and environmentally loaded; his 2007 claims weren’t supported by solid data.
• A minority cite adoption and psychometrics studies to argue for group differences; others respond with methodological criticisms, structural-racism arguments, and warnings about “scientific racism.”
• Broad agreement from many that, even if small average differences existed, they’d be useless for judging individuals and socially dangerous to fixate on.

Ruby’s Appeal and “Hidden Gems”

• Many commenters express deep affection for Ruby, describing it as the language that made them love programming and praising its elegance, succinctness, and “just fits my brain” feel.
• Ruby’s standard library and Rails ecosystem are seen as full of underused, powerful utilities (like Gem::Version), with some sharing stories of only later discovering built-in solutions they almost reimplemented.
• Several people contrast Ruby’s pleasant writing experience with frustration reading large Rails codebases, describing them as dense, magical, and hard to navigate due to metaprogramming and implicit behavior.

Ergonomics vs. Readability, Types, and Tooling

• Supporters highlight Ruby’s concise comparison operators, blocks, multiple assignment, and metaprogramming as big productivity wins; some liken its power to Lisp, with different tradeoffs.
• Critics point to “footguns” comparable to Perl: dynamic typing, runtime method generation, and convention-heavy frameworks making it hard to trace calls or reason about types.
• RBS type signatures are mentioned as helpful in some shops, but others note that major projects don’t use them and dislike separate type files.
• There is repeated contrast with Python, Elixir, Scala, Java, etc., with many showing equivalent version classes to argue those languages can be nearly as succinct.

Performance, Scale, and Tradeoffs

• One side maintains that Ruby is “slow” and that performance-conscious standard library code becomes unreadably optimized.
• Others counter that this is an outdated trope: Ruby has a JIT, serious optimization work, and powers large companies; for many apps, database or frontend complexity dominates latency.
• A recurring startup argument: prioritize developer productivity now and optimize later; opponents say this mindset discourages “nice things” and overstates Ruby’s unique productivity edge.

Ruby vs. Rails and Ecosystem Issues

• Several distinguish Ruby-the-language from Rails-the-framework, arguing that many complaints (magic, maintenance pain) are really about Rails.
• Documentation and governance for parts of the Ruby ecosystem (e.g., rubygems.org, some projects like Opal/WASM) are criticized as weak.
• Technical nitpicks clarify that Gem::Version lives in rubygems, which is shipped with Ruby but optional, and there’s detailed discussion of how Ruby’s standard library is split into default libraries, default gems, and bundled gems.

Comparisons to Other Languages and Standard Libraries

• Some argue Python’s standard library is richer and better documented (e.g., difflib), while others praise Ruby’s stdlib “gemification” model as something Python could learn from.
• There’s light debate over parentheses-less style, operator overloading, and whether Ruby’s syntax is truly more readable than modern Python/Elixir/Scala equivalents.

Design goals and scope

• Font is positioned as an ASCII-first, monospace typeface tuned for symbol‑heavy languages (Perl, Haskell, etc.).
• Key idea: multi‑character operators like ->, >>=, ::, <$>, etc. should look visually cohesive without using ligatures, so it works in terminals and editors that don’t support them.
• Designer emphasizes adjusted angles, weights, and spacing of operators (<, >, -, ~, backtick, colon) to better match real-world code usage, rather than traditional text typography.
• Font is condensed horizontally to show more code per line; derived from a customized Source Code Pro with influences from other mono fonts and built in FontForge.

Symbol alignment and readability

• Some commenters say they can’t see what’s special about the symbols and request side‑by‑side comparisons with other monospaced fonts.
• A comparison table was later added, which helps some readers see the differences and motivates trying it for Perl/Haskell.
• Others feel aligning symbols to brackets and caps makes dashes, colons, and angle brackets look too high next to lowercase letters, especially in HTML/XML/C++ generics.

Glyph choices: mixed reactions

• Curly braces are the most polarizing: some find the “S‑shaped” style noisy and distracting; others like how clearly they differ from parentheses and how they match how they’re handwritten. A “disambiguated braces” variant is suggested.
• Multiple comments criticize l vs 1 similarity; the designer is open to a variant that changes l.
• Kerning in text samples (e.g. “Lorem”) bothers some; designer prioritised strict centering over nuanced kerning.
• Caret ^ height and vertical “ASCII arrows” (^/v + |) trigger a long subthread; many consider that use extremely niche and prefer preserving the traditional elevated caret.
• Em dash is acknowledged as poorly distinguished from dash due to monospace constraints.

Ligatures, Unicode, and arrows

• Font intentionally avoids programming ligatures; designer and some users prefer explicit ASCII sequences for portability and clarity.
• Long debate over whether -> should just be a Unicode arrow:
  • Pro‑Unicode side: languages and tools increasingly support Unicode identifiers and symbols; editor macros or keybindings can insert arrows directly.
  • Anti‑Unicode side: typing such symbols is awkward on standard keyboards; ligatures and Unicode arrows can break search, selection, and semantics in languages where -> and => are distinct tokens.
• Several note that Unicode and full‑width glyphs don’t fit well with monospace constraints; Myna covers Latin extended and a subset of Unicode but is not trying to be a Julia‑style full‑Unicode code font.

Comparisons and usage preferences

• Many compare Myna to Iosevka, Ubuntu Mono, JetBrains Mono, Intel One Mono, Cascadia Code, Go Mono, IBM Plex Mono, JuliaMono, and others.
• Some love its compactness and aesthetics; others find it less legible than their current choices.
• Discussion branches into broader topics: monospaced vs proportional fonts for coding, font size and high‑DPI displays, and how much font choice matters versus actual coding.

Reaction to Rockstar Allegations

• Many express disappointment and anger, especially from fans of GTA and Red Dead, framing Rockstar’s actions as typical of large, profit‑driven corporations.
• Some say they’ll skip or delay buying GTA 6; others admit they’ll probably still buy it, noting that “good people” also worked on the game.
• Several point out that Rockstar’s long history of crunch and anti‑worker culture makes these allegations unsurprising.

Capitalism, Profit Motives, and Crunch

• A recurring theme is that union‑busting, wage theft, and abusive conditions are a rational outcome of capitalism’s demand for endless growth and higher profit.
• Others counter that any hierarchical system (capitalist or not) risks abuse, and that strong regulation, taxes, and unions are what keep capitalism tolerable.
• One commenter claims “great games” come from crunch and stress; others strongly reject this as myth, arguing that crunch is mostly about mismanagement and power, not creative necessity.

Unions: Benefits, Risks, and Organizing

• Pro‑union voices stress that union‑busting is illegal in both the UK and US, and encourage filing complaints with UK employment tribunals and the US NLRB; some share personal wins in such cases.
• There’s a fundraiser linked for the Rockstar workers’ legal fight; people debate why a union needs to crowdfund instead of using its own war chest.
• Several describe positive union experiences: better pay, benefits, WFH protections, and spillover gains even for non‑union shops.
• Anti‑union commenters argue unions can entrench mediocrity, make firing poor performers difficult, and sometimes wield “too much power” (e.g., in some US public and construction sectors). Others reply that this is not inherent and depends heavily on local law and union culture.

Comparisons to Other Game Companies

• Valve is frequently contrasted: seen by many as treating customers relatively well, running Steam competently, and avoiding mandatory crunch; critics highlight 30% platform fees, lootbox‑driven gambling, and alleged internal culture issues.
• Some argue big co‑ops or worker‑owned studios could avoid these dynamics, but note indie‑scale co‑ops already exist and face different constraints.

Consumer Power and Boycotts

• Debate over “voting with your wallet”:
  • Critics say it’s weak because workers are already paid before launch and supply chains are opaque.
  • Supporters cite recent high‑profile boycotts (e.g., in retail and gaming) that hurt revenue and executives.
• General pessimism that gamers will sustain a boycott against a franchise as big as GTA, despite ethical concerns.

Perceived Intrusiveness of Google AI

• Many commenters report AI getting more “in your face” across Google products: Gmail, GCloud search, Calendar, Chat, and especially YouTube.
• Gmail examples: “Help me write” prompts, AI reply buttons, calendar event extraction from emails, package banners at the top of the inbox, constant upsells (“use Gmail to run your business”, AI add‑ons).
• Some find this feels like “in‑product advertising” to hit engagement metrics rather than solve real problems.

Disagreement on What Gmail Actually Does

• Several users say they’ve never seen Gmail auto‑write text unprompted; for them it only activates after clicking “Help me write” or similar buttons.
• Others see AI‑generated reply choices and calendar events created from emails, sometimes wrong and sometimes hard or impossible to delete.
• A number of commenters question the article’s credibility: no screenshot, almost no detail, and nobody in the thread can reproduce exactly what’s described.
• Explanations suggested: A/B testing, regional defaults, misclicking AI reply buttons, or misunderstanding of existing “smart features.”

Turning Off Features and Limits of Control

• Multiple users note you can disable “smart features” in Gmail settings, and they’re off by default in some jurisdictions (EEA, UK, Japan, Switzerland).
• Others are skeptical this will last and argue that with SaaS you ultimately don’t control the platform; features can be forced later to satisfy internal KPIs.

Alternatives and Workarounds

• Some have moved or considered moving to Fastmail, ProtonMail, Zoho, Tutanota, Migadu, or self‑hosting; opinions differ on how viable self‑hosting is for avoiding spam filters.
• Many avoid the Gmail web UI entirely via IMAP clients (Thunderbird, Apple Mail, etc.) to escape AI and UI churn.
• Users mention browser extensions, CSS, and ad‑blockers to strip Gmail ads and YouTube AI features (auto‑dubbing, auto‑translated titles, Shorts).

Broader Critique of Google and AI Product Management

• Strong sentiment that Google optimizes for engagement metrics, not user satisfaction; users are “metrics in a promo packet,” not customers.
• YouTube’s AI auto‑dubbing and forced translations are widely cited as especially bad UX, with no global off‑switch and extra clicks to restore originals.
• Several see this as part of an industry‑wide PM problem: top‑down “More AI!” mandates despite user feedback mainly asking how to turn AI off.

Mixed Views on AI Utility

• Some find AI features genuinely useful (email thread summaries, canned replies, LLM+RAG search over archives).
• Others insist email is important enough that writing should remain intentional and human, turning all AI assistance off.

Vodafone’s change and German ISP landscape

• Commenters see Vodafone’s move to a peering intermediary as consistent with a long pattern of outsourcing and cost-cutting, not technical necessity.
• Many report poor past experiences with Vodafone (slow DSL, bad DOCSIS congestion, opaque support).
• Several note that Deutsche Telekom has long done similar things with peering and pricing; the difference is that in some buildings Vodafone is the only high‑speed option, effectively forcing customers onto this policy.
• There’s disagreement whether this is monopoly, duopoly, or cartel behavior, but broad agreement that German wired and mobile internet quality is weak for a rich country.

Impact on users and legal / practical recourse

• Users ask if severe degradation to popular services (e.g. Netflix) could be breach of contract for “1 Gbps” lines.
• Others respond that contracts usually only promise “up to” speeds to the ISP’s own network; performance to third parties is almost never guaranteed.
• Some describe success using official speed-test apps and filing complaints with federal authorities, but the process is slow and individual leverage is limited.
• Switching providers is the main advice, but many note that alternatives are often resellers on the same underlying networks, or simply unavailable in specific buildings.

Workarounds: VPNs, alternative access, municipal ISPs

• Debate on VPNs: some say they can help by avoiding congested or perversely routed paths; others note that they face the same peering bottlenecks unless the VPN provider pays for “fast lanes.”
• Starlink is mentioned but dismissed as equally subject to pricing, peering, and policy changes.
• Municipal / non‑profit ISPs (examples from the Netherlands and US cities) are presented as strong counter‑models, with cheap symmetric fiber and no throttling, though political and legal barriers often limit them.

Peering economics, regulation, and “fair share”

• Many see Vodafone’s move as part of a broader “double‑dipping” trend: charging both end users and content providers, similar to “fair share” proposals in Europe and regulations in South Korea.
• Some argue asymmetric traffic makes free peering unrealistic; others call this pure rent‑seeking that undermines the open internet and should be stopped by strong net‑neutrality‑style rules or even public ISPs.

Other networks and IX decline

• Commenters stress Vodafone is not unique: various incumbents worldwide refuse to peer domestically, causing absurd routes and congestion.
• Large content networks (e.g. Google) are also withdrawing from public IXes in favor of private deals or “verified peering providers,” which may make life harder for smaller networks and weaken the traditional open peering model.

Critique of the article

• Several readers think the article feels AI‑written: repetitive, loosely structured, heavy on slogan‑like contrasts, plus an odd disclaimer about possible inaccuracies.
• Some specific technical claims, especially around how YouTube traffic flows and the portrayal of Deutsche Telekom, are called out as oversimplified or contradictory.

Perceived Harm of Social Media to Children

• Many compare current mainstream social media to addictive drugs, arguing it harms children’s mental health, attention, and social development.
• Some want even stricter rules than Denmark’s proposal: full smartphone bans under 13 or 15, or even 18–21, and nighttime bans for teens.
• Several teachers and parents report observable issues in classrooms (distraction, meme-fueled behavior, “brain rot”) and say phone bans at school already help.
• Others distinguish “algorithmic, engagement-optimized feeds” (TikTok, Reels, Shorts, etc.) as the main problem, not all online communication.

Parenting vs. State Control

• One camp: parents should simply say no; laws are “nanny state” overreach and absolve parents of responsibility.
• Counterpoint: this is a collective-action problem. If only a few parents restrict phones, their kids are socially isolated because peers organize life online.
• Some parents explicitly welcome legal backing so their kids aren’t “the only one without a phone.”

Age Verification & Digital ID

• Discussion focuses on EU-style digital IDs that can prove “over X” without revealing full identity (zero-knowledge proofs, NFC national IDs, MitID).
• Supporters: platforms can query “is user ≥15?” and get a boolean, avoiding mass data handover.
• Critics:
  • Risk of lock‑in to Google/Apple ecosystems and exclusion of alternative OS.
  • Potential logging of which sites are queried, enabling profiling of citizens’ browsing.
  • Fundamental difficulty of tying a proof to the actual human using the account and preventing ID “lending.”

Privacy, Surveillance, and “Chat Control”

• Strong suspicion that “for the children” age bans are a wedge for broader online identification and surveillance.
• Denmark’s role in pushing EU “chat control” is cited as evidence of deeper authoritarian ambitions.
• Long subthread disputes how expansive chat-control scanning is, whether judges meaningfully constrain it, and whether it effectively breaks end-to-end encryption.
• Fear that once infrastructure for age‑gating and ID is in place, it can be repurposed for content control and selective law enforcement.

Definition and Scope of “Social Media”

• Ambiguity over what will be covered: forums like HN, Discord, WhatsApp, games with chat, YouTube, school platforms, etc.
• Some propose thresholds (e.g., daily active users) or functional criteria (algorithmic feeds with infinite reach) to focus on large, addictive platforms.
• Concern that narrow naming misses future apps; overly broad rules could sweep in benign or niche communities.

Enforcement and Workarounds

• Questions on who is liable (platforms vs. parents), penalties, and whether global platforms will just block Danish minors or Danish users entirely.
• Many expect kids to bypass bans via foreign sites, extra devices, or public Wi‑Fi; others note alcohol/tobacco age laws are also imperfect but still useful.

Alternative or Complementary Policies

• Ideas include: banning or heavily restricting personalized ads, especially to minors; regulating recommendation algorithms; banning tracking of minors; stricter school phone bans; and legal codes of conduct for youth spaces with mandatory moderation.
• Some argue the real root is the ad-funded attention economy, and that targeting that incentive would help all ages, not just children.

Historical “Brain Rot” vs. New Intensities

• Several comments argue that mass media has always “rotted brains” (radio panics, TV ads, Iraq-war hype), so AI/social media are another step in a long trend.
• Others counter that the scale, automation, personalization, and 24/7 reach of platforms and AI make the current situation qualitatively worse than legacy media or print.
• There’s disagreement whether globalized propaganda is better or worse than a few local, overtly biased outlets.

Algorithms, Enshittification, and Attention Harvesting

• Many describe Reddit, Facebook, Instagram, and YouTube as increasingly hostile: ads injected into comments, deceptive UI, low‑effort and violent content dominating feeds, and recommendation defaults pushing outrage, fear, or sexualized material.
• Long‑form, community‑oriented discussion is seen as squeezed out by engagement metrics; some say even “niche” platforms like HN are not immune, just less optimized for addiction.

AI Sludge, Rage-Bait, and Misinformation

• Multiple anecdotes of AI‑generated images and stories (cute animals, surreal memes, racial stereotypes, fake welfare recipients) being used to farm engagement and sell products or push politics.
• Many users don’t notice or don’t care that content is AI; some can no longer reliably distinguish real from fake, even when trying.
• Concern that “cultural antibodies” will lag behind each new manipulation technique, especially for children and less media‑literate users.

AI and Cognitive Atrophy

• Strong worry that LLMs encourage outsourcing thought, research, writing, and argumentation, leading to “reaction not reflection.”
• Analogies to writing, calculators, cars, dishwashers: tools both empower and atrophy unused skills; the question is whether the trade‑off is worth it.
• Some report AI enabling them to tackle more complex projects and learn new domains; others say the more they use AI, the less value they see and the more they distrust it.

Education, Skills, and Search

• Anxiety that students using ChatGPT for homework and teachers using it for grading produce a “bots talking to bots” system and graduates who can’t think on their feet.
• Debate over whether worrying about “traditional Google search” skills is valid, given how degraded search has become.
• Speculation that future hiring might favor those trained before ubiquitous LLMs, though this is acknowledged as speculative.

Coping Strategies and Alternatives

• Some commenters have quit or sharply limited social media and report feeling noticeably better.
• Suggestions: treat social media as a dangerous “digital narcotic,” avoid algorithmic feeds, use AI only as an assistive tool (“show me how,” not “do it for me”), and consciously prioritize offline activity and original thinking.

Perceived strengths of OCaml

• Many commenters agree with the article’s core praise: fast compilation, good performance, strong static typing with powerful inference, pattern matching, algebraic data types, and a pragmatic stance on mutation.
• Multicore + effect handlers are seen as a big advance, giving a modern concurrency story and potentially putting OCaml “ahead” in PL design.
• The module/functor system, named arguments, structural OO, and REPL are singled out as unusually powerful/pleasant for large systems and code generation.

Pain points and “friction”

• Ecosystem size is the main complaint: far fewer high‑quality libraries than mainstream languages; even basic things like OAuth2 clients or file-copy helpers are missing from stdlib.
• Tooling is viewed as uneven: opam is powerful but “weird/buggy”; ocamlformat defaults frustrate some; debugger and gdb integration are cited as weak vs. other ecosystems.
• Windows support is widely criticized as historically bad, only recently improving.
• Documentation is often terse and type‑signature‑only; examples and beginner‑oriented material are lacking.
• Syntax divides people: some like the minimalist ML style; others find it dense, hard to parse, and especially dislike the OOP syntax.

Ecosystem and industry use

• OCaml is acknowledged in compilers, theorem provers, FFTW’s generator, Tezos, Jane Street’s trading systems, Facebook’s typecheckers and tools, etc., but that’s still seen as niche.
• Some argue that needing in‑house forks (e.g., at large firms) shows the language is “almost there”; others say that’s normal for serious industrial users.

Comparisons to other languages

• Rust: often seen as having “stolen OCaml’s thunder” by bringing ADTs, pattern matching, strong typing into a more familiar systems language; but many stress Rust feels very different (no GC, traits instead of modules, borrow checker).
• F#: closer to OCaml but criticized for slower compiler, CLR entanglement, weaker type inference, and playing second fiddle to C#. Others praise its ecosystem and docs and prefer it on Windows.
• Haskell: more research‑y and pure; OCaml is seen as more pragmatic, easier to write in an imperative style when needed.
• Elixir/BEAM: viewed as “OCaml‑adjacent” in spirit (immutability, pattern matching, actors) with a much better story for web backends, but different trade‑offs (dynamic, VM, NIF pitfalls).
• TypeScript: some claim it gives “similar” type safety with far better tooling; others push back, pointing out TypeScript’s deliberate unsoundness and heavy use of any.

Why isn’t OCaml more popular?

• Competing explanations:
  • Ecosystem/tooling and Windows support lag far behind more popular languages.
  • Syntax and “functional” branding scare off mainstream, C/Java‑raised developers.
  • Popularity is driven more by platforms, killer apps, and marketing (Java, Python, JavaScript) than by language merit; OCaml never had a browser, big-company push, or AI moment.
  • Fragmentation across the ML family (SML, OCaml, F#, Reason, etc.) dilutes mindshare.
• Some insist “frictions are overstated” and that momentum and familiarity (e.g., Go’s intentional simplicity) matter more than technical drawbacks.