alskdjflaskjdhf

This kind of response is rude and unhelpful. This is how they are finding it out. Just googling "X vs Y" invariably gives you worthless SEO spam these days. A forum like HN, where you can hear about the experiences of other people in the field, is a great way of getting more useful information.

Render's free DB tier isn't really usable when the data gets nuked after 90 days. Really strange decision IMO.

It's also emphasized in the onboarding materials which is probably more impactful than an internal policy page.

Not to shame the author--I'm glad when people share the stories--but the thing that surprised me is that the author knew the "hang up and call the number on your card" advice but didn't seem to understand why it's common advice. The whole point is precisely that caller ID is completely unreliable. If caller ID were secure and authenticated the caller, there'd be no need to hang up.

Since a good bit before 2014, even. They used to recruit very heavily from MIT (while Palantir was overrepresented at Stanford and Quora at Harvard--all of these reflecting the almae matres of the founders). Note that this was before the popularity of Leetcode and the whole cottage industry around trying to game algorithmic-type interviews. I'm not sure if similar companies founded today would push these algorithm-heavy interviews as hard, since they've probably lost some signal now & prevailing attitudes have changed a bit.

At any rate, it doesn't surprise me at all that Dropbox engineers do better than FANG engineers on these technical metrics. The average Dropbox engineer is almost certainly a bit smarter and a bit better at algorithms than the average FANG engineer. Of course those attributes don't automatically translate into being a better engineer, though, nor do they automatically translate into company success or anything.

Yes, this is scam prevention 101. Anyone who called you is always unverified. It's hard for me to take seriously a "scam prevention expert" who doesn't seem to know or follow this rule, which by itself is enough to protect you from most scams. Normally I try not to victim blame people for getting scammed, but when you've made a declaration like that you forfeit that right.

I'll also point out that the author seems to have some complicated arrangement for their phone number(s), presumably in the name of security, that in fact got in the way of identifying this to be a scam.

This honestly looks perfectly reasonable to me. It's obviously far harder than the SAT math section (which isn't saying much since SAT math is a bit of a joke), but the questions look completely fair and not at all like they're trying to trick or screw the student.

Makes the comment upthread that started this come across as just more racist prejudices about China, unless the commenter has something to back up their claim.

I already said why in my first comment:

> Why would you want to do this? Well, what about layout? And what if you have a component that wraps or otherwise behaves like an HTML element?

Yes, it's nothing something you'd want to do willy-nilly or all the time, but there are perfectly valid use cases. This issue has been one of the single most-commented in the Svelte repos with tons of back and forth and a lot of demand so this isn't just an obscure complaint either.

As for how to resolve it, there are plenty of clean ways to do it. Svelte's style scoping is done via a unique class per component. It suffices to simply provide some way to pass this class from a parent to a child, for example, and let the child component decide what to do with it. There are many possible variations on this theme. The obstacle to resolving this problem isn't technical infeasibility, it's that to date the maintainers just haven't cared.

On the other hand, I find Svelte's handling of this half-baked, as there's no way to pass scoped classes to a component, only to a HTML element. [1] In fact, I find this so frustrating that I have actually given up on Svelte's CSS scoping entirely and I use Tailwind instead, which also solves the same problem by almost [2] completely disregarding the cascade altogether.

[1] Why would you want to do this? Well, what about layout? And what if you have a component that wraps or otherwise behaves like an HTML element?

[2] Of course Tailwind supports modifiers, which do cascade, but everything is still local to a single element.

This is a classic illustration of the Central Limit Theorem--in fact, the example is even on the Wikipedia page [0]. The distribution tends towards a normal distribution as n increases (though to actually take the limit you need to rescale).

[0] https://en.wikipedia.org/wiki/Central_limit_theorem#Applicat...

It's not just "authoritarian governments" but rather "governments" in general, unless you consider the EU government to be authoritarian. And circumventing the law has always been the prime use case for crypto since the beginning. I think everyone has always agreed that it's great for that.

Inertia [1] is an interesting project in this space that might solve some of your problems. I haven't used it, but I believe the general goal is to make it easy to "plug in" client-side frameworks (React, Vue, Svelte) into server-side views.

[1] https://inertiajs.com/

Probably the equivalent would be a custom store, something like this:

  <script>
    import { writable } from "svelte/store";
  
    function autoCounter(interval, initialValue = 0) {
      let { subscribe, update } = writable(initialValue);
      setInterval(() => update((n) => n + 1), interval);
      return { subscribe }
    }
  
    let counter = autoCounter(1000);
  </script>
  
  <div>The count is: {$counter}</div>

>Having used Solidjs for some pet projects, I've come to strongly prefer Solidjs over React. It's an evolution of react, so I've found my existing skills/knowledge transfers. This being said, Solidjs is brand new and the ecosystem is minuscule compared to React. For this reason, I plan to continue using React for the foreseeable future. One of the biggest weaknesses of Solidjs is the lack of a "nextjs" like framework. It appears work is being done in the solid-start[1] repo, but it looks like it's still years away from being fleshed out. I want Solidjs to succeed, but I'm not interested in being an early adopter.

The chicken-and-egg ecosystem problem for new frameworks is tough. I've been working on Svelte stuff lately which has a similar problem but less extreme--the ecosystem is still much worse than React's, unsurprisingly, but it's also much better than Solid's right now.

I think Solid's primary branding is around performance and Svelte's primary branding is around it being easy. For getting things off the ground, I think "easy" is a much more successful approach.

>In React, we render lists by using regular JavaScript idioms like loops, arrays, and array methods like map. However in Solid.js, much like traditional templating languages, we get a construct like <For> that reinvents a concept that's already in the language.

I find this a totally bizarre complaint. I've spent the past few months working on Svelte stuff and I've seen people on HN make this same complaint about Svelte's templating language with {#if} and {#each}. Who cares? What is so wrong, exactly, with "reinventing a concept that's already in the language"? It does not make code any harder to understand or to write, and it does not harm performance (in this case, quite the opposite).

I would much rather have a reactivity model where I plug in completely standard concepts and patterns (a for loop) than one where I have to deal with a bunch of framework-specific, complicated ones (hooks). That Solid's reactivity primitives are familiar is an advantage, not a disadvantage.

>One more factor in Wordle's popularity that I haven't yet seen commentators identify much. The game's word roster tilts heavily toward words with neutral or cheerful connotations.

>So your brain conjures up something happy at the end. You don't slog through the puzzle solving to end up with VIRUS, ENNUI, GRIEF, SLAVE, INANE or other such morose words.

Ironically, SLAVE was actually one of the future solution words in Wordle pre-acquisition. The NYT removed it from the planned solutions.

https://www.theverge.com/2022/2/15/22934587/wordle-solutions...

Yep, these are used extensively at Google (which is where the abseil library came from, and which is famously anti-cpp-exceptions) and they work very well. If I somehow found myself writing a new C++ project I'd probably reach for abseil (and some of the other parts of the Google toolchain: GoogleTest for testing, bazel for builds).