Hacker News new | past | comments | ask | show | jobs | submit | more pornel's comments login

This problem is already solved in places with more developed infrastructure:

• Workplaces can have chargers in their parking lots. In places where cars are parked for many hours, slow chargers are sufficient, which makes them relatively cheap and easy to install, so they can be plentiful.

• Malls, supermarkets, gyms, restaurants, etc. can have medium and high power chargers. BEVs need 20-30 minutes to recharge from a high power charger. You can do your weekly shopping while your car recharges.

• Charging posts can be installed along roads with on-street parking. In some places even lamp posts can be modified to have charging sockets.

Modern EVs used for commuting need to be charged only about once a week (BEVs are most efficient in city driving, and the median US commute is 1/10th of good BEVs city range).

With the infrastructure in place, daily use of BEVs is more convenient than ICE, because you never need to go to a gas station. BEVs charge unattended, so you don't even spend the 5 minutes refuelling. You plug your car in and leave to do whatever you wanted to do at the destination you were going to anyway.


None of this solves the issue of charging at scale. How would you solve a small town of, say, 20 000 people charging for 20-30 minutes at a mall? Note: peak for "weekly shopping" is usually just the weekend.

For on-street parking (and any parking general) it's still a lot of investment in infrastructure, as it's not just hanging an extension cord from your outlet.


You're talking in hypotheticals, but Norway has 80%+ market share of BEVs, and quite a few towns with 20,000+ residents. There are already many multi-megawatt charging locations built all around UK and Europe. It's an expensive infrastructure, but when there's demand, it pays for itself. When it's busy, they build more. Growth of the grid is also manageable: https://www.youtube.com/watch?v=7dfyG6FXsUU

High-speed charging locations that have very uneven usage with peaks, save costs by using dynamic power sharing (so capacity isn't wasted when a car that has finished charging occupies a dispenser), and have battery storage on site to use a cheaper smaller grid connection, and usually also make extra money from power arbitrage.

> it's not just hanging an extension cord from your outlet.

It almost is! For slow (overnight) AC charging the expensive inverter is in the car. The "charger" on the street is just an extension cord with a network-connected switch and a few temperature sensors for safety. BTW, home "chargers" (EVSE) are overpriced. Many of them are literally a Raspberry Pi and some switches.


> You're talking in hypotheticals,

I live in a Stockholm suburb. Any infrastructure investments are met with "it's too expensive" and/or "current infra will not support charging infra".

> High-speed charging locations that have very uneven usage with peaks, save costs by using dynamic power sharing (so capacity isn't wasted when a car that has finished charging occupies a dispenser), and have battery storage on site to use a cheaper smaller grid connection, and usually also make extra money from power arbitrage.

That wasn't my point, is it? High-speed charging locations will be congested exactly because of uneven usage with peaks.


Here's more about electric tugboats: https://www.youtube.com/watch?v=mu9XZIpOTcw

They can have super high torque. Quiet motors allow them to operate where diesel wouldn't be allowed due noise pollution.


Nix also breaks if you try to update it, and you'll eventually have to update for security issues.

I'm stuck with a defunct Nix project I can't update, because crane and fenix flakes made breaking changes, and nix is giving me incomprehensible errors. I've spent enough time googling the errors that I'd be quicker to start over with a nix-less VM.


These are cheap "city" EVs with small batteries and slow charging. They have all the compromises and annoyances that people don't like about EVs.

The desirable EVs have 2x-3x more range and charge 3x-4x faster. That completely changes the equation, because that makes them good enough to be the primary/only car. Even for people who don't have a charger at home, even for people who need to drive long distances.


For compatibility with the Web content, the `click` event has become a device-independent activation event. Sites can't be expected to listen for events from every kind of device, so instead all devices send `click`s.

They care, because focus for keyboard-controlled screen readers sending "click" should behave differently: an element inside the menu should receive focus, even though it's not the element that has been clicked. Otherwise if focus stayed on top-level menu bar, screen reader users would be lost, and had to navigate to menu's content themselves.


Interesting. Seems like something that should be exposed more explicitly.


I'm amazed how well the Send/Sync bounds work.

Finding all possible data races in arbitrarily large and complex programs (even across 3rd party dependencies and dynamic callbacks) seems like a challenging task requiring specialized static and dynamic analyzers. But it turns out it can be reduced to automatically marking structs as safe to move to a thread, and type annotations on mutexes and thread-spawning functions.


It's an example of richer, expressive interfaces that allocate responsibility for who ensures what behavior properly for the problem. Send and Sync don't fundamentally make thread safety easier. What they do is that library authors can provide abstractions to users and each side has a clear scope of diligence. Rust's realization through Send/Sync is more complicated in practice, demonstrated by that one bug for Mutex(Guard?) in the standard library, but pulls its weight well.


How does it prevent two actors from waiting on each other?


There are no locks. There is no blocking wait, the IO lib is nonblocking throughout. Actors cannot wait.

Messages are guaranteed to be processed ordered sequentially.

https://tutorial.ponylang.io/index.html#whats-pony-anyway


There are while loops, though, so actors can still livelock.


Because most applications aren't written in C++.

People don't write web apps in C++, because they would have to deal with memory safety issues in addition to all the other issues related to auth, injections, etc.


I'm concerned that Bluesky has taken money from VCs, including Blockchain Capital. The site is still in the honeymoon phase, but they will have to pay 10x of that money back.

This is Twitter all over again, including risk of a hostile takeover. I don't think they're stupid enough to just let the allegedly-decentralized protocol to take away their control when billions are at stake. They will keep users captive if they have to.


EU should simply buy it.


True, you need to know what is and isn't possible in the borrow checking model to avoid learning it the hard way after writing the code.

There are some gotchas that you need to learn (e.g. self-referential structs won't work, or & returned from a &mut method won't be shareable).

But besides a few exceptions, it's mostly shared XOR mutable data in the shape of a tree. It's possible to build intuition around it.


Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: