bendmorris

False equivalence, because there is zero rational basis to believe the election was stolen. People who are motivated to convince others of this are lying to them. Some are literally inventing "evidence" like registered voter counts that have been shown to be inaccurate, or arguing that states violated their own laws, when the state supreme court, the final adjudicator, rules otherwise.

Frankly, it doesn't matter "who is right in their own point of view." We have to be able to stipulate to a basic set of facts that are supported by objective evidence. You can't just make shit up and expect everyone else to cater to it.

Do you really think there's an amount of "due process" that will convince all Trump supporters to get behind Biden? Trump has clearly been planning to call the election illegitimate since long before it happened - casting doubt on mail-in ballots, etc. He hypocritically advocated continuing counts in some states and stopping them in others depending on whether he was ahead. He claimed without evidence that dead people had voted, late cast ballots had been counted, etc. And he falsely claimed that only votes counted by election night were legitimate.

Do you honestly think once his claims relating to poll observers go through due process, everyone will be satisfied?

Pragmatically, there is such a slim chance that any of his challenges change the outcome of the election, that it's reasonable to consider Biden President-elect at this point.

At best, we're assigning a ton of credit to him based on a vague "probably." Lots of non-Trump factors influenced the stock market over the last four years.

>Forecasts give us probability distributions based on historical polling error data.

They would give you a probability distribution if they were truly random samples. But in reality, response rates are very low, and pollsters make up for this using demographic weighting and modeling - so the results don't actually represent any real population, but rather are extrapolated from people who respond onto a hypothetical population that the pollster thinks is likely to vote. This is why they are spectacularly and systematically off, more and more over time. It's not just variance.

>lets just ban driving?

Or maybe let's infringe on your freedoms by: requiring a license to drive, requiring use of a seatbelt, setting safety standards for car manufacturers...

Presidents seem to get a lot of, sometimes undeserved, credit for the economy when they were President. Besides inherit a strong and growing economy, what specifically did Trump do to deserve credit for the stock market growth under him? And conversely, does he deserve partial or full credit for the impact of covid-19 (and his slow response to it) on the economy at the end of his term?

The Supreme Court has held that this applies to criminal law - you can't change the punishment of a crime or change rules of evidence to convict someone who was acquitted.

You can certainly pass laws to undo a merger or (equivalently) break up a company.

https://en.wikipedia.org/wiki/Calder_v._Bull

For your desktop browser you want JIT, but it's absolutely not required for all applications. For example, some platforms don't allow JIT due to security concerns, so any JS on those platforms has to be interpreted. There are also JS runtimes like JerryScript intended to run in low resource environments where JIT wouldn't be feasible.

Honestly, what is the holdup on releasing the source? Other languages are developed entirely out in the open - what are you worried about? Why not just release it today in whatever state it's in, as was previously promised?

Without releasing it you're expecting people to put blind faith in you.

>Because Volt must have been written in V (please let me know if a counterevidence exists)

The source of V or any substantial V project haven't been released, and the author making inaccurate claims about the compiler (and taking donations on Patreon, by the way.) Why should we accept without skepticism that (closed source app) was written with (closed source language)?

Shameless plug: Kit (https://www.kitlang.org), a statically typed language with no runtime, can interface with C without bindings (by directly including C headers.) Kit includes features such as traits, term rewriting, algebraic data types and procedural macros, which make it more expressive than C without all the boilerplate.

Zig (https://ziglang.org) and Lobster (https://github.com/aardappel/lobster) are also pretty interesting!

It doesn't. It requires building political will in the group that's been left out to override them.

The problem is housing being treated as an investment, resulting in artificially high prices and limited supply for the people who need to live in it.

We should buy housing to live in, not to extract rent from the suckers that were too late. A land value tax would help lower prices and remove the incentive to treat housing as an income source.

We're trying to limit gift giving from any one source to both a dollar and item limit. It's been a struggle and some family members complain about staying within the limits we've requested (ironically, gift giving seems to be more about them than the recipient.) One thing we're trying now is suggesting that gifts to kids be replaced with donations to a 529, and so far this seems to be working OK. There's still some concern that kids won't care about this kind of gift at this age, but we do make an effort to explain who gave what and what it means, and I think that's worth more than yet another toy they might touch once in a few months.

What is "zero-cost" garbage collection?

>It took me a long time to figure out what .njk files were.

Nunjucks is a very popular JS templating language (more or less a straight port of the even more popular jinja2) - it's not an odd choice at all.

https://github.com/mozilla/nunjucks

#2 is more likely than #3 because a reasonable person gives access to another contributor or someone they spent a few minutes vetting, not a total stranger with no GitHub history.

>The latter solution isn't much better

It is unquestionably better than your users, whose trust you've earned over time, suddenly finding that their app is mining cryptocurrency.

>He didn't give anybody the power to do things in his name.

His name is still on the project he gave away access to, so yes, he did.

>Your vitriol would be much better aimed at...

I think criticism is warranted here, but I don't think I've been especially vitriolic about it. Frankly, OP made a poor choice and is now making excuses by complaining about not being rewarded for maintaining the project rather than own up to it. There was a better way to do this without him having to perpetually maintain the project.

And moreover, the herd of commenters here on HN are projecting their dissatisfaction with entitled open source users onto anyone who criticizes OP.

People keep casually making this suggestion. In JS this can involve hundreds or thousands of transient dependencies. Have you ever (1) worked on a React app and (2) vetted all of React's 829 dependencies yourself? It's not remotely feasible. The only solution becomes "then don't use React!" - is this the best we can do?

>If semantic versioning always behaved as it should be

The exploit in question specifically relied on this expectation, by creating a new patch release for the exploit. Even if you could trust well-intentioned maintainers to use it correctly, there's always this risk.

I agree, but you have to start from a known working state at some point - and at that point you are extending trust to that specific set of versions. Anyone who ran `framework create-project` for a framework that included event-stream as a dependency will have downloaded the exploit and then pinned it without knowing.

Stack (https://docs.haskellstack.org/en/stable/README/) for Haskell solves this problem by maintaining sets of curated version numbers that are known to work together.

>He had no way of knowing the person who took it over would use it maliciously.

Then it was, clearly, negligent of him to give it to this person. He gave a stranger the power to do things in his name.

He doesn't have to maintain the project forever - it seems like a much easier solution is: don't give away a project with your name on it to someone you don't know. Instead, encourage them to fork and release a new version under their own name. This is a surefire way to never have an exploit spread to thousands of people with your name on it.

>Ultimately, you can't take dependencies for granted.

The problem is that JS dependencies are so modular that shifting the burden to vet your dependencies to developers is generally not realistic. Creating a new project with one of the current popular frameowrks will bring in hundreds or thousands of dependencies. Who can possibly vet that?

To compound things, this package could be a transient dependency of a transient dependency, so I may not even know the person who decided to depend on it in the first place, or the reason why, or what the package does.

It's not that people are taking dependencies for granted - it's that there is no reasonable alternative.

> if they invent new something ... they probably have a good reason to

https://en.wikipedia.org/wiki/Not_invented_here

Even if there were no reason at all, the bias toward writing things ourselves ensures that we'd continue to see these new frameworks.

Thanks for the response Nicolas. I'm not reading any ill intent into this. I do think that it's time for the Haxe Foundation to make time to be more transparent, or it will continue to stunt your growth as community members get frustrated and leave. As you know, criticism like this isn't new, and it isn't going to go away.

If you don't feel design decisions can be made effectively by a committee and prefer to steer these decisions yourself, that's understandable - just remove the language about the core team voting on proposals or reaching consensus, because in practice it's not how the process actually works.

>the onus should be on the proposer

I'll bite: what should @Lerc have done differently in his proposal (https://github.com/HaxeFoundation/haxe-evolution/pull/51)?

To quote you again:

>perhaps your feature request wasn’t deemed to be thought out enough?

Why jump to finding fault with the OP, rather than accepting feedback about the process? AFAICT you didn't actually check OP's proposal before assuming it was lacking. And OP's experience isn't unique.

You're evangelizing Haxe in this thread, but here you just paper over valid criticism:

- "arrow functions are slated for the next major release": sure, it only took four years!

- "I also think most languages’ directions are decided by committee in a similar way": I'm not aware of any other language that has a proposal process inviting community participation, but doesn't follow it and discusses those proposals in private. Point me to one. Surely you can understand that this can be frustrating when someone tries to participate and is shut out.

- "I’m sure the Haxe community would love to see examples..."

I would be pleasantly surprised if I saw the Haxe Foundation engage in some introspection and actually take steps to change or at least be more transparent. So far I don't see any introspection, only defensiveness.

And FWIW, I used to be part of that internal Slack channel for team members and was a Haxe contributor. I tried to make progress on these issues for years before giving up.

>perhaps your feature request wasn’t deemed to be thought out enough?

Why the automatic defense of the Haxe team? Frankly, small communities like this sometimes come across as cult-like in their response to criticism, and it isn't a good look.

Here's the proposal in question: https://github.com/HaxeFoundation/haxe-evolution/pull/51

Here's the process which wasn't followed: https://github.com/HaxeFoundation/haxe-evolution. Very little discussion, no public vote, even though the proposer put in the effort and clearly wanted to engage.

When someone puts in the effort to make a proposal like this, this bait and switch is not a way to keep them around, and insulting them in HN comments isn't any better.

Similar experience here. I've proposed a few changes to the language and none have been accepted. Rejecting convenience features with no downside like concise object literals is unfortunate. It literally took over four years to finally get arrow functions into Haxe, which had overwhelming community support.

Change proposals are subjective, so people can have different opinions on whether a change should be accepted or whether it was well-formulated enough. What bugs me though is that the Haxe team has a documented process for considering and voting on these proposals, which they don't follow. If Nicolas doesn't like a feature, it's essentially vetoed. If he changes his mind later, it'll be implemented without any further discussion. Most discussion happens in an internal Slack channel so there's no transparency. It's essentially a BDFL masquerading as a democracy, and it can be frustrating to try to contribute as an outsider if you don't realize that. See inline XML for example (https://github.com/HaxeFoundation/haxe-evolution/pull/26) - a lot of discussion, open questions remaining, seemed like Nicolas was generally resistant. Then suddenly, there's a PR and it's merged, and it will be in the next version of Haxe.

IMO, this is not the way to run an open source project. And in my experience, the team is resistant to feedback and takes things personally, so I've lost confidence that it will change.

https://www.kitlang.org made the front page recently; I was asleep and didn't notice until I woke up with a bunch of notifications and emails. Content that appealed to people, not gaming, got it there.