aelzeiny

Give Indians US salaries and see if they're "difficult to work with".

> Don't use those...then an additional 4.9% can be handled with jotai...

Needing Jotai on top of React's defacto state management is the issue. TFA talks about an ecosystem of libraries that attempt to fix React's shortcomings. Pure React does have undeniable shortcomings like proper, non-brittle routing.

The two-part xbox episode was my personal favorite, because I remember that scene in my early years but never knew the story behind it.

The North Korea 3-parter is equally good IMO.

This is accurate. Their competitor, the Ecovacs Deebot, just push an OTA update making cable detection way better. In a way the previous comment encapsulates all the misconceptions about robovacs. I was recently surprised to learn how good they are because my only basis for comparison was my friend's failure of a Roomba that's always getting into shenanigans.

To expand on this OP, I've done the AWS-full-stack approach in a mid-sized startup. Modern Serverless problems require modern serverless solutions. That ecosystem is simply not as developed as "traditional" web-server CI/CD. Here are some things that you will eventually need to optimize for.

- After crossing a certain threshold in scaling needs, Lambda costs more than regular EC2 on ELB

- Lambda cold-start times can be a deal-breaker when users first visit your website. If you contact AWS they will tell you to setup a simple cron job that keep lambdas "warm". But AWS provides no visibility in what's warm or cold, or which endpoints link to which lambdas.

- Dealing with Cloudwatch logs of various lambda runs (IMHO) is objectively a bad dev experience. Query insights is getting better, but is still a pain to work with.

- To reduce deployment and development times, you'll eventually want to deep-dive into lambda layers. Modern problems modern solutions.

- One lambda calling and awaiting another lambda is not a supported first-class use-case. There's no API that allows you to get the status of a lambda run. There's a hack around this where you use AWS Step-Functions. Modern problems modern solutions.

We're still on AWS full-stack "serverless" for our webserver and realtime stream processor. At the time I didn't know what I was getting my company into. I wish I just made a Flask webserver instead.

Nobody will suggest Java, but honestly Java. Java has pretty great flexibility when it comes down to concurrency. It sets the standard which all the other languages have to compete with.

Apart from that, I like languages and frameworks that scale out of their box and into the world of distributed systems. Elixir is very cool, because the concept of distribution with message passing is built into the core of the language. Alternatively, Scala's Akka Framework operates on a similar concept of passing messages to Actors. My bias here is that I don't like to deal with very large super-computers, and would rather have multiple smaller machines that are allowed to blackout occasionally. This is especially relevant for websockets because the stateful connection to a client can be made on any single machine in a cluster, but the state itself is (often) global.

It's always been a Swiss Army Knife. It's a single-threaded-in-memory caching, pubSubing, streaming, distributed-locking beast.

> "It's hard for us to ignore that others are doing it, but for now it doesn't make sense for us"

And that's completely reasonable.

SPAs exist for a reason. Same with SSR. Developer ergonomics play a bigger role than you think. And if you think that the choice is either SPA or SSR then you haven't been paying attention to recent developments in the frontend world.

Websockets+SSR (PhoenixJS) attempts to store state on the server rather than the client; in that way you can still have stateful interactions with minimal JS. NextJS does an amazing job patching the bridge between SPA+SSR by having the same codebase run on the backend and the frontend. What I would like to see more of from this industry is less "grass is greener on the other side" and the unification of a single tool that allows for the cross-collaboration of SPA + SSR without having two distinct codebases that one has to context-switch between.

> I dislike all the magic of rails.

This is my #2 problem with Ruby, and it's also the reason why a lot of folk love it. I think of macros in the same way I think of RegEx, if you're writing one you better hope it works perfectly because chances are that you'll be the only one to maintain it.

Other Ruby "features" that I dislike:

1. Blocks + Procs + Lambdas are all function-adjacent. Can't we just call them functions?

3. Out of bounds indexes on Arrays/Maps return nil.

4. method_missing() is super cool and super abusive. Again it feels like magic when functions come from nothing.

Honest question from someone completely oblivious to AMP. What problem was AMP trying to solve? "Make websites load faster" is a buzzword-flag to me, and it's not really explained in the wikipedia article [1]

[1] https://en.wikipedia.org/wiki/Accelerated_Mobile_Pages

Fair enough. "Crazy complicated" and "the professionals" are both intended as subjective terms. To ME this stuff might as well be magic.

There's a searching concept known as edit (levenshtein) distance that is close but not exactly what you're talking about. To rephrase your question: is there a datastructure that can pre-compute the levenshtein distance for a set or results?

Yes, and it's crazy complicated. See Levenshtein Automata[1]. In reality, I would let the professionals handle this by either using Open/ElasticSearch or Apache Lucene.

[1]http://blog.notdot.net/2010/07/Damn-Cool-Algorithms-Levensht...

All good choices, but it's also worth noting that the structure of the author's DAG is strange. The way this is set up, you would have to change Python code to run (or rerun) this task for different days.

In canonical Airflow, the job would be one DAG, and each day would be a separate DAG run. Then you would backfill all the days that you would like the job to run. If there's some sort of max-concurrency requirement, that would be handled by setting the `max_active_runs` parameter or by using Airflow's pool concept.

If I had to venture a guess, the author is not an experienced Airflow user, and just wanted to give a new technology an honest try.

Xenophobia is a classic way to win an election. From that perspective this is a great policy for him.

True, I'm not disagreeing with you. However, it's worth nothing that Cockroach DB's consistency model assumes consensus in 180ms, and Spanner assumes similar SLOs at 6ms. Arguably, one could say that the reason why an open-source spanner-like DB doesn't exist in the marketplace with comparable performance is because these types of cards are proprietary and close-source (i.e Google's TrueTime). To your point, Cockroach is much less dependent on highly accurate clocks, but if these PCI-e cards became a common hardware commodity Cockroach can become even faster.

Now imagine a world where distributed DB technologies get so good that the trade-offs between consistency and availability is enough to warrant the use of a distributed DB for mid-sized projects. Right now, these DBs are seen as muscle cars with high cost and high maintenance only for BIG projects. A card like this might be the game-changer.

> a sign of poor code quality

Or really complex software. Those of us who work in B2B SaaS products know what it's like to understand what a block of code does, but not comprehend why it was written.

However, I don't disagree with this sentiment. I think what most devs fail to understand about git-history is that it's just another place for sparely populated documentation. Your commit history might be AMAZING, but chances are that nobody knows to look for it. There's just too many places where one has to reiterate intent and purpose (doc-string, inline comments, project specs). It's a lot to keep up with - especially for non-technical folk.

Solutions:

What worked best for my team to was a simple git precommit-hook shell script that just auto-tags the ticket number onto the start of every commit message. So `git blame` just points back to JIRA/Asana/Trello/Whatever you're using to document intent. That way, there's a single source of truth for developer documentation that is accessible by everyone.

At Google if there's something that needs explaining you'll see a tiny-url-link that just points to the Google Doc as an in-line comment (i.e: go/my-project-specification-doc). Commit messages do the same. This saves on copy-pasting multiple lines of purpose on every file and line of code.

I really like this engineer's method of software estimation. It's really close to what Civil Engineers use to estimate load, called Load-Factor-Resistant-Design. That's a fancy way of saying, that we come up with an estimate, then multiply by an uncertainty constant called "Factor of Safety".

Steel in tension, low uncertainty, LRFD safety factor is 1.75. Steel in compression, medium uncertainty, safety factor is 2.5. Anything to do with soil, high uncertainty, safety factor of 4.

Same principal really. If it works for life/death scenarios, it'll work for you!

I aspire to be like the writer of this comment. Using the good parts of both languages to be a productivity machine.

> The cons are mostly compile time and startup time. Startup time isn't very relevant for backend services. Compile times aren't great but not horrible either.

I'd also throw in readability into the mix. Without knowing the magic it's hard to reason about. Then even by knowing what the magic does you have to have some intuition for its arbitrary rules based on its implementation in reflection-land.

<rant> Let's take an example: Autowiring. Java is the type of language heavily that pushes programmers to use the Strategy Design Pattern. It's almost the core of the language's philosophy. However, if I want a file that globally states to always use a specific Strategy then I have to turn away from native Java to the dark magic of dependency injection frameworks (Guice, Spring). If I'm reading such code, I have to know to look for a file that maps a Bean to a specific strategy; which is not apparent anywhere on either file. It's somewhere else in XML or a vague annotation that I have to now wrap my head around. To do so, I have to understand arbitrary limitations to the dark magic like whether this Bean is matched by name, type, or qualifier. All of this can be a little overwhelming at times when you're looking at a file where every variable is a Bean. </rant>

But if you drink the cool-aid, boy does it taste good. I can't start a new project without Guice (pun intended) now-a-days.

As someone who works in Data Engineering, I'm a big fan of cloud-based docker containers with services like AWS Fargate/Google Run. It allows us to be able to pay for resource use rather than provisioning. For the longest time I had to justify the additional cost and constant maintenance of an n-th server just to accommodate for capacity at peak hours. Anecdotally, most of our batch jobs don't need high availability, so the startup time of a server-less docker is an acceptable trade-off to parallelism.