I think changing the calendar is much, much more complicated than making the work week 4 days long. There's countless systems that depend on the current calendar. It would be a herculean undertaking
This. And you won't have a consistent tracking mechanism anymore. You would have a month shift every decade. As a child the season in January might be winter, but as an older person it might be summer. The laws, customs, etc would need a drastic overhaul.
I'm not sure why lengthening the months got folded in with lengthening the week.
Months and weeks are completely independent, we could have an eight-day week and keep months precisely as they are now.
I think it's way too weird to actually do it, but it's less weird than having a cycle of months that's longer than a year.
Islam manages, somehow, to have a cycle of months that's substantially shorter than a year, and doesn't throw in an extra month from time to time like Jews do. I've always found that exceedingly strange, but I guess you get used to it.
That's not what I meant by laws need to change. I mean that we use calendar dates for laws that are tied to seasonal attributes. As a simple example, dates are set in law as a beginning and end date for when you are allowed to use studded snow tires (eg 10/15 - 4/15). Now you would have to go back through all that legislation for every date in law to see if it would need to be subjected to a shifting scheme. Stuff like tax day might not need to change, but school years would need to adjust every year, because the main purpose of it set the way they are is for agriculture labor on family farms (although that is a shrinking concern).
But again you can still have a 3 day weekend by simply shortening the work week. It also has the added bonus that your ratio of days off to days on is 3:4 instead of 3:5.
Meaning you get more days off by shortening the work week than you do by making all of society adapt to adding an extra day to the week.
People care about seasons and regularity a great deal. I know that it’s warm in the summer, so I’ll book a beach holiday then. Moving my vacation plans by a few weeks every few years to ensure they’re still in good weather would be a nightmare. Not least because people would probably want school holidays to match that time period.
The calendar feels very illogical and made up compared to most measurement systems but there’s a reason why they are what they are! A much more realistic proposal would be to just give people every other Friday off. Or work one Friday a month, something like that.
The French First Republic[1] and the early Soviet Union[2] both briefly reformed their calendars, but in both cases the changes were reverted after a couple of years. There's also a whole bunch of proposed calendar reforms[3], each with its pros and cons. But again, it looks like historically there's been too much resistance against calendar reforms.
That would uncouple the months from the location of Earth in its orbit. If you're going to do that, you might as well go full-bore and just adopt a calendar that counts days, 8-day weeks, and years and forgo months entirely.
If you're going to keep months, but have an 8-day week, I'd rather see something like: 9 months of 5 weeks each (40 days) with an extra 4 days at the end or beginning of the year. Leap days could be appended to the extra week. This has the added benefit that the 8th is always Blernsday in any month.
In any case, I think there are advantages to only working 4-days in a row; and 4/3 is a better ratio for workers than 5/3; and I think you're just moving the goal posts, really. People 50 years from now would be arguing about going to a 4/4 week...
Eh, i think i'd prefer 4-3 more than 5-3. For the same reason that i'd rather not work 60 days straight and take an extended period off.
As it is, lately i've been working longer chunks of days in a row, 14+ days without breaks and it drains me. It feels like each day after the next really compounds.
It's also why i dislike longer vacations. I get super antsy after day 3 or 4.
I think people value working to the same work day schedule as everyone else so your time off is aligned. That is how Friday night drinks and Sunday brunch works with friends.
PMs have gotten addicted to the sugar rush of features and developers to fried salty frameworks, creating a culture of obesity in software engineering. This needs to stop. Every prod test should go through a 10 year old system and perform satisfactorily.
I have a 4 year old laptop that cost me $3000. Xcode is so laggy sometimes that if I type, it'll miss keystrokes and words come out garbled beyond recognition. A few weeks ago some source code I downloaded from github wouldn't compile because the swift compiler spent too long doing type inference, and decided to error out.
I'm haunted by a vision of computing. In the vision, us software folks just add bloat to everything until it starts feeling gluggly and slow on our modern expensive computers. Then we optimize our programs just enough to keep them running vaguely ok on whatever hardware is on our desks.
The only way to have a snappy computer running modern software is via the tireless work of hardware engineers. Whenever a big hardware performance improvement comes (like the M1), there's a window of a year or so where if you upgrade, everything will run fast again. And of course, all the devs with the new machines stop optimizing their programs and gradually everything slows down again. Eventually our software goes back to being as slow as it was before, except if you didn't upgrade your computer, now it barely functions.
I want off this ride. My 6 year old FreeBSD server is somehow still snappy and responsive. Maybe the answer is to just not run modern desktop software.
A good chunk of that is unique to the swift part of xcode. Do the same things in an Objective-C codebase and you'll be surprised about how snappy and non-buggy everything is.
I maintain today you could've gotten %80-%90 of the benefits of swift with a syntax refresh and add a few new cheap to compile features to Objective-C itself, like stronger nullbables and the ADT enums.
I think the 'good enough software' stuff will stop happening when physical limits start limiting improvements in compute, because the only way to have a competitive advantage then is through better software.
I hope that day is far away although, because it means that something like 8k consumer VR is something that will never happen, where the software is written properly to take proper advantage of the hardware.
Right; probably because most of the obj-c compiler toolchain was implemented when computers were slower. I was beating on xcode in my comment because it deserves it, but this problem isn't confined to xcode and swift. Compiling rust is also extremely slow. The new reddit feels like a slideshow (and despite launching years ago, how have the reddit team still not fixed the performance problems??)
We're having this conversation in the context of notion. Starting up Notion on my laptop feels like wading through honey. I really want to love notion, but every time I open it and try to do anything I find my motivation tricking away. Notion isn't even doing anything impressive with all that compute - its just slow. The sales pitch I make in my head for notion is that its a place to organize all my notes and workflows, but like Jira, living in notion means accepting that I work at the speed notion does, and that feels antithetical to the feeling of productivity I have in snappier, lighter tools like Bear and iA writer.
But Notion and XCode aren't really the problem. The problem is cultural. It seems to be the worst in the web ecosystem, though its not confined there. My favorite example of all is this issue in web3.js[1]. I can't help but play Benny Hill music in my head while I scroll through this 3 year old, apparently unsolvable issue thread.
When the new M1 macs came out lots of people were complaining that there's no 32 gig variant. Holy cow that is so many bytes. The Atari 2600 had 128 bytes of ram. The NES ran super mario bros in 2kb. Its completely ridiculous to me that our software can even fill 16gb doing everyday computing. Is there a ceiling? Will there ever be a ceiling, or should we expect a document editor in 2030 to sit on 256gb of ram, just because thats how much ram modern javascript frameworks use by then?
It's an economic tradeoff. Engineers are expensive and businesses choose what is most productive for them to what customers respond to. Also performance work is not fun and more work than new features. Performance bugs are harder to detect and quantify than normal crash bugs and such because they are statistical ranges, not binary on off states.
Performance is taken into account when it matters for the product, you'll notice this in games where they do a lot of perf improvement work.
Also swift & rust are slow due to their design as a language. They provide very strong guarantees and make a lot of thing static. It's very similar to the reasons why C++ is slow to compile.
Also notion is like 10 engineers last time I checked, and they've decided to go towards speed of dev & features more than nicer, but slower to develop tools.
The economic stuff fails to account for slow death of their product as customers don’t even know how things have gotten slower over the years. Then all of a sudden a snappy competitor product appears and they jump the ship en masse.
The business people are still clueless and continue to double down on more features their customers don’t want. While the competitor is gaining market share.
> Performance is taken into account when it matters for the product, you'll notice this in games where they do a lot of perf improvement work.
I think most development shops chronically underestimate how much application performance matters for sales. Most people will never file bug reports when software is slow. They just "won't like that program for some reason". (Or worse, misattribute the reason they don't like your product.) Slowness is invisible to the developers because they're almost always using computers which are much faster than the computers their customers are using. And unless you actually take the time to record performance statistics, you won't have any idea this is the case.
Game developers know this. People measure the FPS they get on their gaming computers. But as far as I can tell, the reason isn't an essential quality of video games. The difference is culture. There's a culture in video game development of measuring performance. People have the tools and terminology to talk about it. In comparison, what are notion's performance numbers like? Does notion run at 60fps for the average user? How many ms of typing latency does it usually encounter? Does the team even know?
> Also swift & rust are slow due to their design as a language. They provide very strong guarantees and make a lot of thing static. It's very similar to the reasons why C++ is slow to compile.
Roll to disbelieve. Swift and rust are simpler languages than C++, and yet compile much more slowly. The reason C++ seems to compile slowly isn't templates. Its because of the way C++ header files need to be parsed over and over again, and thats not a problem rust and swift share. (Rob Pike has some great rants about this if anyone's interested.) A well written, from-scratch Swift compiler should be able to get compilation speeds closer to Go. At least, for debug builds.
I suspect if swift and rust were invented 20 years ago, we would still have been able to write compilers that ran at tolerable speeds on the computers of the day. And if thats the case, the reason for slow compilation speed is something other than language design.
> Also notion is like 10 engineers last time I checked, and they've decided to go towards speed of dev & features more than nicer, but slower to develop tools.
Notion can make that choice if they want. But until they fix performance, I won't / can't use their product.
> Also performance work is not fun
Speak for yourself - I love performance work. Its so measurable and the feeling of taking something sluggish and making it scream is delightful.
I work in improving performance at a big tech company. It can be like dragging feet to get executives, managers and developers to care about improving performance because incentives are misaligned and it's frankly a chore compared to the million other things you have to be doing. It's also significantly harder to show the business metric improvement that comes from performance improvements than it does from simple A/B tests due how much variance there are in performance metrics compared to A/B testing. It's very much like security actually.
For games, it's not a 'culture', it's because games become very frustrating to play when non-responsive in anything fast paced, and thus will review badly and become 'not fun' and thus will not sell. It's directly connected to sales metrics, which is why management in game companies give space for it, and why CDPR recently offered refunds for a game because of bad perf on the PS4 tier of consoles, which is fairly unprecedented. You'll notice worse performance in slower paced games typically, such as Civ 6.
Also I've worked on trying to improve swift build perf and have worked on large C++ codebases before. The reason why C++ is slow to compile typically is because templates cause an explosion in code generation, everyone uses boost & the stdlib smart pointers & containers, which all template heavily and result in slow build perf and large binary sizes. Swift & rust do that, often implicitly and in an invisible to the programmer way and type inference are the typical reasons why it is slow and they too, create large binaries. When I started running into swift's build problems, I internally said to myself "oh boy, it's C++ again" and if you go to WWDC and talk to Xcode's engineers or swift compiler engineers, they often call swift 'new c++' and other not as nice names. Swift and rust are also incredibly complicated languages with a lot of edge cases when you start getting into the weeds, on par with C++.
Why are these languages using features such as type inference, stricter and more complicated type systems along with heavy templating? It's because now computers are fast enough to provide these 'developer ergonomics' and 'multithreaded memory safety without locks' that these features become viable in the compilers of today vs. the compilers of yesterday. If they could deliver such abilities in the past without having a compiler that takes too long, they would have. In the past C++ was known as a slow compiling language, like swift is today. You also notice slow build times in other 'statically sophisticated' languages such as scala or haskell.
Golang was specifically designed as a language to provide fast compile times. When they were designing the language, if they had to decide between cool language feature and fast build time, they chose fast build time.
Try to expand your horizons, just because you like something, it doesn't mean most people like it. I wish most people liked performance improvement work.
Fair enough; thanks for taking the time to chat about this. I'm not sure I agree, but I appreciate your perspective and experience.
For all that you've said, I still strongly suspect that a standalone rust / swift compiler designed for speed above all else could achieve many times the performance of the current LLVM based designs. The resulting binaries might need to lean heavily on dynamic dispatch over monomorphization to achieve that - but during development thats a tradeoff I'd take just about every time. The common factor in swift and rust is llvm - both using it for codegen and having the compiler think about the program in terms of llvm constructs. The fastest compilers I know about - V8, LuaJIT, Go, Jai(?) are designed with both performance and the target language in mind, and (I assume) don't translate the code through a series of complex intermediate representations internally. And you're right - none of those languages do complex template specialization.
Also its probably no coincidence that maybe except for V8 all of those compilers were designed by a single expert mind, not a huge team spanning multiple companies. As you point out, large scale refactoring (required for top tier performance) gets increasingly difficult as team & code size increases. The reasons are partially political ("your commit conflicts with how much??"), and partially because it gets super difficult for any one mind to conceive of the whole program at once when it has so much code and so many authors. Let alone do large scale refactoring.
I don't know if its true but I heard the chrome team started with just a dozen or so very senior engineers who all had experience with webkit. Before they brought anyone else onto the team, they spent months iterating together on the internal design of the browser engine until they were happy with it. They did it that way because they figured it would be basically impossible to change the core down the road once they had a larger team hacking on it.
> Why are these languages using features such as type inference, stricter and more complicated type systems along with heavy templating? It's because now ... these features become viable in the compilers of today vs. the compilers of yesterday.
Maybe. I think we also just got better at designing languages. Rust's trait system seems both simpler and better than C++'s classes + templates. Traits would have been just as viable in a compiler decades ago, but OO was trendy and we didn't know any better.
> just because you like something, it doesn't mean most people like it
Oh, I know! I've spent enough time working on teams building websites to know I'm not the average bear. But I don't think its because performance work is fundamentally uninteresting. I think its because most engineers working on websites don't have enough raw CS skill to comfortably step into the performance arena.
AFAIK swift and rust were actually initially design and made by one engineer for a couple of years before anyone else worked on it, and were led for years by those specific engineers. Chris Lattner for swift and Graydon Hoare for rust.
Interesting to know! But even if those guys made super fast front ends, they would have been always limited by the speed of the llvm optimizer and code generation backend. Writing a compiler on llvm isn’t the same as writing a compiler from scratch.
> Over the coming months, we’ll be working on integrating Workers and Pages into a seamless experience. It’ll work the exact same way Pages does: just write your code, git push, and we’ll deploy it for you. The only difference is, it won’t just be your frontend, it’ll be your backend, too. And just to be clear: this is not just for stateless functions. With Workers KV and Durable Objects, we see a huge opportunity to really enable any web application to be built on this platform
Also:
> With Cloudflare Pages, each commit gets its own unique URL. Preview URLs make it easier to get meaningful code reviews without the overhead of pulling down the branch.
> each feature branch will have its own dedicated consistent alias, allowing you to have a consistent URL for the latest changes.
Agree. I keep calling that Serverless 2.0. 1.0 being basically a fast cache clearing CDN.
Workers is so cool but the starting point is a a bit rough. It looks like they have big plans and will eventually have a full pipeline vs the current Wrangler + scripts situation.
I think it would be extremely useful to have some type of simple authentication system for the preview URLs. I think the One-Time Pin Login [1] available with Cloudflare Access would be a really great fit if I could drive it from a list of email addresses in the GitHub repo.
As a use case, consider a small project where someone is looking for very preliminary feedback and wants to ask friends, family, trusted colleagues, etc. for feedback on non-public previews, but without the burden of a full blown authentication system.
I suppose that depends on whether or not it supports private repos. I don't like the systems that require public repos.
That's awesome! The thing that would make it valuable to me would be to send links to friends or family that have never heard of Cloudflare. If it got tied into Cloudflare Teams or something that added even the tiniest bit of friction it would significantly devalue it IMO. For example, I'd consider OAuth "log in with X platform" to be too much friction. Signing up for an account somewhere would never happen, at least for my use case.
The ideal scenario for me would be if I'm on the phone or video conferencing with someone and can send a link to their email that would grant them instant access with a single click, plus repeat access by doing the one-time-pin flow.
Do you know of any Cloudflare products that would let me build something like that one-time-pin auth flow into a user facing app driven by Workers? Most of the info I can find seems to assume it's going to be used to protect internal resources for companies and the pricing would never work for a user facing app. I might just be missing it though. It took me a while to figure out MS has Azure B2B vs Azure AD which is a similar scenario.
Just rouging it out in my head, I think (I'm probably getting some of it wrong) I could build something like that that's really inexpensive to run using Workers. I'm thinking something like 1 invocation for "unauthorized", a second for the auth request + JWT generation + email link, and a +1 per request cost for a worker to check the JWT / resource request.
IIRC Workers are $0.50/million runs with KV to match, so I could do _a lot_ of authenticating for $5. Compare that to something like Cognito where it's $275 USD for your second 50k users and the one-time-pin style auth running on Workers starts to feel like a good option for low value accounts that don't require a sophisticated auth system with 2FA, etc..
I say that in the context of thinking about a product where people would log in so infrequently they'd probably be doing a password reset anyway. Or they could just be like my parents where every login is a password reset. Lol.
Login and click cancel account and read the language. I’m sure it’s because of some of their intertwined or niche services and not everything but is very real.
You can cancel your credit card, but I imagine big Amazon and Co shops/sells their collections to the best on paper deal debt collectors (aka, truly the scummiest and worst ones).
If you have ever been pursued for unpaid debt like this, despite consumer legal protections, it is years of Hell, legal threats/letters, calls, and other gray intimidation. All while wondering if your credit score will just be nuked over night.
I'm not trying to troll but the reaction to "It's my f*cking data!" should be to seriously look into projects like Urbit. Where you do in fact own and control your own data.
Didn’t read this before commenting but you are exactly right.
There is NO good starting point for developers beyond snippets.
- Vercel as a framework they can modify around their platform
- Netlify is just easy to use and welcoming / friendly / not scary
- Cloudflare has code snippets... I expect this to change overtime as more migrate to Serverless but Cloudflare is like Serverless 2.0 (Durable Objects, runtime APIs) while everyone is building for 1.0 (quick cache clearing and server less functions).
Has been a couple years and still nothing I think.
The link on this post is cool to compete with Netlify and eat up all those small simple static sites but we developers really need a bit more of an ecosystem for app development (framework)
IMO: Cloudflare Workers are far superior but there are basically no frameworks to really leverage the power of all that tech.
If you had a next.js app why on earth would you NOT use Vercel thinking long term.
For Cloudflare, yeah a static site, configure some sort of basic SSR demos, a million Cloudflare code samples, but there’s no REAL starting point for full blown application development beyond going custom.
Coolest I have seen is Flarereact.
Netflify on the hand offers very little beyond insanely easy to use and a ton of developer promotion.
Exactly. Little more clarification here though I think...
Flexibility of Cloudflare KV reads in general still yield quick enough results and make doing a quick and dirty cache a pretty good use case IMHO.
But Worker Sites specifically also use the Cloudflare Worker Cache runtime API — aka, per each POP, first reads of a route (index.html, blah.css, cat.jpg) are from KV and THEN cached indefinitely cutting that time to like 10ms.
This is taken then even further by using ETAG matching to make BrowserTTL indefinite (304s not 200s) on all assets until cleared cutting repeat visitors (regardless of POP) to basically nothing. Though .html for some reason doesn’t respect this (I think...).
You can link to specific lines on GitHub by clicking the line number, then the ellipses, then 'copy permalink' (you can also shift-click to select multiple lines). It also links to the current HEAD commit so the code won't change on you later on.
I HATE Slack. For me, it turns into a gross “pinging you” and overall is insanely annoying to be in channels and check back on information. Or, finding files or using search is Hell. Not to mention their insanely painful login experience. I am looking forward to its death at CRM.
Front is the real deal. Hands down the greatest productivity software I’ve used in YEARS. If you haven’t used it check it out. If you collaborate with a small team it will change your life.
It’s nothing like Slack...
Edit: To clarify some more. Slack and Front are for different mindsets.
Front is best when you are a project/assignment driven person. Slack is best when you are just a drone on a project/channel (if that makes sense...).
Slack also is great when the conversation is heavily one sided. Boss bugging employee. Or, someone who doesn’t know what they are doing has lots of questions for someone who knows what they are doing during a task. Which is fine and has a use.
Thinking about it, CRM should have bought Front instead. Their CRM/people integration is getting incredibly good especially as a support desk suite beyond “email”. The Slack sale is one of the greatest heist I’ve ever seen.
Looking forward to Front eating Outlook and Team’s lunch next
> Slack is best when you are just a drone on a project/channel (if that makes sense...).
> Slack also is great when the conversation is heavily one sided.
Honestly, that seems extremely unfair to me. It feels like you're using it wrong. In my experience, Slack is for conversations. The groups I'm in use it for tossing out random thoughts/questions... and people participate as they choose.
If you're using in a way where people are constantly pinging you demanding your attention, then you should change that. That's no different than being in a large office and everyone else feeling free to just walk over to you and tap you on the shoulder every time they want something. If _that_ was happening, it would be something you should fix, too.
Chat is definitely needed and important but nothing ever gets lost really by “tossing out random questions” in Front.
I would rethink twice how you are communicating in the work place. I find that messy and then forces people to juggle back “oh, yeah what did you Slack me about this the other day”. The most annoying people on Slack don’t realize they are annoying.
Either way to each it’s own. Check out Front and stay open minded to how you communicate in work place
Why as people do we not just add an extra day to the week between Saturday and Sunday?
Who cares about official calendar?
Make all months 4 days longer.
All work weeks still 5 days.
All monthly : 30 day contracts stay the same.
People who need cash or work hard can use the extra day to get ahead.
3 day weekend society - I would vote for it.