I think that programmers are quick to jump to concurrency when they want to make something performant as opposed to using other structures, like a cache, or researching other possible solutions, like the HN favorite bloom filter, or other algorithm.
We also have a mantra against optimization until you know that you need to. It seems too cost and time prohibitive to put these things on the programmer to maintain, and that we need to develop tools to help optimize our code. Maybe the next generation of optimization techniques will be runtime instead of compile time. We already have dbs with optimizers, so maybe there will be programming languages with optimizers?
I would say reddit is a forum, and you can have good discourse on there, but can also have straight comfort internet trash. Basically I think its more nuanced than just having a forum...
Not sure why you are sticking to your guns here. First, it's highly unlikely anyone would ever write wasm by hand. Second, the article rambles a bit but the most compelling argument for assembly is writing fast code for constrained hardware. At a high level, that's not what wasm is solving.
This is a compelling article, but then when you try to see what the product is, you have to submit your email / request a demo. In my experience, hiding your product behind a demo is a bad sign that the product has flaws. It also puts you in contact with a salesman or account manager which is typically geared towards a high pressure sale event of the product. I'd be interested to hear other people's experiences with this model, though.
Not sure why HN is saying it is obvious that assembly is relevant because compilers... The article's intent is around a programmer writing assembly. I'm sure there are niches but I can see web developers getting away without writing assembly in their professional career.
I think one contributing factor slowing down progress is the cost of electricity in Italy. It's €0.24/kwh vs $0.06/kwh in the US (at least in PA). You dont see any electric cars in Italy, and it seems super expensive to them. I’m also not sure if there is a tax on top of that €0.24 from what I remember my cousin telling me. I’m hitting a language barrier confirming this.
I think the real problem is that they didn't properly maintain their code. Rewriting it in Go won't prevent them from dealing with this in a few years for when this Go version reaches end of life. I would have liked to see an article on "introducing process" side of programming.
I think the part that is hard to grasp is that React essentially has it's own runtime tangled with JS. With the introduction of hooks, there are non JS things going on, which is why React relies on the quirk of having the same order and number of hooks in your component. It also has Suspense which allows you to exit from the render function and return to that spot, which is definitely not a feature of JS. So yea, it's weird. I think the interesting question is trying to figure out what this means for the next version of React. I would like to see if it takes a page or two out of Svelte's book.
I have been on similar kicks for drawing similarities between the two, but it never pans out to anything useful. I.e how does this move the science forward?
I can play devil's advocate (aka classic hacker news' commenter) and say what about inhibiting neurons? Tonic neurons? What about the ability for the brain to do recall after hearing a name once? Procedural memory? Does the relationship you point out help you understand any of these things?
JIRA is meant to break up work. Atlassian has another product called confluence to let you write prose, like the author wants, and you can link all these things together. When you have a group of 3 people on your team, you need to coordinate different parts of the feature into separate tasks for each developer so that they can work in parallel. This guy/girl hasn't discovered anything we don't already know.