It's very clearly a toy example to demonstrate the idea, and it does so well.
> What we have here is a Rube Goldberg machine, not a cleanly solved engineering problem.
And what _we_ have here is unfounded indignation over a perfectly fine way to solve a problem. People have been using linked libraries to re-use code across languages since forever, it's fine. This solution isn't very different, it just makes shipping easier.
As a parting comment, "sound software architecture" is not a decided upon principle which can be empirically determined, and if it was we'd all be out of a job.
> And what _we_ have here is unfounded indignation over a perfectly fine way to solve a problem
Absolutely no way is this a fine way to solve the problem. That is crazy talk.
1. It introduces additional toolchains into the solution when it is unnecessary.
2. It now means you need multiple language specialists to maintain it and associated communications and context switching.
3. More interfaces and integration means more fragility when it comes to debugging, problem solving as well as increasing the problem surface.
4. It massively increases the dependency stack which means there are now multiple sets of supply chain issues and patching required.
This makes no problems easier at all! It's even a bad last resort if that's all you have left to try.
Sound software architecture is very very well defined and this is definitely not it. I have seen entire companies burn by taking this approach to problem solving.
I'm really getting tired of solutions before problems and this is a fundamental example of it. Give us a real use case not manufacture a problem for it.
> 2. It now means you need multiple language specialists to maintain it and associated communications and context switching.
Sometimes you have that and you need to accept it. In this case the function was really trivial. What if it was a mega secret algorithm that needs Rust speed which you want to really write in Rust because XYZ? Or C++ I don't care. But not Go, which you want to use exclusively for microservices, for example.
> 3. More interfaces and integration means more fragility when it comes to debugging, problem solving as well as increasing the problem surface.
This is inevitable when you want to go that low level. Some companies use C++ for everything, some mix low/high level: how do you do in that case?
This article is about Go, but I could imagine something similar for Python: use something superfast under the hood, python for the high level part. It's really a common solution, which requires a bit of bindings left and right but it's worth it.
> 4. It massively increases the dependency stack which means there are now multiple sets of supply chain issues and patching required.
This is how software is done today. Maybe 30 years ago you would write everything in C and be happy with it. Today companies use at least 3 programming languages - at least that's my experience.
> This article is about Go, but I could imagine something similar for Python: use something superfast under the hood, python for the high level part. It's really a common solution, which requires a bit of bindings left and right but it's worth it.
That's not a bad idea really, the wasm/wasi option could be a nice intermediate step between "we can't optimize the python any further" and "write a native extension" (or god forbid use cffi or the cursed horror that is ctypes).
> Absolutely no way is this a fine way to solve the problem. That is crazy talk.
I disagree. I see this in a similar way I see Electron and actually you can make the same arguments against using Electron.
But guess what, Electron wins on practicality. It makes creating GUI apps much easier. That wins over any problems associated with the extra baggage of shipping a whole browser. It doesn't win it for everyone, but it does for the majority of people who just want to get shit done.
> People have been using linked libraries to re-use code across languages since forever, it's a fine way to solve problems.
People have been doing it forever, but people have also hated it forever. Twenty years ago you saw SWIG in a build, you'd know you were probably in for a bad time in an exciting new way.
I think SWIG had a different purpose. The author here generates and embeds WebAssembly in Go, to avoid building the same lib for multiple platforms (+ the bindings to call the low level c code). Maybe the tool wasn't good enough? Right now this is just WebAssembly which is proven to work on multiple platforms.
If the API is clear and documented, I don't see why this would be an issue, except for the fact it might be a little bit clunky.
It's not the first solution I would come up with, but the question would be: why not? Just because we're used to older and more traditional patterns, why not just to embed webassembly for low level stuff in your code?
War is a symptom of various causes, like over-population, changing geographical conditions, and just plain old greed. It is not a root cause. If humans had no bloodthirst we would still wage war, so long as we had a will to survive (something which would be difficult to take out of a lifeform).
The actual article only asserts that military innovation is a predictor for social complexity, which is pretty different from saying that "war makes society complex".
> “Nobody likes this ugly idea because obviously warfare is a horrible thing, and we don’t like to think it can have any positive effects.”
The implicit assumption being that a more complex society _is_ a good thing, which is not clear to me.
It may not be universally clear but to most people it clearly is a good thing to be in a more complex society. im definitely happy to not be sitting in a hut in a jungle with no other option.
It's possible to cooperate to survive, it seems much harder (more complex!), but I don't agree that it's impossible. Much easier, I'm sure.
We'd need to forgo some autonomy to achieve it IMO, for example: we'd need to get a handle on population rises; we'd need to limit resource usage using some mechanism other than financial affordability; and lots else.
They did this in a few places in caphill during covid, 16th and 11th being big examples. The cars have since been allowed back on those roads, though. Someone went tearing down 11th in their jeep at easily 50mph the other day, made me really really miss those days.
- A lot of practice, which stemmed from a lot of fooling around and abandoned side-projects. I would deliberately start projects which were way over my head, with no intention of even getting something working, just to see how far I could get before getting bored.
- Learning new languages which had vastly different paradigms than the ones I was used to. Java to Perl to Javascript to PHP to Erlang to Clojure to Go to... Over time you learn patterns from one place you can bring to another, and learn patterns which exist in most places which you'd rather didn't.
- Lots of experience in the actual workforce, building things people (supposedly) wanted. There are aspects of programming which people spin their wheels on which really don't matter in the long run, and conversely there are aspects which go ignored but are very important. Working on real, rubber-to-the-road projects gives you perspective on what actually matters.
- Being a daily archlinux user (I don't use any non-archlinux OS on any machine I own). Yes, it's hard. Yes, it's an incredibly good use of your time to figure out. Once you're comfortable in arch, every other Unix-like OS (ie, most of them that you'll ever probably work with) will feel familiar.
I don't think that's what web3 is, that's just one direction some are taking it. Web3 is a move away from centralized platforms to ones which are either decentralized or more directly controlled by users (self-hosted, federated).
> Like anything blockchain there is no real solution for how to handle records becoming stale over time without a central authority that manages disputes.
I don't understand this part. In pretty much every decentralized name system I've seen a user pays to own a name for a period of time, there's no stale records.
> Any former meaning is now drowned out by that definition, whether you like it or not.
Random pronouncements on HN don't make it true. If you want to restrict your understanding of the term, by all means do so. But don't expect others to follow suit.
You might be right. But just like crypto bros co-opted the term, it could very well be co-opted again by whatever tech seems like the next big thing after "everything is blockchain" fades into obscurity
I used to use this obscure little piece of software for that called Apache. Maybe y'all have heard of it. Though I think it's getting some competition from this unknown little project called nginx. Really looking forward to that stuff becoming mainstream, it'll be revolutionary.
Link doesn't load, so with only the title to go on...
It feels like it's implying that sincere is the opposite of cynical? But someone (me) could be sincerely cynical. Or falsely optimistic.
In any case, signaling sincerity sounds a bit like fighting for peace, and doesn't give me high hopes for this article whenever we do get to find out what it says.
(It _is_ sort of fun to have this playground though, where we can all just freely admit we didn't read the article, and riff off the title alone)
I don't think they intend sincerity to be the opposite of cynicism. I think the idea is that people, being cynical, will assume that you are insincere. Presumably, TFA tells you how to avoid that.
So if you are sincerely cynical, how would people tell you that they are being sincere (when your assumption is that they are not)?
If anyone had ever perused around the steem network (pre-Justin Sun takeover), you'd know what twitter would become if posting/liking/retweeting ever got monetized. It was a strange place. It might still be, but it seems to mostly be chinese posters now so I can't judge.
On the flip side, monetizing social interactions is a great way to suck the vitality and soul out of them, which would fastly reduce twitter's impact on the real world. So if you don't like twitter this isn't the worst proposal.
There's no perfect solution, but you can make it painful. One solution I've seen, which only works in a server-side rendered site, is for the server to generate a random name for each form field being rendered. The mapping of random id to real field name is kept in the user's session information server-side, so the translation is then done server-side as well whenever the user performs an action.
At that point anyone writing a library like this would need to actually pull in the rendered page on which the user is supposed to be navigated, scrape the field names off of that (which won't be easy), and only _then_ could they perform the form action.
But if you're a big enough site, someone will likely still take the time to do it.
In putting together my own RSS feed recently, and trying to figure out the best way to sync it with all my devices, I realized the simplest way was to just turn the aggregated links into a webpage and publish that publicly. There's no reason not to, and now others can use it as well!
It's at https://news.cryptic.io, if anyone wants to see the output. I recommend others do the same if you like.
The difficult part of using RSS is the actual curation part, so it's cool to see a trend (2 datapoints is a trend?) of folks doing that work up front and sharing it with others.
> "hike" (just long walk since I live in flat Houston)
I've been calling it "urban hiking" and everyone thinks I'm joking. But why drive all the way to the wilderness to do a hike, when I can just walk out the door?
I love this. I will now call it "urban hiking," as well. It was still more fitting when I lived in NYC to call it hiking since there is at least hills and grass and trees.
> What we have here is a Rube Goldberg machine, not a cleanly solved engineering problem.
And what _we_ have here is unfounded indignation over a perfectly fine way to solve a problem. People have been using linked libraries to re-use code across languages since forever, it's fine. This solution isn't very different, it just makes shipping easier.
As a parting comment, "sound software architecture" is not a decided upon principle which can be empirically determined, and if it was we'd all be out of a job.