nytopop

> How is it difficult to get someone to install something for a test run when like 90% of app installs are test runs?

The link you shared does not provide any statistics about the amount of installs relative to didn't-installs. It only deals with the set of people who have already installed, which says nothing to prove or disprove the point in contention (that increasing the set of people who have installed at all is difficult).

> So you're saying it's difficult to get someone to install your app at all

Yes [they are].

> and that has nothing to do with your product or your marketing, but it has something to do with the technology?

Based only on what they wrote, not necessarily. They only seem to be saying that the statistics you provided do not support your conclusion:

>> you're going to be hard pressed to get people to install your app just to try it out

> In fact, the statistics prove[1] that this is false. Most app installs are to try it out, and promptly delete it. Most users will delete your app shortly after installing it.

You can apply a filter in htop before running your binary, it'll only show matching processes.

I think the hotkey is F4.

It is - The Library of Babel.

That's an artifact of it being statically typed. The data type to unmarshal into / marshal from needs to be defined somewhere. The extra stuff apart from error handling isn't required if you use a more generic type like `map[string]interface{}`.

Check out the hindley milner type system [1]. It's used by haskell and some other languages, and allows for a very extensive amount of type inference. You can often write large sections of code with no type annotations and the compiler can figure out the most general type based on the type of some function called somewhere, which means the thing you did with that result must be of a certain class of types, which makes the surrounding expressions' types have to be a certain class of types, etc etc.

[1] https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_sy...

To be fair, only 125,367 lines of that is actual c.

With documentation documentation.

That doesn't seem right. Why wouldn't intelligence help predict the unexpected? The point of their argument is that higher intelligence may make it easier to expect what somebody with a lower intelligence would not expect.

People don't think in strictly logical terms, there's a whole mess of abstract pattern matching and built up experiential anticipations embedded in the process.

That pun might require some iota of shared knowledge, but it doesn't require much intelligence to get. Amount of knowledge doesn't define intelligence - someone who scores low on an IQ test will get that joke just as much as someone who scores highly (not that I'm equating IQ score with intelligence).

I don't think that a lack of shared knowledge is what they are getting at. Complexity of a joke has more to do with lots of disparate moving pieces, so to speak. The ability to quickly perceive those pieces - and what is unexpected within them - isn't shared by everyone.

Well no, vaping is more addictive because inhalation as an ROA is more addictive. This is a well studied effect.

You can purchase mass produced stuff but the quality of vape you get is much better with DIY setups, though it puts the onus of safe design parameters on the builder. With electronically regulated devices this risk goes down a great deal, older gen (though still in wide use) devices called mechanical mods would basically short circuit a lithium battery to a coil of wire - if the resistance is too low you pull way too much power for the battery and catastrophic heating occurs.

Location: Bothell, WA

Remote: Yes, preferred

Willing to relocate: No

Technologies: Python, Go, HTML, limited experience writing C. MongoDB, Gin web framework, NuPIC, Docker. Networking and OS knowledge.

Github: https://github.com/nytopop

Resume/CV: https://registry.jsonresume.org/nytopop

Email: [email protected]