luord

Have a good night!

Some company just expecting free work comes closer to the definition of "entitlement", in my opinion.

> Who wouldn't want to do this? Sure, it's stressful and it takes time, but it's also fun. You get to talk about yourself! That's everyone's favorite subject.

I wouldn't, so there's that. And, mind you, I don't even consider myself particularly introverted, so I highly doubt that I'm the single exception to what you said. So what I'm trying to say is that one can't assume that one's sensibilities are shared by everyone else.

> someone who just walked in off the street.

Not only had the author already been through a process, the fact that there was a recruiter involved makes it seem to me that the company (or the recruiter) contacted him, not viceversa. So it doesn't seem like he "just walked off the street".

You seem to be arguing as if the company wasting the author's time was a hypothetical. No, they veritably, absolutely, wasted his time.

The respectful thing to do, IMO, is not to ask people to perform this type of free work, specially if the likelihood of the preparation going to waste is this high.

Thankfully, no company so far has asked me to do something like this, because I would just refuse.

It's the epitome of applying the KISS principle for building interactive web applications, not in small part because it allows the developer to keep the UI code in a single place, backend templates, instead of spreading it around[2]. In my particular experience, I've found that htmx pairs really well with my backend microframework of choice, flask.

In fact, using htmx means that there isn't a division between backend and frontend as much as there's a backend with some extra attributes in some of the tags in the templates, and a few extra rules deciding which template to serve at specific endpoints.

[1]: https://htmx.org/

[2]: Having spent most of my professional life deep within js/ts frameworks, I thought that progressive enhancement was either a pipe dream or required duplicating at least a significant portion of the UI code on both ends. Htmx showed to me that such ain't necessarily the case; `hx-boost` in particular is a godsend.

Coincidentally, just two days ago I too went through my RSS subscriptions and, fortunately, most of them were still online, but sadly quite a few hadn't been updated in years, so it's likely that this will happen to them. Safe to say, I agree wholeheartedly with the author.

I found this one interesting because I practice inbox zero so I delete 99.9% of the emails I get.

Regardless, I do have some I keep just in case, so I should back those up.

I mean, not that I'm really surprised by this happening with Google[2], but still I didn't expect them to get involved; don't see what they have to gain by this other than sharing on the bad publicity. Wonder if Apple will step in too.

Hopefully these events will actually lead into more adoption of decentralized protocols and platforms (and more support for open hardware development, maybe), and I'm starting to wonder if this week will go into the history books.

[1]: I mean to say that I know that many in the tech sector were already aware of it. But everyone at large was just kind of okay with it, so this is revelatory from that perspective. Well, hopefully it is.

[2]: In fact, this was probably caused by the surge in activity triggering one of their (in)famously intransigent algorithms, which never seem to stop increasing in number.

No, it's not. This is far from the only objection/disagreement I have with the article, but I can take almost everything else as either opinions or convenient examples in support of those opinions.

That sentence, though, just stuck with me as particularly odd because, among other things, using classes doesn't make you more likely to use global variables than using functions exclusively. And I'm not even talking about Python in specific.

Anyhow, it had been a while, I think, since a post pitting FP against OOP had reached the front page, and thus causing yet another iteration of that traditional flamewar in the comments. Guess it was due.

I've been thinking about this kind of setup for my and my family's data, at least.

Reading this stuff makes me glad that nobody I care about still uses Facebook for anything more than sharing the odd picture. Soon I'll be able to delete it entirely, and hopefully decentralized social networks will indeed become popular.

Now if only we had some sort of open website aggregator on top of which people could build search engines. Sort of like an analogous for what OpenStreetMap is for geographic data. Maybe it already exists—I'm a bit ashamed to say that I haven't actively looked for it nor have I heard of such a thing—but whether it does or not, it'd be a huge step in the right direction. I think that any progress toward a decentralized web is a bit weakened if search results continue to be provided at the whim of only a few actors. But I'm digressing at this point.

I'm not sure that differential dataflow is that simple as I haven't checked the paper nor the repository—according to other replies, it isn't—but if it were, that's all the more reason to use a library/tool instead of reimplementing something for the thousandth time, I think.

Gonna check to see if he has a template or boilerplate that he uses for new projects.

Well, I'll keep using it, dragging it along kicking and screaming... until it's deprecated or improved, I guess.

Agreed.

"2) We would have never got a free open source tool that helped kick-start many other companies."

Disagreed. A different open source tool would have gotten the attention and that would have helped kickstart many other companies. Pretty much every open source tool or library has equally open source alternatives, sometimes even just as popular alternatives.

Elasticsearch is no exception, and its alternatives are about to get a surge in popularity.

"You could say the same about Mongo. Imagine what impact it would have had on the startup world if Mongo wasn't a FOSS project."

More startups would have used Postgres instead... Which probably they should have done anyway. Mongo only started to become usable for anything but raw streams of data, IMO, not long before it became source available. And even nowadays, I would still recommend Postgres (or any relational database) over Mongo for 95% of startups, even if it still were open source.

That said, I know that that is not the case with Elasticsearch, which probably is the best among its alternatives.

Now, it's very likely that many of them will stop contributing for versions 7.11 and up.

By the way, I am not a lawyer and I might have misinterpreted the article, but I feel like the AGPL could have accomplished what they wanted to do. Maybe it's not restrictive enough for their needs, but I'm not sure why.

Un muy feliz año a todos!

Feliz Navidad!

I was also agreeing with GP's saying that "static typing won't save us". There are many things to say about Go's type system, but it is definitely more static than Python's, which I've also worked with.

It was shared here a while ago (https://news.ycombinator.com/item?id=22531453), if you also want to read the HN discussion about it.

So, I'm adding this as another reason to keep avoiding co-location as much as possible.

[1]: And, well, online meetings discussing what to code and how to do it; they're often pointless, particularly the daily ones, but bearable.

There are even studies on this and, so far, there's no strong correlation between type system (or paradigm, for that matter) and number of bugs in a codebase.

In fact, one recent study on the matter ended up turning into a flamewar between two different groups of scientists, the ones who first published the study and the ones trying to replicate and double check the data... As discussions on type systems and paradigms are won't to do. Evidently not even academia is safe.

I wish there actually were empirical evidence to support one's preference in that area, if only to get rid of those flamewars that have been going on for decades. Alas, until that happens, what language one prefers mostly remains opinion or personal experience.

I would still like to improve any application I might create depending on how it's being used (to know what features to improve, which ones could potentially be removed or changed, etcetera). Keeping logs of this kind of usage would still go against the GDPR? I thought that it wouldn't as long as it was aggregated data without using any of the users' personal information. But some comments here have led me to believe that it would go against the GDPR regardless because it would still mean separating unique users.

Hoping someone more familiar with the law sees this comment. I mean, I can think of multiple ways to aggregate that data, even with unique users, without using personally identifying information, but I'm not sure anymore if that's enough.

This is sane, and how most other open source applications or tools work. Don't see any reason why this one should be different.

So... As long as we're talking about the shell, when will we be able to interact with sourcehut entirely from the command line? Right now I'm particularly looking at managing build secrets.

Being able to use it entirely from the command line is the only thing sourcehut lacks for it to become the best code/project/build management tool. At least for me anyway[1]; I'm aware that sourcehut's idiosyncrasies are not for everyone.

On that note, is anyone aware of any such platform that can be managed entirely from the command line? The one that comes closest is the github CLI, I think, and even that one still requires a browser flow for logging in and getting the token[2].

[1]: I am aware that I could dive into the code and maybe contribute this myself but a) there might be plans for this already; I believe there's an issue where it was discussed and b) I don't have nearly enough time to commit to it.

[2]: I know that this is very nitpicky of me, but I do truly want a tool like this; I think it'd be awesome.

Maybe it's just me, but I don't really care about fewer page reloads or having multiple animations and interactivity. I understand why those can have an impact on end users and so I do think that SPAs have their place, but I'd much rather the interface was rendered from the server and worked through links if it means it'll work faster. In fact, half the time I'm not even using the web interface; I'm using the SDKs.

For number eight: If your reviewer is being a douche, I don't think there's harm in pointing it out, respectfully. Nothing says that both sides can't learn from the review.

As for number nine. I'm not sure if adding comments is going to completely help; I'd rather refactor to make the code as explicit as possible, including the tests[1]. But more importantly, I don't think that sacrificing possibly more idiomatic code for the sake of beginners is a great trade-off. I think it's better to encourage people to get more familiar with the language and technology being used.

[1]: Which is usually my first stop for when I might not understand something in the code itself.