HN user

jbiason

78 karma
Posts5
Comments15
View on HN

Honestly, I have been thinking about the same topic for some time, and I do realize that direct files could be faster.

In my (hypothetical, 'cause I never actually sat down and wrote that) case, I wanted the personal transactions in a month, and I realized I could just keep one single file per month, and read the whole thing at once (also 'cause the application would display the whole month at once).

Filesystems can be considered a key-value (or key-document) database. The funny thing about the example used in the link is that one could simply create a structure like `user/[id]/info.json` and directly access the user ID instead of running some file to find them -- again, just 'cause the examples used, search by name would be a pain, and one point where databases would handle things better.

Brazil have something like that: Up to 4 children, you get about 1/4 of the minimum pay from the government for each. There are some caveats, though: The children must be in school, they can't fail a year, children which reach adult age (18) do not count/get paid for anymore, and the family monthly salary can't exceed about 75% of the minimum pay[1] to be eligible.

While this somewhat help lower paid families, we still have a huge number of men that just leave their families once kids appears and leave a single mother to raise the kids -- which have their own issues.

[1] I may be a bit off in the values, but you get the idea.

That's one way to think about numbers and not about the persons.

I believe most of countries have orphanages already -- and what you're suggesting already exists in some countries (I do believe we still have that in Brazil).

While that could increase the number of people, orphanages are not great places to raise a child (with rare exceptions). Imagine you growing up with a large group of other child, and nobody actually take the time to take care of you. What kind of person would you be today?

(Just to be sorta pedantic) I don't think it's the version 1.x that promotes backward compatibility, but editions.

In 2016, you could call your function `fn async(...) { ... }` without any issues, and you can still compile this code with the modern version of rustc. If you want to use the async features of Rust, you need to change your edition to at least 2018, which brings breaking changes in the language.

And you can have a project that mixes those editions, and cargo will correctly use the edition asked for each crate.

(So, I guess the ideal world would to first look at the package management in Python, and *then* try to introduce breaking changes. And I'm withholding how much I'm angry at the PSF for postponing having a decent package manager for 20 years and investing in removing the GIL and adding JIT.)

... and merge without Mark's review. :D

Imagine you wake up one day, and see that you get a bunch of code review requests 'cause the old maintainer simply said "This guy is the owner of this now".

(I'm pretty sure Mark is fine with this, and Guido already explained the situation to him, but kinda funny, nonetheless.)

The "Renamed To" was bothering me (like some other posters mentioned), and then it hit me why:

Forks of large projects happen when something bad is going with the source (why fork something huge when things are going ok?), and marks the source as poisoned.

Renamed means... It just changed name, everything is already, nothing to see here...

Sure there is the mindshare on the name but people in IT for long knows what means when a fork of this size means.

not all code can be easily updated to conform to safety rules (e.g., it’s old and not understood, it belongs to a third party that won’t allow updates, it belongs to a shared project that won’t take upstream changes and can’t easily be forked).

I have to say, this sentence annoys the heck out of me.

Old code that can't be understood needs to be rewritten anyway. And since you're rewriting, you can apply the safety rules -- which would be better anyway.

If the code belongs to a third party and they don't want to update, it means the third party is playing against you -- or, worse, that they control how you're going to move forward. It's in your best interest, in this case, to rewrite the third party dependency as soon as possible, and since you're rewriting, you can apply the safety rules -- which would be better anyway.

If the code is shared and the upstream does not accept patches and -- worse -- doesn't support forks, then you have an issue with the upstream anyway and -- guess what -- you'd be better rewriting it anyway.

All those issues are managerial issues, not software issues. Management decided that it is better to be stuck than moving forward. And they can happen with any languages, not just C++.

Adding these things as "we can't be totally safe" are like "I can't jog every afternoon 'cause bears/alligators/wild life may jump an attack me". It's pure excuse to NOT do things.

Sunsetting Atom 4 years ago

The Vim plugin in VSCode is the thing that drives me out of VSCode, to be honest.

I have to say that I built so much muscle memory in those years that it is kinda hard to realized I'm not using Vim, and there is always something not-quite-like-vim in VSCode-vim that usually gets in my way.

(To be honest, the only editor that I found that is really close to Vim without being a Vim-thing was GNOME Builder.)

Bleh 4 years ago

Dunno if he still have his Mastodon account, but after seeing continuous posts calling GNOME devs "complete idiots" and constantly bashing Rust for their decisions, I stopped following him completely.

You're seeing the posts in his blogs. His timeline was full of bashing devs of other open source projects. Never a constructive criticism, just plain bashing (with occasional self-congratulatory comment for his own decision).

PS: I think part of his Rust criticism was towards the attempt to make Sway use wlroots-rs and it not fitting his idea. So, instead of saying "Sorry, it didn't work", he jumped into full bashing Rust for not doing what he was trying to do.