arendjr

I was aware that indeed the trait and lifetime bounds were an artifact of the Tokio work-stealing behavior, but Evan makes a very well-explained case for why we might want to consider stepping away from such behavior as a default in Rust. If anything, it makes me thankful the Rust team is taking a slow-and-steady approach to the whole async thing instead of just making Tokio part of the standard library as some have wished for. Hopefully this gets the consideration it deserves and we all end up with a more ergonomic solution in the end.

Of course, I’m a user too, but I don’t think Linux’s UX is that bad. It may be bad in some areas, but it’s not bad across the board.

I also don’t think Linux is only for developers. It’s great for developers, but it’s also great for people with only basic needs of their computer, those that don’t need much more than a browser, an email client and maybe an office suite. The UX is totally adequate for them, as evidenced by ChromeOS.

I think where Linux lacks is mainly for the users in between, those who are not full developers or tinkerers, but do want to mess around and do so from a perspective of expectations of how things worked in the Windows world. And I won’t deny there’s a plethora of legitimate enterprise use cases for which there is no equivalent in Linux today. But those are not UX issues, those are mainly matters market support. Linux is not great there, maybe it never will be. Or if it does, it’ll take a long time.

First example that came to mind was actually Mac users who struggle with external monitors/projectors and things like screen sharing too. I agree they’re things that are so basic they should just work. Reality is often different even on other OSes.

Of course if you have a Windows home and everything works and then you try Linux and it struggles with a piece of equipment, it’s easy to blame Linux. You wouldn’t even be wrong. But you are oblivious to someone else’s experience who uses Linux exclusively and everything works for them, how many of those things wouldn’t work or work well with Windows.

Personally I’m a developer, so I care a lot about integrating parts of my development stack. A lot of those things don’t “just work” on Windows, or even Mac, so I’m happy to stick with Linux instead.

I agree with your examples and it’s certainly true there are plenty of rough edges on Linux. Then again, how many examples are there for things that should “just work” and do on Linux but don’t on Windows? There’s enough that make me not use Windows at all, because it has a subpar user experience. I even used a Macbook for a few years, mainly for work, and there were too many small things that annoyed me about it, so it too had a subpar user experience.

Seems it’s mostly a matter of perspective which issues are more important to you.

0° being “very cold” and 100° being “very hot” is intuitive.

As someone who’s not used to Fahrenheit I can tell you there’s nothing intuitive about it. How cold is “very cold” exactly? How hot is “very hot” exactly? Without clear references all the numbers in between are meaningless, which is exactly how I perceive any number in Fahrenfeit. Intuitive means that without knowing I should have an intuitive perception, but really there’s nothing to go on. I guess from your description 50°F should mean it’s comfortable? Does that mean I can go out in shorts and a t-shirt? It all seems guesswork.

You make a good point in that Docker promised to make dev environments reproducible so that everyone on the team would have the same environment. They even succeeded in that, but either intentionally or accidentally omitted reproducibility over time due to the introduction of non-locked dependencies.

Actually, I stand corrected. I just looked into insertion sort again, and you're right, it was insertion sort I initially came up with. The funny thing is, I was later taught "bubble sort" in an Informatics class in high school... but in reality that was insertion sort too!

So it seems I was taught under the wrong name and never realized, I wonder how many others are in the same boat 😅

~~Yes :)~~

Edit: Sorry, this wasn't true, see other comment!

Dunno what to say except that I started programming as an early teenager without formal education, so I “invented” bubble sort before I ever heard of other sorting mechanisms.

I agree it shouldn’t be used in real-life, but to me it’s pretty intuitive and at least I’ve disproven that “nobody” comes up with this by themselves :)

As someone who doesn’t like AI-based auto-complete but will happily use AI occasionally to ask questions every now and then, it looks like these guys might be on to something.

I’m not using Zed yet, but this is giving me some incentive to try it out.

As a junior with no clue how to write production code, is Clean Code going to provide with a decent framework I can quickly learn to start learning my craft, should I throw it out completely because parts are bad, or should I read both Clean Code and all its criticism before I write a single line?

I see what you’re getting at it, and I agree we shouldn’t increase the load for juniors upfront. But I think the point is mainly there are better resources for juniors to start with than Clean Code. So yeah, the best option is to throw it out completely and let juniors start elsewhere instead, otherwise they are starting with many bad parts they don’t yet realize are bad. That too would increase cognitive load because they would need to unlearn those lessons again.

Also in Europe, but I’ve worked at 3 different startups before becoming a contractor earlier this year.

• First one I worked for 5,5 years, joined at ~30 people and saw things grow to 180 people at which point the company was sold and I left about a year after that.
• Second one I worked for 7 years, was one of the first employees and responsible for building their frontend stack as well as various microservices from the ground up. Company grew to about 80 people, but I left after Covid layoffs. I wasn’t one of the layoffs, but culture went to shit quickly after that.
• Third I was also one of the first people and helped build a pretty exciting architecture from scratch. Stayed for 3,5 years, but unfortunately the company never found market fit during that time and the team never grew beyond ~20 people.

Overall I can say:

• If you value autonomy and you have a getting-things-done mentality this is the right gig for you.
• Culture differs very much per workplace, you may need to be lucky. (I don’t think that’s unique to startups though.)
• You need to be assertive and pro-active.
• Don’t do it for the money. Startups usually pay less, but in theory make up for it by offering equity. But most startups fail, so in most cases this will never be more than theory. Even if you do get an exit, chances are the payout is less than you would’ve earned working those years for a bigger corporation.
• The experience can be extremely rewarding because you can easily reach a position of influence.
• You will learn a lot.
• The experience can be frustrating because there is always pressure and a lot to do and you rarely have the means to do it all.
• You will need to improvise a lot.
• If you pull it off and your startup becomes successful the thrill is exhilarating.