lukeramsden

Why are AI researchers constantly handicapping everything they do under the guise of ""safety""? It's a bag of data and some math algorithms that generate text....

Can't read the full article due to paywall but ostensibly it's due to bias rules on race and not visa rules? Sounds like visas being abused and then backstopped by unrelated rules does not mean the visa rules shouldn't be fixed.

You joke but I have seen this far too many times... in very highly valued startups...

100% line coverage though!

Not really. Do you think that this is trivial at AWS scale? What do you do when people hit their hard spend limits, start shutting down their EC2 instances and deleting their data? I can see the argument that just because its "hard" doesn't mean they shouldn't do it, but it's disingenuous to say they're shady because they don't.

Can start with the number of unicorns in USA vs Europe, especially when you take population in to account https://www.failory.com/unicorns

If you can’t afford to pay the current employees that raise, you certainly can’t afford new people - the market rate is the market rate.

The best way to do this is message passing. My current way of doing it is using Aeron[0] + SBE[1] to pass messages very efficiently between "services" - you can then configure it to either be using local shared memory (/dev/shm) or to replicate the log buffer over the network to another machine.

[0]: https://aeroncookbook.com/aeron/overview/ [1]: https://aeroncookbook.com/simple-binary-encoding/overview/

Part of test-driven design is using the tests to drive out a sensible and easy to use interface for the system under test, and to make it testable from the get-go (not too much non-determinism, threading issues, whatever it is). It's well known that you should likely _delete these tests_ once you've written higher level ones that are more testing behaviour than implementation! But the best and quickest way to get to having high quality _behaviour_ tests is to start by using "implementation tests" to make sure you have an easily testable system, and then go from there.

I did some research in to this this year in the context of maybe trying to start a business to solve this - and this was the conclusion I came to. There’s lots of threads here on HN about it too. It’s a structural, market-wide issue where the primary service Ticketmaster provide is reputation laundering, and in return, large agents and promoters agree to continue to use Ticketmaster despite their reputation.

I don’t know what the solution is.

> There are many instances I've encountered where two pieces of code coincided to look similar at a certain point in time. As the codebase evolved, so did the two pieces of code, their usage and their dependencies, until the similarity was almost gone

https://connascence.io/

Learning to program does not equate to learning to architect and evolve over many years a non-trivial system, operate it, document it, train others on it, scale it, etc. - “unmotivated” is a bit reductive. In the same way I might enjoy some DIY here and there but don’t want to and shouldn’t be trusted to build new houses, the same goes for non-trivial systems - sometimes you really do just need professionals.

That’s not to say you can’t give areas with guardrails to non-software-engineering-professionals if you can teach them git.

The difference is that nobody has to actually accept updates that the core team make - and this has happened a few times, resulting in forks, although those cases were for things the core team refused to do - how can you “fork” a security? What is the common enterprise when forking a PoW chain?

> Even if this leads to humourously Java-esque code, it's worth it

Some people seem to get mad about the verbose naming common in Java - but it’s one of the biggest blessings I’ve ever experienced. If you name things after what they do, and that name is stupid, then it’s the quickest indicator of bad design I’ve ever seen. Good design is where every name is patently obvious and encompasses the entire purpose of the class / record / method / whatever.

Then the price has to go up. This sounds like… regular market dynamics? It’s still not clear why that’s a crisis?

Works absolutely fine with git, you just have to take the time to keep the pre-commit checks reasonably quick

> Should Microsoft be forced to rename itself to Microsoftandhard because they make hardware?

I and I suspect many others would not be averse to this

> and what everyone wanted most was a stable relationship, a job they enjoyed and to be able to afford a modest house. > It's reassuring that in a seemingly insane world, the kids who are coming up seem have their heads screwed on straight.

One might say that the reason is because this is seemingly becoming harder than ever in Western countries.

> spend 4 hours putting a webflow site on top of GPT APIs

GPT _is_ AI though, no? I would think that this would count. Might violate "a re you exaggerating what your AI product can do" or "are you aware of the risks" instead though.

You still have to do all that with cloud though - instead of firewalls and IP tables it’s VPCs, IAM, security groups, auto scaling groups, etc etc. The reason I think it’s still probably better for Sprocket Masters to go cloud is purely because those skills are easier to hire for.

that's actually a very interesting idea. you could probably generate a proto schema from your edgedb schema...

> What I want is a new database that defines tables in terms of rich structures like proto, like Spanner.

Do you mean like https://www.edgedb.com/? Or something more... rich?

> Does this mean we could fragment an application into, say, a low-level "engine" or "kernel" in C or Rust, an application server to handle requests to it, and the view be any of a React Native mobile app, desktop app, or convenience web API?

Let me present: Kotlin Multiplatform Mobile[0] (or KMM, a real mouthful I'll grant you). Something I'm very excited about, because you could do exactly that. Seems like an interesting thing to keep an eye on.

[0] https://kotlinlang.org/lp/mobile/

(note: I agree with your approach, just making a point)

> that uses the latest Angular

But what's the migration plan for the next time Angular goes through a massive ecosystem migration and suddenly you're staring down the barrel of being massively out of date, or investing anywhere from days to months of work running just to stay in place? This is what actually seems to be the problem to me, not just in frontend either: very little is stable, and you end up piling hacks upon hacks just to try and stay up to date. People also pick new tech after being burned by previous tech doing these massive ecosystem-wide migrations and seeing how painful it is.

I wish I knew the solution :)

I’d love to know more about how one gets to be in the second group at all as a non-Googler - might make working at a FAANG worth it.

Object pooling, mutable objects, flyweight encoding[0], and being allocation-free on the steady state are all alive and well in latency-sensitive areas like financial trading, plenty of which is written in Java

[0] https://github.com/real-logic/simple-binary-encoding/wiki/De...

Only works if you actually do pull requests. I wonder what startups like Coherence think of Trunk-based Development and Dave Farley-style CI/CD?

In my experience (and our experience at TransFICC building middleware for financial trading systems, which is extremely throughput and latency sensitive), Java is the fastest language to work with simply because the tooling support is second to none.

I agree with the other commenter - in my view, a monorepo is the _best_ choice for a small company. I guess this depends on what tooling is available for your language / ecosystem of choice though. In my experience of TypeScript and Java with monorepos, you definitely need to know how to configure the tooling properly (which is certainly "overhead"), but it massively reduces the maintenance cost and increases the consistency of your tooling config. Spreading out over loads of repos means you need to share artefacts, which means package managers and package manager hosts, and a whole suite of release CI/CD which gets out of sync almost immediately.

It's also getting a lot better, gradle works amazingly well for a monorepo even with dozens of developers committing to it every day with shared caching, nx/turborepo/others are making the story for front-end/TS much better too.

Sounds like you should be writing some blog posts about writing complex applications with this stuff

> If you don't have the discipline to do these things then they are likely best avoided.

I'd go further and say you should avoid databases and maybe even persistence entirely if you don't have the discipline to do the above. Sprocs will be the least of your problems otherwise.