News for hackers. Stuff that matters.

mellab2

Re:Qwen has alter egos triggered by flipping a single neuron on Wednesday October 28, 2026 @04:55PM (#50280775)
That sounds a bit like saying planes can’t fly because they don’t flap their wings like birds do
Re:The Agent SDK on Wednesday October 28, 2026 @04:48PM (#50280682)
Can confirm it draws from my subscription
You say you agree with Bill Gates but your view is completely at odds with his, he is extremely concerned about existential risks … and your view is “stop focusing on it” ?
Re:Show HN: Giving Opus 5.5 a simulated paint canvas on Saturday October 03, 2026 @09:46AM (#49944230)
Why is this I wonder though? Does it mean they were able to exploit/manipulate the grader in training? I.e they had access to the grader’s program?
Re:What Happened to the Real Time Strategy Genre? on Friday September 13, 2019 @08:17PM (#20967982)
You might want to check out Railway Empire, it’s considered a spiritual successor.
Re:Virtual DOM is pure overhead (2018) on Thursday May 23, 2019 @08:56AM (#19991242)
>> the main reason why no ones does this is because you would be missing the most useful aspect of React which is compatibility and consistency with the rest of the React ecosystem. So you cannot separate React from its ecosystem. All this complexity has become tightly intertwined.

This is just plain wrong. Firstly using JSX or not will have 0 impact on compatibility with other libraries in the ecosystem because they are not coded against JSX they are coded against what JSX is compiled down to. The main reason people use JSX is because people like it.

Also you say the complexity has become intertwined but I don't hear any examples of how that is the case?

Re:Terraform 0.12 on Thursday May 23, 2019 @08:46AM (#19991154)
Terraform is an amazing piece of technology but the biggest thing holding it back is HCL. I guess the intention was for it to serve as a happy middle ground between a full blown programming language and a configuration language - enabling some abstractions, but yet rigid enough to stop developers getting too carried away. I think unfortunately that trying to have it both ways doesn't really work and ends up leaving those writing the code frustrated - it's almost as if it's teasing you - you can feel there's all this power under the hood and you are given things like modules which are nice, but you always feel like you're on a of short leash.

I switched from Terraform to Pulumi for a personal project recently and haven't looked back (no affiliation). Writing it with Typescript means you get excellent IDE support (using VSCode here) and access to the enormous JS ecosystem. I've also found myself creating a number of useful abstractions - that I would never have bothered to with HCL - like IAM helper functions, eg:

    const limitedReadAccessPolicy = createPolicy(
      "product-table-read-access",
      allow(
        ["dynamodb:Get*", "dynamodb:Query"],
        [table.arn, interpolate`${table.arn}/index/*`]
      )
    );

vs

    resource "aws_iam_policy" "product_read_access" {
      name        = "madu_${var.env_name}_product_read"

      policy = <<EOF
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Action": [
            "dynamodb:Get*",
            "dynamodb:Query"
          ],
          "Effect": "Allow",
          "Resource": [
            "${aws_dynamodb_table.products.arn}",
            "${aws_dynamodb_table.products.arn}/index/*"
          ]
        }
      ]
    }
    EOF
    }
Re:Terraform 0.12 on Thursday May 23, 2019 @08:25AM (#19991002)
I've been using Pulumi for a few weeks now and it works pretty much exactly as advertised (for AWS at least). I am yet to run into any major hurdles and for any minor issues I have had the Pulumi team have been very responsive (they have a public Slack channel available).

It actually uses terraform's API's under the hood which is comforting in a way because you know it's building on a solid foundation.

I would not go back to writing HCL after experiencing Pulumi if I can avoid it, using a "real" programming language just feels a whole lot more natural and allows for much more powerful abstractions.

Re:Virtual DOM is pure overhead (2018) on Sunday May 19, 2019 @04:08AM (#19952125)
Sorry but what complexity are you talking about? React (particularly in the early days) has always had a comparatively small API surface.

You have components with a render method, and in that render method you return other components which you can pass data to via "props" - that's basically react in a nutshell.

I've noticed React is often conflated with the wider ecosystem it is a part of (Webpack, Redux, Babel) - perhaps this is the complexity you are referring to, but to be clear React can be used without any of these things.

And sure React being developed by Facebook couldn't have hurt in terms of it gaining popularity - but the real reason it took off is that in contrast to what you said it removed a huge amount of complexity by alleviating the burden of developers having to manipulate the DOM directly in ad hoc ways. Instead of having to manually add classes, add elements, remove elements, append children, you could just say given this piece of state, give me this.

> Anything that comes out of Facebook is just pure manipulation.

This just shows that your issue lies with facebook the company, which is biasing you against react - the technology.