Tehnix

I’m 100% for globalism, but you cannot outsource your sovereignty. The US has proven time and time again that it is fine with using its embedding into nations as a bargaining chip, and has proven highly unreliable.

It is quite puzzling to me though as to why.

We have plenty of talent here to build stuff ourselves, and frequently do.

If I’m honest I’d guess lobbying and/or trade deals where we often agree to buy smth from the US.

A recent one is NHS (UK healthcare system) and Palantir, which makes no sense to hand over core medical data to an outsider. That seemed a clear lobbying case.

Palantir should be completely banned from any EU government contracts. We cannot keep handing over our most core systems and data to non-EU entities, especially given the US’s adversarial stance towards EU.

I don't see a way it wouldn't be offered in addition to. Some EU countries (e.g. Denmark) already do something similar where we a national debit card called "DanKort" (mashup of "Danmark" and "Kort" which translates to "Denmark" and "Card"). It typically also has a VISA part to it for usage abroad.

All stores accept this as well as VISA/Mastercard since they want to maximize who they can get money for, so it's already a common place practice for payment terminals to do this. Tourism alone is enough of a reason you would accept VISA/Mastercard still.

Compiling Rust is actually quite fast in my experience

I guess it's all relative.

I find Rust's compile times abhorrent and it's objectively slower than many many other languages that also pull in dependencies left, right, and center. I guess that just means Rust scales very badly with amount of code.

I'd put it at a bit better than Haskell, but honestly not by much.

I really wish Rust would focus much more on compile times, or on making smaller parallel compilation units. It's quite a chore to have to keep splitting your program into smaller and smaller crates just to not sit and wait for an eternity.

As a comparison my CI job for Rust takes 14m running on a 16vCPU machine while my much larger TypeScript project compiles in 1m on a 2vCPU machine. I know people that have to spend quite a lot of work on keeping compile times manageable for Rust (nix, smaller crates, aggressive caching, etc etc).

Rust still brings me enough value that I'll stick with it, but one can still dream of a better future :)

It’s not OK as a hard requirement for anything else such as banking.

What’s the alternative that you think is okay for that then?

Certain businesses have regulatory requirements to know and verify your identity (banking, telco).

A UK poster gave an example of how they need to mail the bank a copy of their passport and other private information.

I’d certainly much prefer simply using a digital login solution as an alternative to that. They can verify I am who I say I am, without needing my passport which I would consider a much bigger privacy invasion to hand out.

MitID doesn't work on rooted android phones, or those running a custom rom.

I find these arguments quite strange. A big part of MitID and similar services is to protect you against fraud. The most vulnerable in society (e.g. old people) aren't running these kinds of devices, and I'd rather we optimize for the general population and the people most at risk, rather than people running some weird setup that is almost identical to setups a scammer would run.

What privacy aspects are you lacking here? For all the services that MitID connects you to, there are government required responsibilities for these companies to track all of this information anyways and be able to provide it to the government if needed. That goes for banking, public services, telecom, etc. And this is in no way unique to Denmark, it's how most countries operate. Denmark has just acknowledged this and decided to make it easier.

Did you expect your UK bank to not be required to know who you are and be able to track and keep records of literally all financial interactions you have with them and their services? I'm a bit confused on what society you are comparing against.

I see a few people here complaining about the idea of a central digital identity service.

As a Dane, having lived in other countries, MitID is an insanely superior to anything I've ever tried. It simplifies so many touchpoints with the government, and is honestly such a good upgrade going from nothing -> physical NemID card with codes -> digital MitID (literally "My ID").

The only real disruption I'd say is if you happen to be buying something online that triggers the 3DS prompt (an additional security layer to prevent cards getting stolen/scam). In Denmark the 3DS prompt for VISA at least uses MitID to verify you are the owner of the card, so that'll obviously not work when MitID is down.

I'll say, it has been surprisingly stable though otherwise, and disruptions usually aren't a big impact (I literally wouldn't have known unless I saw this HackerNews post).

As for a centralized identity system: I personally see this as an acceptable contract for living in a society. Most countries have SSNs anyways, your taxes and many other things are tied to this. Centralizing this identity allows the government to streamline so many things to give a better service to their citizens. For example, all official communication goes to your "DigitalPost" email inbox, your verify identity with "MitID", and every person or company has a registered "NemKonto" tied to them for any salary or government payouts.

I maybe see people get tripped up at the concept that your government should actually care about the service they deliver. That's probably already the point where we diverge when talking about if these things are a good idea or not.

Bunch of negative sentiment in here, but I think this is pretty huge. There are quite a lot of applications where latency is a bigger requirement than the complexity of needing the latest model out there. Anywhere you'd wanna turn something qualitative into something quantitative but not make it painfully obvious to a user that you're running an LLM to do this transformation.

As an example, we've been experimenting with letting users search free form text, and using LLMs to turn that into a structured search fitting our setup. The latency on the response from any existing model simply kills this, its too high to be used for something where users are at most used to the delay of a network request + very little.

There are plenty of other usecases like this where.

OP here.

Really couldn't find many resources on how to actually use subsecond in your own Ruest applications for a better development experience, so thought I'd share the step-by-step I just did to get our own project up and running with it.

I'm sure there's some optimizations that could be done in order to hot-reload less of the code, but I think this is a pretty good starting point for people that are just looking to "reload my server on change, without killing it during the reload".

Let me know if you have any questions or things you'd like me to try out!

Nothing has opened my eyes more to how much mainstream media is distorting reality to fit their narrative, than the genocide Israel is committing in Gaza.

You can sit with literal video of an incident, and then see media headlines tell a completely different story than what actually happened.

Social media in our generation has been a weird amplifier of both misinformation as well as truth from the ground that contradicts misinformation in the media.

My selection of topics I trust media to report on has greatly narrowed down to ones that are completely apolitical, which is sad (they’ve always been biased, but at least I felt you could tell that they were biased and read through it).

With investments of these huge amounts (similar to Anthropic's recent investment), do they actually get a full 1.7B€ deposited into their bank account? Or does it work in some other way?

Ah, the penny drops. The idea that you can’t run a traditional server and must rely on serverless vendor if you’re “serious”

That's not at all how you should read this. They later on give an example of exactly what kinds of problems you'll run into once you start needing to horizontally scale you Next.js servers (e.g. as pods in k8s, which is not serverless):

The issue of stale data is trickier than it seems. For example, as each node has its own cache, if you use revalidatePath in your server action or route handler code, that code would run on just one of your nodes that happens to process that action/route, and only purge the cache for that node.

Seeing as a Node.js server running Next.js serving SSR or ISR (otherwise you'd just serve static files, which I personally prefer) is not known to have the greatest performance, you will quickly run into the need of needing to scale up your application once you hit any meaningful amount of traffic.

You can then try to keep scaling vertically to avoid the horizontal pains, but even that has limits seeing as Node.js is single-threaded, and will run into issues with the templating part of stringing together HTML simply taking too long (that is, compute will always block, only I/O can be yielded).

The common solution for this in Python, Ruby, and JS/Node.js is to run more instances of your program. Could be on the same machine still, but voila! you are now in horizontal scaling land, and will run into the cache issues mentioned above.

There was not really anything in the article that should have lead you to believe that this was a "serverless only" issue, so I think the bashing against Netlify here is quite unwarranted.

Hmm, beyond a bug they had in bun between version 1.0.8 and 1.1.20[0] bun has otherwise worked perfectly fine for me

You have to do a few adjustments which you can see here https://github.com/codetalkio/bun-issue-cdk-repro?tab=readme...

- Change app/cdk.json to use bun instead of ts-node

- Remove package-lock.json + existing node_modules and run bun install

- You can now use bun run cdk as normal

[0] https://github.com/codetalkio/bun-issue-cdk-repro

If you're not a Medium member, I've included a link in the start of the post where you can read it for free :)

In case you're not a Medium member, there's a link to read it for free right at the beginning of the post :)

Imagine this happening on a longer sail where help might be much further away, that’s kinda scary

I definitely would not be surprised if this ends up in people being prepared for these attacks in the future, if this keeps occurring, and I’m afraid that won’t do good for the orcas.

I feel I should bring up that in the EU there almost exists two worlds when it comes to GDPR: Germany - and the rest of the countries.

I’ve made software for the childcare industry, where the data concerns are greater than most other industries.

Nobody had any problem with AWS, or really any non-EU vendor, as long as they lived up to the GRPR agreements and could provide the usual agreements.

Only in Germany would you run into requirements to either host in Germany (at worst) or at least within EU (at best). Additionally, there’s a lot of German specific laws on top, that simply aren’t in the other EU countries, and the general population is also much more concerned about data privacy and residency than any other EU country.

It was a world of difference, and honestly enough for me that I would not enter the German market again if it meant needing to comply with any additional effort than the rest of the EU market.

A bit more of a rant: The hosting solutions in Germany are also quite atrocious once you get to a certain scale. Lack of proper managed services, tons of instability, insane maintenance policies, poor security support (eg no 2FA for many). Once you’ve gotten used to how AWS/GCP/Azure handles things, it’s hard to go back to that world.

Edit: Almost as response to my last point, AWS is setting up a unique EU sovereign cloud https://aws.amazon.com/blogs/aws/in-the-works-aws-european-s...

I make daily/weekly/monthly goals, and structure it in whatever App I use e.g. Linear, Todoist, or Notion.

- Monthly goals are very high level and few (e.g. “Make PoC for this”, “Redesign and relaunch blog”)

- Weekly goals are more tangible and limited (e.g. “Settle on approach for calling Rust from Swift code”, or “Finish design and styling of posts”)

- Daily are very concrete (e.g. “Set up UniFFI pipeline to generate Swift bindings” or “Implement new theme across blog pages”)

Sometimes things come up that I discover during implementation, and then I typically shift a daily goal to the next day.

Has worked well so far for giving me focus, and I then pick the daily goals based on the weekly focus from the list of many open tasks/issues I have in my various projects.

I set up each thing I’m working on as a Project in e.g. Linear, and immediately add a priority when I add things, which allows me to easily keep an overview of many smaller or larger projects I might have going on or want to do in the future.

While I do like paper, for me that’s only for ephemeral things. I prefer to keep things digital, allowing me to easily add stuff from my phone in the go when I get an idea while being out-and-about. I also write much faster on a keyboard and use the various tasks as the dumping ground for info while I’m working through something or researching something.

I've been playing Diablo 4 and Diablo II Resurrected on Crossover ever since Whisky didn't work with Battle.net anymore. It's been working great tbh!

I’m definitely of the opinion that what Figma[0] (and earlier, Notion[1]) did is what I’d call “actual engineering”.

Both of these companies are very specific about their circumstances and requirements

- Time is ticking, and downtime is guaranteed if they don’t do anything

- They are not interested in giving up the massive amount feature AWS supports via RDS, very specially around data recovery (anyone involved with Business Continuity planning would understand the importance of this)

- They need to be able to do it safely, incrementally, and without closing the door on reverting their implementation/rollout

- The impact on Developers should be minimal

“Engineering” at its core is about navigating the solution space given your requirements, and they did it well!

Both Figma and Notion meticulously focused on the minimal feature set they needed, in the most important order, to prevent disastrous downtime (e.g Figma didn’t need to support all of SQL for sharding, just their most used subset).

Both companies call out (rightfully so) that they have extensive experience operating RDS at this point, and that existing solutions either didn’t give them the control they needed (Notion) or required a significant rewrite or their data structures (Figma), which was not acceptable.

I think many people also completely underestimate how important operational experience with your solution is at this scale. Switch to Citus/Vitess? You’ll now find out the hard way all the “gotchas” of running those solutions at scale, and it would guarantedly have resulted in significant downtime as they procured this knowledge.

They’d also have to spend a ton of time catching up to RDS features they were suddenly lacking, which I would wager would take much more time than the time it took implementing their solutions.

Great job to both teams!

[0] https://www.figma.com/blog/how-figmas-databases-team-lived-t...

[1] https://www.notion.so/blog/sharding-postgres-at-notion

even if it meant changing priorities 5 times in 3 days

That kind of thing is exactly what an EM is there to stop.

I’ve faced similar problems a couple of times, and it takes a lot of effort to correct the ship into a healthy Product/Engineering organization, but it can be done. There are tangible downsides to switching priorities constantly, and beyond inefficiency, team morale usually also takes a hit.

Now, without an EM, whose responsibility is it to stop this? No one’s really, it doesn’t land on anyone’s plate, so you either have to hope one of your colleagues with enough organizational leverage steps up, or do it yourself.

Honestly, the article lays out what I would expect the opinions of a junior or mid-level Engineer to be (it irks me quite a bit)

- Clearly not aware of the difference between “an individual” and “team dynamics”

- Unaware of the huge amount of organizational work that happens behind the scenes that someone needs to do (and I guarantee that you wouldn’t want to do that as an Engineer)

- Unaware of how much an EM shields their team as the frontline for questions, planning, prioritization, feasibility

- HR is never gonna be there to guide or mentor your Engineering career, which an EM will

Even the most senior engineers need guidance, and that’s what your EM is for.

The EM typically steps in to fill voids until they find qualified people to do these things. Not every Engineer is good as tech leads, nor as project managers, so it takes time to get them up-to-speed or find someone else.

There’s been a recent trend of rewriting tools in Rust with insanes speed gains

- Rspack (webpack compatible)

- Rolldown (rollup compatible)

- Turbopack

- Oxc (linter)

- Biome (linter and more)

- Bun (writing in Zig, does crazy fast bundling)

There’s several parts here that are crucial to Frontend development

For production you need:

- Minificion of source code

- Bundling of modules and source code into either one JS file or split into multiple for lazy loading only the parts you need

- Transforming various unsupported high-level constructs into something older target browsers support

- Typechecking/compiling, or stripping TypeScript if that’s in use

Build times could easily go to 10-20 minutes with older tools.

The development loop also gets hurt, here you’d want the loop from saving your change to seeing it in the UI to be almost instant. Anything else means you’ll have to develop crutch methods to workaround this (imagine moving and styling components only to need to sit and wait during each small incremental change).

Very excited for Cranelift for debug builds to speed up development iteration - in particular for WASM/Frontend Rust where iteration speed is competing with the new era of Rust tooling for JS which lands in the sub 1 second builds sometimes (iteration speed in Frontend is crucial).

Sadly, it does not yet support ARM macOS, so us M1-3 users will have to wait a bit :/

I honestly believe removing the Hobby plan to be a huge mistake on the long-term, while optimizing for short-term profitability.

Without any inside knowledge, I can only speculate, and who knows, maybe PlanetScale wouldn’t have been able to continue as a business, if they kept serving the Hobby plan

What I am quite certain of though, is that PlanetScale is far from ubiquitous enough to have people take a bet on a service they’ve never tried, without a way to try it risk-free first

It’s a competitive space, and killing your funnel of “Engineers learning technologies as a side-project, and bringing they tech into their day job” seems to me at least to be very shortsighted

Aren’t you assuming most people finish the full article? I find that quite unlikely, especially for longer articles.

I would definitely imagine a sweet spot between “they are now engaged” and “they haven’t given up or gotten distracted yet” is optimal, especially given people’s attention spans these days :)

Why not have both? That's exactly what DynamoDB offers, and people want the SQL equivalent promise of "it'll keep up no matter what scale you're at".

The point is: You don't want to need to switch technology at a later stage, you'd like to build with the right technology from the get-go.

I almost always go for DynamoDB first, since for small projects it's essentially free, and for huge projects I do not have to worry about the ops overhead that follows normal SQL databases.

A lot of people also have traffic patterns that go:

- Very high volume during the day - Almost no or little volume during the night when your users are sleeping

Aurora Serverless v2 gets us closer to this for SQL, but does not scale to 0 so it's not too nice for the initial phases of projects.

I really don’t understand this sentiment, it is extremely easy to build and deploy Next.js yourself??

You either:

- Build static files and host it like any other framework (e.g. throw it in an S3 bucket)[0]

- Or, run a Node.js server

Where’s the Vercel exclusive part there?

[0] Here’s me doing exactly that, going through the same steps I would for literally any Frontend framework, including the WASM alternative I also build in the post (exact same deployment) https://codetalk.io/posts/2023-10-16-the-stack-part-3.html#n...

There’s a two simple reasons I would go for Next.js

- It’s React-based: Almost everyone knows how to do React these days

- It allows me to build and serve chunked static files, instead of just a single static files like classic SPA

The last part is the main reason for that over other React-based frameworks. While SSR is hot these days, I’m firmly in the camp of “less servers I need to operate is better” and almost have “needs to be servable via S3+CloudFront” as a hard requirement for Frontend stacks.