3PS

This feels like the opposite to me? The MoT architecture looks like the ideal that the Bitter Lesson alludes to - just take all of your data in all of your formats (audio, image, text, action, video) and dump it all into a single shared latent space. Then let the model sort things out, with just enough structure to handle the different requirements/output formats needed (e.g. autoregressive stuff for sequence modeling/prediction, diffusion stuff for generation).

Duolingo | Full-time | Multiple roles | $177K-$240K for NY roles | NY and London | Hybrid

Our mission is to develop the best education in the world and make it universally accessible. Our culture is eng-driven, friendly, and very data-driven thanks to our large userbase. Check out our blog to see what engineering at Duolingo can look like: https://blog.duolingo.com/hub/engineering/

Tech stack: (frontends) Swift/Kotlin/TypeScript, (backend) Python/Kotlin/Postgres/Dynamo, (infra) AWS/k8s/Terraform.

We're always hiring for engineers. A few roles below:

Senior Engineering Manager, Chess (NY) https://careers.duolingo.com/jobs/8385137002

Senior Android Engineer (NY) https://careers.duolingo.com/jobs/8217266002

Senior iOS Software Engineer (NY) https://careers.duolingo.com/jobs/8318257002

Engineering Director (London) https://careers.duolingo.com/jobs/8444624002

Senior Gameplay Programmer (London) https://careers.duolingo.com/jobs/8424809002

Base salary: $177-240K for the NY-based roles, unsure about the London-based roles.

Perks: breakfast and lunch served in office, 2-week winter break + 20 days of flexible time off.

Duolingo | Full-time | Multiple roles | $177K-$300K | NY and Pittsburgh | ONSITE

Our mission is to develop the best education in the world and make it universally accessible. Our culture is eng-driven, friendly, and very data-driven thanks to our large userbase. More info about working as an engineer at Duolingo here: https://www.youtube.com/watch?v=WThT8sufdBE

Tech stack: (frontends) Swift/Kotlin/TypeScript, (backend) Python/Kotlin/Postgres/Dynamo, (infra) AWS/k8s/Terraform.

We're always hiring for engineers. A few roles below:

Senior Engineering Manager, Monetization: https://careers.duolingo.com/jobs/8414653002

Senior Android Engineer: https://careers.duolingo.com/jobs/8217266002

Engineering Manager, Chess: https://careers.duolingo.com/jobs/8385137002

Senior iOS Software Engineer: https://careers.duolingo.com/jobs/8318257002

Base salary: $200K-300K for Senior Eng Manager, $177K-$240K for the others (+equity).

Perks: free lunch, 2-week winter break + 20 days of flexible time off.

This is also the case with Google Fuchsia, just replace 9P with FIDL. I'm really hoping Fuchsia doesn't end up just being vaporware since it has made some very interesting technical decisions (often borrowing from Plan 9, NixOS, and others.)

Different bracketing.

"If it sounds too good to be true, it usually isn't (true)"

vs

"If it sounds too good to be true, it usually is (too good to be true)"

I think you're technically correct here: if you just have a bunch of Merkle trees where each one tracks the hash of the previous block, it would be accurate to refer to it as a blockchain even if you're not bothering to implement any of the distributed consensus algorithms that cryptocurrencies are actually known for. It's probably not the first thing that would come to mind, but it is a correct way to use that word.

> One way of thinking about a blockchain is to think of it as a shared datastructure to keep databases in sync. Any time you want to distribute your database over more than just a single central place, in a cryptographically secure way, you're probably going to re-invent a blockchain to do it.

Even more specifically, a blockchain is for when you want Byzantine fault tolerance, i.e. you don't trust one or more of the actors involved. This is the main distinguishing feature of blockchains IMO, the reason we have proof of work, proof of stake, etc. It's also the main thing I saw people getting wrong when using blockchains during the earlier waves of cryptocurrency fever; most proposals for blockchains did make sense as distributed public ledgers, but didn't really need the extra computational overhead because only trusted parties were adding blocks to begin with.

I think both you and GP are correct, but in different ways.

It's true that the English language has a very large number of phonemes... but accents tend to regularize/restrict these phonemes. For example, a typical bilingual speaker of Indian English and Hindi will replace instances of the /æ/ phoneme (as in "blast" or "fast") with another phoneme like /a:/ (as in "father"). Which isn't that unusual since /æ/ is pretty uncommon among languages.

Other rare English phonemes include the dental fricatives, i.e. the "th" sounds in "ether" (voiceless) and "either" (voiced). Speakers of Indian English often replace this with a dental stop, a "t" sound (voiceless) or "d" sound (voiced). (Note that Devanagari has a _lot_ of stops, so this is one place where it cannot be cleanly encoded into the Latin alphabet without diacritics.)

So overall: while I think Devanagari can't encode e.g. American English, it can actually do a pretty solid job of encoding Indian English, but not the other way around.

For prices specifically I think it's fair to say that inflation only goes in one direction, but for larger market trends, IMO the key here is _habit building_.

Many things were technically feasible pre-pandemic but not done habitually: remote work, streaming movies instead of going to the theater, ordering delivery instead of dining out, and so on. The pandemic forced many people to change their habits and get over any initial inertia (e.g. investing in a WFH setup or home theater). The result is that when the world returned to normal, the markets didn't: consumer habits had already moved on.

Broadly summarizing.

This is OK and fair use: Training LLMs on copyrighted work, since it's transformative.

This is not OK and not fair use: pirating data, or creating a big repository of pirated data that isn't necessarily for AI training.

Overall seems like a pretty reasonable ruling?

> But fish is too much like bash in syntax, meaning that I just think of it like bash until I have to type "(foo)" instead of "$(foo)", or "end" instead of "fi"

Note that fish does also support bash's "$(foo)" syntax and has for a few years now.

Nit: that's not what negative reinforcement means. Negative reinforcement is about removing a negative stimulus, like inducing someone to go to a desirable website by improving their initially bad text contrast whenever they go there.

In this case, jumpscaring yourself would just be considered punishment (or "positive punishment").

Quiver was absolutely indispensable when I did a category theory course a few years ago. The UI was clean, intuitive, and featureful. Compared to banging one's head against Tikz, it's absolutely no contest.

It doesn't always work, but I like the SQLite model: the core offering is free and open source, but enterprises can pay for things like

* Professional support, including on-prem hosting when applicable

* Additional features that enterprises care about (encrypted databases, SSO)

* Compliance documentation/certifications

> As my understaning it bring bunch of features out of box, syntax highligh, tab completion etc.?

I think this is a good summary. The best thing about fish is that you don't need to install any plugins to get all of the nice things that other people put a lot of effort into configuring: tab completion, syntax highlighting, and so on. It's also just really comfortably ergonomic in a way that is hard to describe unless you've used it - multiline commands automatically update their indentation as you type, completions for most common programs come pre-bundled, you can easily set environment variables globally across all of your shell instances without fiddling with config files or reloading your shells, and so on.

Poetry has two flaws imo:

1. It's written in Python, which makes it slower and prone to bootstrapping issues.

2. It doesn't manage your Python installation, which necessitates the use of a tool like pyenv.

Rye sidesteps both of those by (a) being written in Rust and (b) trying to solve all of the problems solved by poetry and pyenv in one go.

I agree, but the definition alone isn't sufficient to actually calculate eigenvalues. Hence the standard approach which says that for matrix A, vector v, and eigenvalue λ, we have

  Av = λv
  => Av - λv = 0
  => (A - λI)v = 0
  => det(A - λI) = 0

Which then yields the characteristic polynomial. Skipping the determinant means you need a different approach.

> The novel approach taken here banishes determinants to the end of the book.

Big fan of this approach! Though I have warmed up to determinants ever since I saw 3Blue1Brown give a fairly intuitive explanation for them [0].

I'm kind of curious as to how they covered eigenvalues/the characteristic polynomial without determinants. Maybe they just jumped straight to diagonalization?

[0] https://www.youtube.com/watch?v=Ip3X9LOh2dk

I paid for Tasker years ago but never got around to trying it. This might be the impetus I needed.

Joke or not, this could be a pretty ergonomic way to read long form content. Currently I rebind my mouse side buttons to page up/down which serves much the same purpose, since scrolling endlessly on a mouse doesn't feel great for your hands.

I use a Pixel with the Nova Prime launcher (which is a fantastic launcher) and it can do all of these things except the audio stuff. Individual app audio control is definitely one of the features I wish I had the most.

Adding to the other comments, one thing I have heard about projected population decline is that it tends to happen very _rapidly_. That is, even if birth rates are below replacement level, it takes a while for that number to get reflected in the bottom line population statistics, and by the time a crash in population has serious consequences, it's too late to stop it.

Condolences to the author, but this is a huge relief. A polytime quantum algorithm for LWE would have been a scary prospect for the future of asymmetric key crypto. (Not to mention all the other cool stuff people are building on top like fully homomorphic encryption.) Even if it wasn't quite fast enough to break the current schemes that NIST is standardizing, I (and I'm sure many others) would much prefer those problems to stay in exptime.

This looks really exciting - will definitely check it out.

Until now I've been using jq with up [0] for interactive queries, but I don't find myself liking up's UX much (especially for long queries or non-ASCII data) so I'm keen on looking for a replacement.

[0]: https://github.com/akavel/up

Understandable, though JVM strings can also use the UTF-8 charset under the hood. In fact, if you initialize a Kotlin string from a byte array, it'll default to assuming the UTF-8 charset [0]. (Kotlin chars are still 16-bit code units though, and it is true that you can't use the native JVM char type if you do this. Personally I think that's still acceptable.)

[0] https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.text/-st...

Seems like an interesting language with a lot of new ideas, especially the declarative concurrency approach. I am very disappointed by the decision to go with UTF-16 for strings though [0] and strongly urge the author to reconsider. UTF-16 is the worst of all worlds: it is inefficient, it is endianness-dependent, it is still variable-width like UTF-8 for code points outside the basic multilingual plane (like emojis!), and it adds an O(n) penalty to processing most text from the internet. It also means that you need a whole new fundamentally different data type outside of char for encoding byte sequences.

Please, for modern software UTF-8 everywhere is the way to go!

https://utf8everywhere.org/

[0] https://docs.clarolang.com/common_programming_concepts/varia...

Your mistake is here:

> The possible values of N are evenly distributed [1...100] (we discount the N=0 case because we drew a red ball)

These probabilities over N are not actually even anymore; the fact that you drew a red ball means that higher values of N are more likely.

> I do wish fish could seamlessly convert and run bash scripts on the fly..

It can. With a little help. I use this:

https://github.com/edc/bass

Chiming in as another fish+starship user. It's hard to imagine using anything else now; I get just about every feature I would ever want out of my shell with essentially zero configuration, which makes it easy to replicate my setup across a ton of heterogeneous devices and operating systems.

For reference, that "some guy" is Andy Pavlo, a professor of databases at Carnegie Mellon. He has a lot of neat writeups online, like this annual review of new database systems [0]. He puts up lectures on the internet for free too.

Having been to Dr. Pavlo's office - or at least, one of them - I can attest to there being multiple cardboard boxes filled with gifted shirts from different companies. One of my favorite designs was actually from CMU's DB group itself - it has a little "this database kills fascists" tag on it, with a skull motif :D

[0]: https://ottertune.com/blog/2022-databases-retrospective