What steps do you think you'll be taking to never have to deal with this again?
116 karma · joined April 10, 2020
Could you, please, explain how?
[0]: https://raw.githubusercontent.com/romefrontend/rome/1d583050...
[1]: https://raw.githubusercontent.com/romefrontend/rome/main/ass...
Coming from an imageboard myself, I think about this often. The "serious" users keep comparing themselves to Reddit when they should strive to be more like HN, instead. Now HN is home -- literally; it's my homepage.
Coming from an Islamic country, minorities such as gay people or non-religious people cannot seek legal action without a strong sense of a chilling effect.
In the US, you have the electoral college as an attempt to amplify small state's voices to not have states with massive populations dictate who's president (at least in spirit, as I understand the implementation is far from perfect) which is understandable, since states are _first-class citizens_. The other thing, and correct me if I'm wrong, is that you have the house and the senate. The senate adheres to that first-class citizenship of states, while the house is a direct representation of citizens (blocks of them), which makes a tyranny of a majority (e.g. one-size-fits-all bill that suits people of California but wouldn't go well with the people of Wyoming) impossible.
So, if you don't feel like there is a tyranny of a majority in the US, you perhaps have to thank your legislative process for that. That sadly, does not map to private entities.
> He who knows only his own side of the case, knows little of that. His reasons may be good, and no one may have been able to refute them. But if he is equally unable to refute the reasons on the opposite side; if he does not so much as know what they are, he has no ground for preferring either opinion. The rational position for him would be suspension of judgment, and unless he contents himself with that, he is either led by authority, or adopts, like the generality of the world, the side to which he feels most inclination. Nor is it enough that he should hear the arguments of adversaries from his own teachers, presented as they state them, and accompanied by what they offer as refutations. That is not the way to do justice to the arguments, or bring them into real contact with his own mind. He must be able to hear them from persons who actually believe them; who defend them in earnest, and do their very utmost for them. He must know them in their most plausible and persuasive form; he must feel the whole force of the difficulty which the true view of the subject has to encounter and dispose of; else he will never really possess himself of the portion of truth which meets and removes that difficulty.
[0]: https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS...
> Most people don't have the context to understand this narrow technical document - it is only applicable to a very particular, very technical situation in the internals of Deno. This is not at all a reflection on the usefulness of TypeScript in general. It's not a discussion about any publicly visible interface in Deno. Deno, of course, will support TypeScript forever. A website or server written in TypeScript is a very very different type of program than Deno - maybe much more so than novice programmers can appreciate - little of Deno is written in TypeScript. The target audience is the 5 to 10 people who work on this particular internal system. Please don't draw any broader conclusions.
I think that's the whole point. It's not the right tool for their specific goal.
In their design doc[0], they agree that Rust glue code should not be written in TS: compiled code "full of weird namespaces."
From the design doc discussion[0]:
ry: manually managing the d.ts files has been great - it's very much part of the public interface - we need to have 100% control over it we do not want random compiler-generated __namespace0123 in there This is the same situation - but for the bundle It's not good that we do not have visibility nor control over what code is in there. for example, the TS compiler worker, has 15k lines of code in its bundle - EXCLUDING typescript.js TS compiler worker is about 500 line thing that interfaces between ops and TSC this is caused by our attempt to "self host" the internal code self hosting is cute - but if it's effecting performance and the ability to make improvements - it's an unnecessary feature https://gist.github.com/ry/a6d4b1466158d82750a6447342fd3af4 ^--- here is what we ship for the compiler worker we call this code every time deno runs
lucacasonato: Ok, wow. I hadn't seen this. That changes things...
ry: does the compiler worker really need to generate a UUID? https://gist.github.com/ry/a6d4b1466158d82750a6447342fd3af4#... (no) yes, this is fixable within the current system .. but the point is that we're abstracting away the important parts V8 does not run typescript. It runs JS. We need to have a good handle on the JS we ship If we don't try to self-host, we don't need a sourcemap for the internal code. There's 1mb off the executable right there. The point is the internal typescript comes at a cost - and that cost is too high.
lucacasonato: So the actual issue is the bundling and opaqueness that that brings with it. It makes sense to stick to pure JS in that case. Its annoying that type checking is gone, but youre right. This is not the kind of code that should be in the runtime.
ry: not like the code isn't full of "!" anyway. TS is great, but it gives a false sense of security.
[0]: https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS...