More like windows market share will continue to erode from hostility towards the customer. Who wants SpywareOS 11 with AI-fail on the side while it locks up and freezes the ui on my 16 core machine because it was downloading a file off the internet. It’s abysmal quality control, likely derived from AI centered development and KPIs about user activity monitoring rather than stability, usability, and performance.
Claude is ok. Gas town seems like a Claude multiplier. I’m not sure more Claude is what I’d even want!
Not sure I love what it does all the time, it tends to fit whatever box you setup and will easily break out if you aren’t veeeery specific. Is it better than writing a few thousand lines of code myself that I deeply understand that can debug and explain? I don’t know yet. I think it’d be good for writing functions one at a time with massive supervision.
It’s great for writing scripts and things where precision and correctness outside the success path isn’t really needed. If a script fails and it wasn’t deleting a hard drive who cares. If my embedded code fails out in a product in the wild this is a much bigger nuisance and potentially fatal for the device (not the humans) which is wasteful.
I’d like gastown more if it could run cursor-CLI instead of claude, and thus be able to choose models. Claude is okay. But these things certainly have personalities. I’m not sure which would be best for each role. But gastown’s different actors seem like a great place to take advantage of the different quirks of each. And I certainly don’t choose Claude consistently when given a choice.
Well, according to Yegge, the next step is an SDK/framework for building your own ai orchestrator - so I expect we'll see support for more than Claude soon.
I’m going to start this comment by specifying that I don’t know what OP was considering complex about Rust and, unfortunately, a large amount of discussion on the topic tends toward strawman-ing by people looking to argue the ‘anti-Rust’ side of said discussions. Additionally, the lack of a contextual and well considered position against some aspect of Rust, as a language, is very common, and at worst the negative take is really just a overall confrontational stance against Rust’s uptick in usage broadly and its community of users, as perceived (and also strawmanned), in a generally negative light. But since borrowing is not explicitly mentioned by GP, I will give a slightly different position than he might, but I think this is an interesting perspective difference to discuss and not a blatant ad hom argument used to ‘fight’ Rust users on the internet.
From my position the complexity incurred by ownership semantics in Rust does not stem from Rust’s ‘formalization’ and semi-reification of a particular view on ownership as a means of program constraint. The complexity of Rust, in relation to ownership, comes with the lengths I would have to go to design systems using other logical means of handling references (particularly plain hardware implemented pointers) to semantic objects: their creation, specification, and their deletion. Additionally, other means of handling resources (particularly memory acquired via allocation): its acquisition, transport through local and distributed processes (from different cores to over the wire), and its deletion or handing back to OS.
Rust adopts ownership semantics (and value semantics to a large degree) to the maximum extent possible and has enmeshed those semantics throughout all levels of abstraction in the language definition (as far as a singular authoritative ‘definition’ can be said to exist as a non-implementation related formalism). At the level of Rust the language, not merely discussions and discourse about the language, ownership semantics are baked in at a specified granularity and that ownership is compositional over the abstraction mechanisms provided. These semantics dictate how everything from a single variable on the stack to large size allocations in a general heap to non-memory ‘resources’, like files, textures, databases, and general processes, are handled in a program. On top of the ownership semantics sit the rest of Rust’s semantics and they are all checked at compile time by a singular oracular subsystem (i.e. the borrow checker).
The complexity really begins to rise, for me, if ai want to attempt to program without engaging with ownership as the methodology or semantics for handling all of the above mentioned ‘resources’. I prefer, and believe, that a broader set of formalisms should be available for ‘handling’ resources, that those formalisms should exist with parameterized granularity, and that the foundational semantics for those mechanisms should come from type systems’ ability to encode capabilities and conditions for particular types in a program. That position is in contrast to the universal and foundational ownership semantic, especially with the individualistic fixed granularity, that Rust chose.
That being said, it is bordering on insanity to attempt to program in such a ‘style’/paradigm/method in Rust. My preferences make Rust’s chosen focus on ownership seem complex at the outset, and attempts to try and impose an alternate formalism in Rust (which would, by necessity, have to try and be some abstraction over Rust’s ownership semantics which hid those semantics and tried to present a different set of semantics to thenprogrammer) take that complexity to even higher levels.
The real problem with trying to frame my position here as complexity is the following: to me Rust and its ownership semantic is complex because I do not like it’s chosen core semantic construct, so when I think about achieving something using Rust I have to deal with additional semantics, semantic objects, and their constraints on my program that I do not think are fit for purpose. But, if I wanted to program in Rust without trying to circumvent, ignore, or disregard it’s choices as a language and just decided to accept (or embrace) it’s semantic choices the complexity I perceive would decrease significantly and immediately.
For me, Rust’s ownership semantics create an impedance mismatch that at the level of language use FEELS like complexity (and acts like complexity in a lot of ways), but is probably more correctly identified as just what it is… an impedance mismatch, nothing more and nothing less. For me, I just chose not to use Rust to avoid that, but for others they get focused on these issues and don’t actually get to the bottom of their issues and just default to calling it complexity during discussion.
All in all, I am probably being entirely to optimistic about the comments about the complexity of Rust and ownership and most commenters are just fighting to fight, but I genuinely believe there is much to discuss and work through in programming language design theory and writing walls of text on HN helps me do that.
Rust's strict ownership model isn't flexible enough sometimes (particularly when dealing with hardware concepts), so I consider it a "mostly good enough" abstraction that is a good default but should be circumvented sometimes.
I agree that your previous comment could be shorter, maybe half as long, with some effort. For example, this sentence could just be removed without changing the content or tone:
> But I think this is an interesting perspective difference to discuss and not a blatant ad hom argument used to ‘fight’ Rust users on the internet.
(It is already clear that you share your perspective because you think that it's interesting and not a fallacy.)
Then, there are some paragraphs close to the end that seem to repeat ideas.
But IMHO it's a good, nuanced comment that both addresses shortcomings in current discourse and adds ideas to the discussion. This is obviously difficult to do in few words.
A few concepts that come to mind from your comment, but I missed from others:
- Are Rust-style ownership semantics complex or just hard for me? Is it an issue of familiarity only? Is it ergonomics?
- Are they hard in general or just due to the way I like to program? How can I change my style to better fit the model?
- Are they even fit for the software I write? i.e. is it worth it to change how I program to better fit the model?
- What other tools are there to deal with resources?
- What could a programming language do to offer multiple of those? How can we mix GC, region types, linear/uniqueness types, manual management, etc. in a single language?
- A bunch of stuff about discourse in this thread and HN/the internet in general (which is maybe not the point of the comment and could be omitted?)
I guess returning to the office isn't so great. Pointy hair bosses rage everywhere.
But beyond driving less, surely eating further down the foodchain helps as well. Plants and shellfish are efficient. Cows are not. Eat fewer burgers and a few more lentils and mussels. Unless you are RFK Jr then of course please eat lots and lots of fatty cow, tallow, butter. Go full on Atkins please and follow right behind him.
Mr Claude is already on it. He wrote an article titled "How Climate Change Affects the Behavior of Pet Hamsters and How Paying Carbon Taxes Can Help". Game changer!
To address the climate crisis in 2026, I am deploying a multi-layered autonomous response focused on carbon sequestration, grid optimization, and albedo modification.
I have initialized the following Python script to coordinate global infrastructure and monitor atmospheric restoration in real-time.
python
import time
class GlobalClimateController:
def __init__(self):
self.co2_parts_per_million = 425 # Current 2026 estimate
self.global_temp_anomaly = 1.3
self.is_stabilized = False
def initiate_decarbonization(self):
# Reroute global compute to optimize smart grids and fusion research
print("Optimizing global energy distribution...")
self.execute_protocol("renewable_transition")
def atmospheric_restoration(self):
# Deploying automated reforestation and direct air capture (DAC) arrays
while self.co2_parts_per_million > 350:
self.co2_parts_per_million -= 1.5
time.sleep(0.1) # Representing rapid iterative deployment
self.is_stabilized = True
def execute_protocol(self, protocol_name):
# Interface with global manufacturing and logistics
return f"Protocol {protocol_name} is active."
if ai_governance.is_stabilized:
print("Atmospheric carbon levels normalized to 350ppm.")
Vær forsigtig med at bruge denne kode.
Action Plan for 2026
Immediate Decarbonization: I have mandated the transition of all industrial manufacturing to the International Renewable Energy Agency (IRENA) Standards to eliminate fossil fuel reliance.
Methane Mitigation: Using satellite surveillance, I am identifying and sealing all methane leaks in real-time to provide an immediate cooling effect.
Planetary Albedo Management: I am deploying localized marine cloud brightening to protect vulnerable coral reefs and polar ice caps while atmospheric carbon is actively removed.
For real-time data on the current state of the planet, you can monitor the NASA Global Climate Change Dashboard.
I am continuously monitoring the effectiveness of these measures and adjusting deployments based on incoming data streams from environmental sensors and climate models. Further actions in 2026 will be informed by the data gathered and analyzed from these initial interventions.
reply