> Great post. This should be the default configuration, community can make discussions, contributors can make issues.
I'm not so sure. I think this sort of discussion mostly falls within the realm of bike shedding. I'll explain why.
There's such a thing as a ticket life cycle. Ticketing flows typically feature a triage/reproduction stage. Just because someone creates an issue that doesn't necessarily mean the issue exists or isn't already tracked somewhere else, or that the ticket has all the necessary and sufficient information to troubleshoot an issue. When a ticket is created, the first step is to have someone look at it and check if there's something to it. This happens even when tickets are created by internal stakeholders, such as QAs.
GitHub supports ticket labels, and the default set already cover these scenarios.
To me this discussion sounds like a project decided to update their workflow to move triage out of tickets and into a separate board. That's fine, it's the exact same thing but with a slightly more complex process. But it's the same thing.
Security. I host personal sites on Linodes and other external servers. There are no inbound ports open to the world. Everything is accessed via Cloudflare Tunnels and locked down via their Zero Trust services. I find this useful and good, as I don't really want to have to develop my personal services to the point where I'd consider them hardened for public internet access.
When you have a simple tool you have written for yourself, that you need to be reliable and accessible but also that you don't use frequently enough that it's worth the bother of running on your own server with all of that setup and ongoing maintenance.
The DX is great: simple deployment, no containers, no infra to manage. I build a lot of small weekend projects that I don't want to maintain once shipped. OpenWorkers gives you the same model when you need compliance or data residency.
> But do you need 300 pops to benefit from the edge model? Or would 10 pops in your primary territory be enough.
I don't think that the number of PoPs is the key factor. The key factor is being able to route requests based on a edge-friendly criteria (latency, geographical proximity, etc) and automatically deploy changes in a way that the system ensures consistency.
This sort of projects do not and cannot address those concerns.
Targeting the SDK and interface is a good hackathon exercise, but unless you want to put together a toy runtime to do some local testing, this sort of project completely misses the whole reason why this sort of technology is used.
> Anyway if the "DX" is a kind of runtime, in which actual contexts is it better than the incumbents, e.g. Node, or the newer ones e.g. Deno or Zig or even more broadly WASI?
I'm not the blogger, I'm just a developer who works professionally with Cloudflare Workers. To me the main value proposition is avoiding vendor lock-in, and even so the logic doesn't seem to be there.
The main value proposition of Cloudflare Workers is being able to deploy workers at the edge and use them to implement edge use cases. Meaning, custom cache logic, perhaps some pauthorization work, request transformation and aggregation, etc. If you remove the global edge network and cache, you do not have any compelling reason to look at this.
It's also perplexing how the sales pitch is Rust+WASM. This completely defeats the whole purpose of Cloudflare Workers. The whole point of using workers is to have very fast isolates handling IO-heavy workloads where they stay idling the majority of the time so that the same isolate instance can handle a high volume of requests. WASM is notorious for eliminating the ability to yield on awaits from fetch calls, and is only compelling if your argument is a lift-and-shift usecase. Which this ain't it.
Indeed "global edge network and cache" is not my interest. I do prototyping so I don't care about scale or super low latency Worldwide. If I want to share a prototype I put on my small server in Germany, share the URL and voila, good enough.
That being said I understand others do, so this helps me understand the broader appeal of cloud workers and now some limits of this project.
> What if we hosted the cloud... on our own computers?
The value proposition of function-as-a-service offerings is not "cloud" buzzwords, but providing an event-handling framework where developers can focus on implementing event handlers that are triggered by specific events.
FaaS frameworks are the high-level counterpart of the low-pevel message brokers+web services/background tasks.
Once you include queues in the list of primitives, durable executions are another step in that direction.
If you have any experience developing and maintaining web services, you'll understand that API work is largely comprised of writing boilerplate code, controller actions, and background tasks. FaaS frameworks abstract away the boilerplate work.
In the last year alone, around 2/3 of space X's revenue was directly tied to starlink launches.
> If they lost all government and private launch business tomorrow and had to rely on Stalink revenues to stay in business they wouldn’t last through next month.
> The issue is it had the range of a golf cart. So it basically ruled out 98% of the population that needs a car that can go on road trips.
You're trying to use weasel words to try to hide the fact that the Nissan Leaf, which was released in 2010 and elected world car of the year, was the world's most successful electric car and top-selling electric car until 2020.
That does not happen if 98% of anything doesn't like it.
Any claim involving "road trips" is a red herring because the Nissan Leaf was designed as a city car used in daily commutes, which means a daily driver for your 1h trips. This is by far the most popular use of a car in the world.
Why do you think it's design range was slightly over 300km? That roughly represents a ceiling of a round trip that takes 2 hours each direction.
For over a decade, the whole world has been buying Nissan Leafs more than any other electric car. How do you explain it?
> That does not happen if 98% of anything doesn't like it.
Actually it does. Electric car sales were so anemic during that time claiming the title made it trivial to be supported by 2% of the population.
> Any claim involving "road trips" is a red herring because the Nissan Leaf was designed as a city car used in daily commutes, which means a daily driver for your 1h trips. This is by far the most popular use of a car in the world.
No it’s not. “Range anxiety” was a constant refrain for anything mentioning electric cars during the first 20 years of the century.
A “city car” isn’t a concept in the US. Only when you get into upper middle class where people can afford multiple cars per household is when you could sacrifice one car like this.
I dunno, as someone who was raised in a pretty rural area and has since lived in both cities and suburbs, I think the need for long distance driving is dramatically overstated.
From my rural hometown, the drive to varying degrees of civilization (just big enough to have a small shopping center up to the state capital) is about 25 and 75 miles, respectively. Cities sized in between are around 40-50mi out. The drive to the nearest tiny town for groceries and such is about 2 miles.
I currently live in a suburb and everything one might need, including an international airport, is within a 30mi radius, with the majority of that being within a 5mi radius.
With that in mind and remembering that the bulk of the population lives in cities or their surrounding metro areas, "city cars" are viable for more people than they aren't. Sometimes they'd be better suited as secondary vehicles dedicated to errands, which at first glance might seem more expensive, but the dramatically better fuel economy of e.g. a tiny hybrid or even plain gas car quickly adds up, and in states with cheap electricity combined with scheduled charging at off-peak times, the scales are tilted even further if you have a plug-in hybrid or full EV. The up-front cost is higher, but you quickly make that back from not having to haul the big gas hungry SUV or truck around all over the place.
More than half of US households have multiple cars. The market that can handle a limited-range car is enormous; most of those households and many single car households too. And the existence of range anxiety doesn't change that.
> Actually it does. Electric car sales were so anemic during that time claiming the title made it trivial to be supported by 2% of the population.
What are you talking about? The Nissan Leaf was the world's best-selling electric car until 2020, outselling all Tesla's until Tesla Model 3 surpassed it. Are you trying to claim with a straight face that electric cars weren't being used en masse until 2020?
> No it’s not. “Range anxiety” was a constant refrain for anything mentioning electric cars during the first 20 years of the century.
I don't think you are being serious. "Rage anxiety" was literally GM propaganda to throw FUD at electric cars.
> Put that on your resumé and you'll easily land a cushy job in Washington.
I think you have it backwards. The entire tech bro scene reeks of fraud schemes, and the most successful ones seem to be pulled into all kinds of government schemes as well.
> For years, we've been told a lot of things that have never come to fruition.
Sometimes I wonder if Musk's astronomical pay package is an engineered rug pull on Tesla's investors. Imagine if they know the jig is up and intend to fleece stockholders one last time by leaving them holding the bag when the house of cards comes crumbling down.
I'm not so sure. I think this sort of discussion mostly falls within the realm of bike shedding. I'll explain why.
There's such a thing as a ticket life cycle. Ticketing flows typically feature a triage/reproduction stage. Just because someone creates an issue that doesn't necessarily mean the issue exists or isn't already tracked somewhere else, or that the ticket has all the necessary and sufficient information to troubleshoot an issue. When a ticket is created, the first step is to have someone look at it and check if there's something to it. This happens even when tickets are created by internal stakeholders, such as QAs.
GitHub supports ticket labels, and the default set already cover these scenarios.
https://docs.github.com/en/issues/using-labels-and-milestone...
To me this discussion sounds like a project decided to update their workflow to move triage out of tickets and into a separate board. That's fine, it's the exact same thing but with a slightly more complex process. But it's the same thing.
reply