Live data from Hacker News

Things that used to be hard and are now easy

jvns.ca

141–150 of 316 posts

Re: Things that used to be hard and are now easy

#141
post #19

Would be interested in also seeing a "things that used to be easy but are now hard list". Feels like basic stuff is harder now: * Privacy online * Google search for niche or exact matches * Browsing without captchas and blockers, especially if you don't adhere to big tech's rules for the internet * Sending emails without worrying about spam filters being way too aggressive * SEO before it got hacked to hell * Barrier…

> * Privacy online Privacy is a lost cause, the younger generations don't care. I remember when people were warned about sharing their real information online. over 50% of people I knew were just nicknames on the internet. I had zero clue about their gender, where they lived or what they did for a living. Didn't affect our conversations the least bit. Now everyone is plastering their faces everywhere they go. Every p…

Really? On almost all Discord servers I've visited, everyone has a nickname and doesn't share photos of themselves.

On Instagram, I've also noticed a lot of young people who share e.g. art have a completely anonymous profile (and I guess probably another, non-anonymous profile for their friends only).

Not sure about Snapchat or TikTok, though.

Re: Things that used to be hard and are now easy

#142
post #70

It's very hard to accept the statement that writing fast programs is now simpler with Go/Rust. I think that what happened is more like this: * With Go is now possible to write reasonably fast (not as fast as C) programs in a simpler way. That's great indeed, but is not exactly the above statement. * With Rust it is possible to write programs that have a speed that is comparable to the one of C programs, that are memo…

I think you're point is correct around rust in that writing rust is harder than writing C due to the constraints the compiler places on what you can do. So far I'm happy with this tradeoff because I've had some very gnarly C concurrency bugs that took weeks to understand and debug. If the rustc compiler can point out that I'm doing something stupid and save me two weeks for a bit of pain immediately I'm all about it.

Re: Things that used to be hard and are now easy

#143
post #83
post #31

Eh... I'd argue against quite a lot of those being "easier" than doing things manually. Docker is a prime example. It's supposedly easier to spin up a docker container for a basic web server stack, but to be honest I'd rather install PHP/MySQL and an SSL certificate manually, rather than spend time finding a decent container from a trustworthy source, and then spend 20 minutes trying to figure out how and why it's be…

I highly disagree here. Within seconds I can have all the technology I want running in a Docker container with little to no setup. Just make a docker-compose.yml file with the services I want, say Postgres and Redis, mount my local folder to a Golang Docker image, and then I just do `docker compose up` and all three are running and communicating with each other with little to no effort.

I don't think these points address the original post's points. Specifically they highlighted the issues of _finding_ images to run and having the _knowledge_ on how to use these tools in the first place for abstraction.

Re: Things that used to be hard and are now easy

#144
post #54

Earlier quoted context omitted.

Logging into an online account on a computer you don't normally use when you don't have your phone. This can range from "had to jump through a bunch of extra hoops" to impossible if you haven't saved backup codes ahead of time (Google). My wife lost her phone when we were on vacation and it was literally impossible for us to login into her Google account in order to use find my Android. We were trying to login on a r…

I can't really see this as the negative you imply it to be. This seems like complaining that you might get locked out of your house if you lose your keys. There are certainly better and worse forms of 2FA, but I would like more pervasive (well-implemented) account security, not less.

A better analogy would be the locksmith refusing to let you in because you can’t produce the deed, which itself is in the house.

Re: Things that used to be hard and are now easy

#145

Personally, I disagree that parsing was hard before and made easy with PEG parsing. For decades it has been easy and common to implement parsers by hand. From what I can tell, universities and textbooks just overcomplicated the process by teaching parser generators. I have done a few studies of various open source ecosystems now and (edited: other than CPython) I haven't seen PEG parsers really used in anything but t…

IMHO the barrier of entry really came down because with PEG-styled parser libs they put you back in the comfortable "declarative land" where you specify what you want using roughly the same mental model as RegEx without having to worry too much about quirks caused by implementation (i.e. leaky abstraction).

Re: Things that used to be hard and are now easy

#146

The general theme of this list is that technology gives us more and more hoops to jump through, then provides some trampoline to jump through them. We're supposed to be eternally grateful. I'm not. I want to focus on problem-solving, not masterfully using trampolines. > SSL certificates, with Let’s Encrypt Semi-mandatory SSL certificates weren't a thing on the web until fairly recently. Not managing them at all was c…

I've been on teams that haven't used docker for dev envs and teams that do in the last 5~ years. The teams that used docker were significantly more productive since each dev env was a replica and forced the team to maintain a common env. The dev env drift without it is huge and causes so many "it works on my machine". I can see a one man show or maybe two not needing a docker dev env but any sizable team IMO it is ab…

Oddly, my experience is a mixed bag here. Teams I've been on that went for rigid standardization with docker have largely been much harder to upgrade than those that allow local dev however the dev wants.

This is subtle. There are more bumps along the way. However, the task of upgrading isn't neglected forever. Instead, it usually seems that each new member winds up upgrading some small piece and making sure the code works with a small change in environment.

Re: Things that used to be hard and are now easy

#147

The general theme of this list is that technology gives us more and more hoops to jump through, then provides some trampoline to jump through them. We're supposed to be eternally grateful. I'm not. I want to focus on problem-solving, not masterfully using trampolines. > SSL certificates, with Let’s Encrypt Semi-mandatory SSL certificates weren't a thing on the web until fairly recently. Not managing them at all was c…

Out of curiosity what were the

> [...] gotchas of .NET Core async/await APIs drove me away.

I kind of lost track of the framework to core changes but I think it became simpler with the removal of synchronization contexts?

Re: Things that used to be hard and are now easy

#148
post #70

It's very hard to accept the statement that writing fast programs is now simpler with Go/Rust. I think that what happened is more like this: * With Go is now possible to write reasonably fast (not as fast as C) programs in a simpler way. That's great indeed, but is not exactly the above statement. * With Rust it is possible to write programs that have a speed that is comparable to the one of C programs, that are memo…

> writing a fast program in C is often simpler compared to writing a fast program in Rust

I think it really depends on what you need to do. If you need a HashMap or a BTree, getting your hands on high-performance implementations of those structures in Rust is much easier than in C. Also "sprinkling some threads" on existing serial code can be much easier in Rust, using a library like Rayon. But I take your point that designing new data structures and doing unsafe things with pointers can be more complicated.

> Overall Rust made programming harder

This is certainly a matter of opinion, but I like to argue that writing large, correct systems software was always this hard. Rust frontloads a lot of the difficulty, forcing you to handle every error condition, lifetime mismatch, and potential data race before it will even consent to run your tests. When you're first learning Rust, or when you're writing toy code where safety doesn't matter to you, this can feel like an unnecessary burden. But I think we've learned from experience that writing large systems software without this discipline leads to an endless stream of memory corruption and concurrency bugs.

Re: Things that used to be hard and are now easy

#149

The general theme of this list is that technology gives us more and more hoops to jump through, then provides some trampoline to jump through them. We're supposed to be eternally grateful. I'm not. I want to focus on problem-solving, not masterfully using trampolines. > SSL certificates, with Let’s Encrypt Semi-mandatory SSL certificates weren't a thing on the web until fairly recently. Not managing them at all was c…

> But we're talking about what became easier, right? Not about what became more ideologically correct, semantic, etc. Then think of it this way: it became easier to make the content/UI both good looking and fully accessible (e.g. to screen reader users, for whom layout tables are indeed a hindrance). I think the same applies to the other hoops to jump through; they're solving a real problem, just perhaps one that doe…

Sorta. Screen readers, being external programs, really had no trouble dealing with tables. The tag wasn't semantic, sure; but the intent and reasoning wasn't exactly difficult.

I suspect that the giant explosion in primitives for a screen reader to deal with had actually made the job harder.

And this is ignoring the explosion in nested divs that most modern sites have.

Re: Things that used to be hard and are now easy

#150

The general theme of this list is that technology gives us more and more hoops to jump through, then provides some trampoline to jump through them. We're supposed to be eternally grateful. I'm not. I want to focus on problem-solving, not masterfully using trampolines. > SSL certificates, with Let’s Encrypt Semi-mandatory SSL certificates weren't a thing on the web until fairly recently. Not managing them at all was c…

Async/await is not for parallelism.
Post reply on HN