Once either of you present an argument worthy of respect within a civil and democratic society, I will respond in kind. Until then, statements like "the glorification of every other sexual special interest except the productive one" will continue to get the responses they deserve.
Of course only a pedophile would even think of having intercourse with a woman who has not yet entered menopause.
I should probably also get the lethal injection for being a product of such a sick and depraved congress, because apparently a child is guilty of the crimes of the father.
What if furthering the human species through the use of stable two-parent households happens to be my kink? You wouldn't kink shame, would you?
It will always be funny to me how little it takes for the mask of limitless tolerance to slip and reveal what you people think of those of us who dare even dream of deviating from the prevailing social norms.
What criticism, calling them "regressive troglodyte opinions" without any substantiation? You're not trying to have an argument, you're just trying to start a flame war.
ok, let me "hn-speak" what's already a clear position that you understand that i hold:
i think your views on women's roles are ridiculous, to the point of deserving hyperbolic comparison. your position is misogynistic, bigoted and repulsive to the ideas of self-determination, social equity, liberty, and nonaggression... summarized perhaps irreverently but not inaccurately by the phrasing "regressive troglodyte."
Why would you assume that someone who specifically mentioned "self-determination, social equity, liberty, and nonaggression" was advocating for "keeping women chained to their desks and away from children" through a lack of parental leave?
Because of the clear regressive biases evident in your comments: not once in your little diatribe nor the tedious back and forths since then have you mentioned general paid time off, bereavement leave, or even paternity leave. I don't want fathers to be chained to their desk and away from their children either, hence my use of "parental leave", but you seem only concerned about mothers being around their children. Isn't that interesting? That coupled with your "the glorification of every other sexual special interest except the productive one", spreading the bigoted lie that non-straight people are unproductive to society and there's little ambiguity on what you think women's role in society is.
The level of knee-jerk reaction to anything Rust into traditionally C projects borders on the pathological. That email is about as polite as it gets without being coddling.
Do keep in mind that a lot of the people involved in these sorts of things are neurodiverse in some ways, and may have significant trouble dealing with change.
As teh64 helpfully pointed out in https://news.ycombinator.com/item?id=45784445 some hours ago, 4ish years ago my position on this was a total 360 and I'd have had the same reaction to now-me's proposal.
All these changes requires work. Because of this, other priorities will get less attention. It would be ironic if bad security flaws are missed/introduced because of all the work switching to Rust. Its also very likely that all the new code written in Rust will be far less mature than the existing source bases. So the outcome might be (very probably actually) a lot of work to worsen security.
Most of the academic research into these sorts of typesafe languages usually returns the null result (if you don't agree, it means you haven't read the research on this topic). That's researcher for it didn't work and you shouldn't be using these techniques. Security is a process, not a silver bullet and 'just switch to Rust' is very silvery bullet.
It's not like I'm in a hurry to switch to Rust and will spend full steam on it. It's amongst the lowest priority items.
A lot of the Rust rewrites suffer a crucial issue: they want a different license than what they are rewriting and hence rewrite from scratch because they can't look at the code.
But here we're saying: Hey we have this crucial code, there may be bugs hidden in it (segfaults in it are a recurring source of joy), and we'll copy that code over from .cc to .rs and whack it as little as possible so it compiles there.
The problem is much more there on the configuration parser for example which does in a sense desparately need a clean rewrite, as it's way too sloppy, and it's making it hard to integrate.
In an optimal world I'd add annotations to my C++ code and have a tool that does the transliteration to Rust at the end; like when the Go compiler got translated from C to Go. It was glorious.
> Unlike other npm clients, Bun does not execute arbitrary lifecycle scripts for installed dependencies, such as `postinstall` and `node-gyp` builds. These scripts represent a potential security risk, as they can execute arbitrary code on your machine.
Hmmm, it still has a pretty extensive default list of permitted npm packages, which wouldn't necessarily be a problem if there were a way to disable it, but I can't seem to find it.
the latter is what i was getting at yeah. updated list of standard library-esque functions implemented in native code so the need to reach to npm for a dependency happens far less often.
Presumably, a reset is resetting to a browser's defaults, whereas a normaliser is about establishing a cross-browser default. I haven't done much web-dev in recent years, but I vividly remember the same page looking different in different browsers, particularly prior to HTML5.
None of that matters. Just set the properties you want the element you are using to what you want it to be. No need to think about any other elements except the ones you use and, when you set a property, it will be the same across all browsers. No need to give it a name or import it into your style sheet.
No thinking involved at all outside of your normal design method. No need to investigate the latest trends or activities by some online guy. Just do what you do.
> Just set the properties you want the element you are using to what you want it to be.
"Just". What I remember from that time was putting a button at relative 0,0 and it being at the top-left of the page in one browser, but was offset in another because that browser was adding padding/margin to <body>. I cannot say which was "correct" but it nonetheless pushed me to use normalisers, which prevented this kind of problem from ever coming up again.
No, a browser's defaults are, well, its defaults. One doesn't reset to them.
I think the line between a normalizer and reset stylesheet is _very_ fine, if there even is a line. A normalizer is probably _slightly_ more opinionated than a reset stylesheet. In the end, the difference isn't really important. If you need a reset stylesheet, normalizer will probably do just as well.
The line is not fine. Resets don't apply any styling, normalizers do. Normalizers keep the overall styling, like the margins of paragraphs and set them to an arbitrary value so all browsers will act the same. A reset is usually just: * { all: unset; }
I really dislike it when a turing-complete language is used for configuration. It almost always breaks every possibility to programmatically process or analyze the config. You can't just JSON.parse the file and check it.
Also I've been in projects where I had to debug the config multiple levels deep, tracking side-effects someone made in some constructor trying to DRY out the code. We already have these issues in the application itself. Lets not also do that in configurations.
> It almost always breaks every possibility to programmatically process or analyze the config. You can't just JSON.parse the file and check it.
Counterpoint: 95% of config-readers are or could be checked in with all the config they ever read.
I have yet to come across a programming language where it is easier to read + parse + type/structure validate a json/whatever file than it is to import a thing. Imports are also /much/ less fragile to e.g. the current working directory. And you get autocomplete! As for checks, you can use unit tests. And types, if you've got them.
I try to frame these guys as "data values" rather than configuration though. People tend to have less funny ideas about making their data 'clean'.
The only time where JSON.parse is actually easier is when you can't use a normal import. This boils down to when users write the data and have practical barriers to checking in to your source code. IME such cases are rare, and most are bad UX.
> Side effects in constructors
Putting such things in configuration files will not save you from people DRYing out the config files indirectly with effectful config processing logic. I recently spent the better part of a month ripping out one such chimera because changing the data model was intractable.
This is what's nice about Pkl, you define a schema as a Pkl file, you define a value of that schema as a Pkl file that imports the schema, `pkl eval my file.pkl` will do the type check and output yaml for visual inspection or programmatic processing, but keeping it to one file per module means that I almost never obsessively D-R-Y my Pkl configs.
Actually that's not the biggest benefit (which is tests for schemas) but it's nice to have the “.ts” file actually log the actual config as JSON and then the app consumes it as JSON, rather than importing the .ts file and all its dependencies and having weird things like “this configuration property expects a lambda.”
I still have to see a JS project where the config for each tool could not be something simple like `.toolrc`. We could have some markers to delineate plugins config.
Instead, there’s a another software in the configuration of sample projects, instead of just using good code organization and sensible conventions.
When Python projects used that approach (setup.py files) that meant to just know what a package's dependencies were, arbitrary code had to be run. Now it's pyproject.toml
pyproject.toml calls into a build backend which is... Python.
It is good to have a simple, declarative entry point to the build system which records declarative elements of the build. The non-declarative elements of the system are configuration-as-code.
i don't. and neither my perl-based softwares.
there should not be the possibility whereas a given parameter can have both string or a numeric value too at the configuration level which the user interfaces with - as of the "real-world analogy" programming paradigm suggests. json and stuff still do have their place but in a lower, machine-to-machine layer.
And for those that haven't taken a look at it, the "customize" menu and everything it supports is silly impressive. And it just writes out the results out, like a boss.*
* Obviously, it has a lot of "don't edit below this line" complexity to it. But that doesn't change that it is right there.
- Turing completeness means that you have to deal with the halting problem, meaning you can't statically ensure that a program ever completes. This is really shit when dealing with config, one buggy while loop or infinite recursive function and stuff just grinds to a halt with no good way of debugging it. Having this problem at the config level might mean that your program never even gets to properly start up, so you never get to setup the logging / otel or whatever you usually use to catch those problems.
- Normal programming languages have side effects and are therefor insecure! They can usually read and write files anywhere, open sockets, send traffic over the internet, etc. These are all properties you don't want of a config language! Especially if you can import code from other modules, a single import statement in a "config file" is now a huge security risk! This is why "npm" keeps having security nightmares again and again and again.
So what you want from a config language is not the same thing as from a programming language, you want as much power as you can get without "Turing completeness" and without any "side effects". That's the reason we have stuff like HCL and whatever the article used as an example.
Can't speak for everyone, but I think a substantial part of the shift from Maven to Gradle was the ability to write build scripts: you didn't need to write a plugin. I'm hoping that Maven (and Gradle) can take advantage of JEPs 458 and 512 to allow people to write build scripts for that Java projects in Java.
Ant had the ability to write build scripts. It's part of what made Ant such a terrible build tool and IMO it's what makes Gradle such a terrible build tool.
Maven's requirement that you write plugins meant that you had to have a decent understanding of the conventions that Maven brought to the table before you could inflict some monster on the world.
In Gradle you can do something quick to get your idea working how ever terrible it is and however much it defies convention or breaks the expectations of anyone coming to the project later on.
While I'm unsure about the efficacy of LLMs, I do yearn for language tooling that lets you 'Bring Your Own Syntax'. I'm someone who prefers TypeScript, Java, and Zig's syntax and genuinely, genuinely struggles with Go, Crystal, Kotlin's syntax. Whoever came up with := versus = needs to stub their toe at least once a day for the rest of time. But if I could write code for Go using a different syntax, I'd write way more Go code. I feel like that's what petlangs like Borgo (https://github.com/borgo-lang/borgo) and AGL (https://github.com/alaingilbert/agl) are doing: making Go less goey.
