When used in that equation it's meant to implicitly depend on n as edflsafoiewq points out. o(1) stands for o(f(n)) where f(n) = 1. Hence any function g(x) in the family of functions represented by o(1) must be less than c * f(x) for every positive c and all x greater than some m. This is exactly the statement that any function in the family of functions o(1) must tend to zero.

Whenever you see big-O/little-O/theta notation there is always an implied dependent variable, even for o(1)/O(1)/Theta(1).

I think a nuance people are missing is that for big O, it is sufficient for the existence of any positive C and x, but for small o there must always exist an x for every c.

Or https://en.wikipedia.org/wiki/Prime-counting_function .

Yep, blurred on one of my devices.

I do not know why but this game makes the winning font look much better than it is when I use my code.

Whenever I try the winning font (b612, fira mono), I always go back to Liberation Mono.

I think it has to do with rendering. Have a spin with iosevka-term-ss05.

MBAs are seen as people without skin in the game. They are rewarded if things are going well, and are not punished if things go bad. The asymmetry makes these individuals look as if they are here to leech and most of their knowledge is just how to "network". Just pick any big bank and look at how the board members rotate as time goes on.

I remember that a bunch of my classmates in elementary school knew German through watching Pokemon on a German cartoon channel that was broadcasted in Croatia (required no paid subscription, unlike Cartoon Network).

It was incredible, the accent was impeccable.

Any idea if amount of cannabinoids produced by our own body is high enough?

No async/await is a good thing, IMO.

Using fp-ts there is never a need for async/await and the code is still linear, (Promise is transformed to TaskEither<Error, Result>, similar to the example in the article, although you can ignore the error and just map over the result, handling the error somewhere near the end of the chain).

Problem with async/await is that the syntax is so easy that eventually the whole codebase gets polluted by it, even parts that could have been completely separated.

From the coding perspective, the problem with promises arise when there is a need to bind the intermediate results. You can either store them in an object and return that object for the next .then(fn) call, or you can nest inside a promise. I guess nesting is what annoys people the most (pyramid).

> Problem with async/await is that the syntax is so easy that eventually the whole codebase gets polluted by it, even parts that could have been completely separated.

Curious, why is this bad?

Sometimes you don't want to pause (with await) and give something else the chance to execute (happens a lot in UI).

When code is sloppily written you realize that at some point you can't use much of the existing code outside of async.

One nice example of polluting the codebase is having async local storage. Now everything that reads from the storage needs to be annotated async and now your initialization pipeline might be insanely async. Good way to avoid it is to read the whole local storage at the beginning (having a sync interface) and then everyone just reads without await.

From recent experience, I did exactly that with storage and ended up removing thousands of async annotations that were no longer necessary.

Similar "mistakes" happen for other things and then at some point you are putting loading guards everywhere because your async operations are always awaiting and letting the UI update when it should not.

Behind async there is a real actual hardware reality. Accessing local storage (or the network) is slow and you do not want to block your UI.

You say async were all over the place. Either it makes sense because fundamentally, what you are doing IS asynchronous. Or it make no sense because the asynchronous nature of you calls are not important in your design (I don't see why but ok), in that case you can always break the chains by using a promise:

    async bar() {
      return await baz();
    }

    foo() {
      const promise = bar();
      promise.then(() => {}); // don't care...
    }

Yes, but the usual cases of -> "app starts -> load some state from local storage -> store it in memory for sync access -> do app" sometimes get lost due to the ease of async/await syntax.

If you have to chain network requests but each request depends on results of the former ones, then async/await makes it really pretty.

I have no idea how much async/await is too much.

What I do dislike is that storage loads, network requests and other things are tied to the same type, so when you look at code, you have no idea what's happening inside those async functions, but that story is for some other time.

I think I've heard that underneath, async/await gets desugared into a Task "monad" anyway.

Do you dislike async/await? If so, why?

I discussed it elsewhere in the thread.

This was my experience too. After the initial period where recruiters are a bit afraid to give you your first engagement everything starts flowing really smooth.

I started at Upwork and was constantly writing proposals and struggling with the search to find relevant jobs.

But on Toptal, even after an abrupt end of the contract I get something else in less than a week and it's zero effort from me and all effort from the Toptal team.

Even if I get bored and want a change, announcing the end of contract turns on the avalanche of offers from the Toptal team.

It's just insanely smooth and I had no idea I'd find something like that, initially.

Other comment mentions difficult onboarding process at Toptal with 3 interviews, is this also your impression?

Their interview process is well documented (for instance, here https://clevercoder.net/2017/09/04/toptal-passed-interview/). My experience was that it was doable, though you need to brush up your algorithm skills and have luck with the problems you get.

The interview process is onerous more than difficult: mostly leetcode style questions that need lots of practice for, plus a basic but time-consuming take-home task.

And for me the scheduling was super difficult: the whole process took weeks, with the only times available at odd hours West Coast US time, and my recruiter flaking and rescheduling once.

Beyond some basic level of coding, it's more a test of patience and time.

Automatically evaluated leet coding session (2 hours) + Live English language check interview (15 mins) + 2 week fake template project + Live coding session (30 mins).

I was fortunate enough to pass everything without additional attempts and had no job at that time. Some of my friends got in after 1 year (after you fail at some step, 2nd attempt is delayed), some never managed to complete the whole process.

It's their whole sales pitch - "hire the top 3% freelance talent". You're not getting in through a casual 30 minute conversation.

I understand, still would be interested in his experience.

This is computer modern optimized for printing. It’s not bad, the pixels are constructing the glyphs in a way that makes them good for printing.

Bitmap version of the font, I guess.

DVI files do not contain fonts. What happened here is that the DVI to PDF conversion targeted a low resolution bitmap output (for screen/download, not for printing). The vector font specified by the DVI file was rasterized at that point. Later, PDF compatible (PostScript) vector versions of the Computer Modern fonts became available.

https://wearables.cc.gatech.edu/resources/latex2pdf.html