Live data from Hacker News

Things that used to be hard and are now easy

jvns.ca

151–160 of 316 posts

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

#151
post #66

Earlier quoted context omitted.

They are both so much more pleasant to work with than C.

Golang was created from the same people of C, it's what C++ should have been. It takes lots of background from plan9, the 'Unix++' OS.

> it's what C++ should have been

No. There's a large class of programs that you can't write in Go that you can write in C++.

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

#153

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…

I've worked on Rails, Node, and Clojure teams where Docker was optional and was always glad I avoided it. There has never been something important in my dev environment[1] that couldn't be responsibly managed by rbenv and bundler (or their equivalents for other languages).

[1] The one exception is SQL DBs and redis, but I have always been fine using brew, linuxbrew, or apt for them.

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

#154

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…

Yeah I may be the only one, but I still think async/await was a huge missed opportunity to get rid of promises like I proposed here for javascript:

https://es.discourse.group/t/callback-based-simplified-async...

It seems quite inneficient to me to wrap every function call in a caching layer and state machine that pretty much goes unused in the context of async/await and makes things unecessarily hard to undertand for new programmers.

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

#155
There's another facet I've watched with interest:

>> Building videogames, with Roblox / Unity

This has resulted in something like 90 new games entering Steam every day. While some games may still be art, they're increasingly difficult to find among the noise. I've heard the mobile game market is in worse shape[1] by the deluge of games. "More games for everyone!" sounds great - but note that definitely doesn't mean more "good" games - or more "innovative" games all the while encouraging rampant copying/stealing of ideas.

[1] https://www.youtube.com/watch?v=Q30qZSEnI9Q

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

#156
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…

> Overall Rust made programming harder: something that I'll hardly excuse to it.

Rust isn't much harder than any other language once you understand lifetimes. Non lexical lifetimes made it easier than ever. It's a month of dealing with speed bumps as you learn, and then you're good to go.

Rust makes it insanely easy to write multithreaded applications. I write servers on a daily basis with shared in-memory caches, worker thread pools, async jobs, and all kinds of fun and useful things that I wouldn't dare do in any other language.

I'm developing apps in Rust at near Rails speed.

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

#157
post #56

Earlier quoted context omitted.

> The number of times I've been bitten by the very specific semantics around async/await in JavaScript makes me wonder if I've hit some kind of a ceiling in trying to grok it. Got any examples? I've mucked around a fair bit with JS's async and never felt like it got in the way. (Other than the whole function coloring ordeal)

> I've mucked around a fair bit with JS's async and never felt like it got in the way. When functions return more than one Promise , or when one chains async functions calls, it isn't really clear Error s from which functions are likely to break out and result in an unhandled exception (read also: https://archive.is/ULT7P ). For example, does trapAllErrs() below trap 'em all? Not really. Why? The answer involves unde…

Would you do a .catch on the await p to fix that?

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

#158

Earlier quoted context omitted.

Reading the article and I didn't see writing fast Rust programs as easier listed(only Go). The callout was for sharing data between threads which I think is an area where Rust has the edge over other languages.

Because the article was modified. [Note] Another HN user mentioned that the statement was dubious, cited the original statement, got downvoted to hell: https://news.ycombinator.com/item?id=30406644

They got downvoted not because of their disagreement, but because their comment was low quality. "Sure, bud." is a mere quip and doesn't add anything substantial to the discussion.

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

#159
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.

Thats how you get people who have no idea what the underlying tools can do and bloat the high level abstraction.

Complexity has to go somewhere. If something is easier, something else is harder. These things may make the bog standard use case easy but woe to you if you ever try to go another path or change something. Then you need to figure out if the abstraction layer allows you to tweak the underlying software layer, or invent your own way of reaching into that layer which may break when any update comes in a higher layer etc.

Its more learning upfront to get familiar with the basic Linux tools and services, but it is very versatile and flexible and will stay mostly the same for decades.

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

#160

Earlier quoted context omitted.

Agreed. To add to that I would say that publishing a website (if you yourself don't do tracking, advertising, affiliate and all that) is in no way impacted. A simple web site without cookies and not transferring user data elsewhere but the hosting webserver is not impacted at all. At least when hosting with an European host. One needs an imprint and data privacy page. But both is easy (except in specific cases like f…

> One needs an imprint and data privacy page. Really? I have a small personal website with no tracking; I guess my hosting provider collects server logs, but do I really need a privacy page for that? An imprint is something I've only seen on German websites (I recall reading somewhere that those are required by law there).

In Germany every site that collects, stores and/or processes personal data (PD) is required to have a data privacy explanation that is easily reachable from every page and explains to the user what data is being received, stored, processed and also explain the user's rights (for example the right to be informed, to correct data and so on).

At first glance, a "private" page does not directly process personal data and would therefore not require a privacy policy.

So if you don't use contact forms, advertising banners, social media plugins, etc., you should be on the safe side.

What most don't see: The server on which pages are located (hosted) collects personal data in the background in the form of server log files. These log files contain IP addresses, these addresses are personal data.

So yes. Even if the server doesn't log the IP to logfiles as it still receives the IP every site needs a privacy page.

There are good privacy page generators, though. Free of cost.

Post reply on HN