emrox's blurblog

Announcing TypeScript 7.0 Beta by Daniel Rosenwasser
Wednesday April 22^nd, 2026 at 5:58 AM

TypeScript

Today we are absolutely thrilled to announce the release of TypeScript 7.0 Beta!

If you haven’t been following TypeScript 7.0’s development, this release is significant in that it is built on a completely new foundation. Over the past year, we have been porting the existing TypeScript codebase from TypeScript (as a bootstrapped codebase that compiles to JavaScript) over to Go. With a combination of native code speed and shared memory parallelism, TypeScript 7.0 is often about 10 times faster than TypeScript 6.0.

Don’t let the “beta” label fool you – you can probably start using this in your day-to-day work immediately. The new Go codebase was methodically ported from our existing implementation rather than rewritten from scratch, and its type-checking logic is structurally identical to TypeScript 6.0. This architectural parity ensures the compiler continues to enforce the exact same semantics you already rely on. TypeScript 7.0 has been evaluated against the enormous test suite we’ve built up over the span of a decade, and is already in use in multiple multi-million line-of-code codebases both inside and outside Microsoft. It is highly stable, highly compatible, and ready to be put to the test in your daily workflows and CI pipelines today.

For over a year we’ve been working with many internal Microsoft teams, along with teams at companies like Bloomberg, Canva, Figma, Google, Lattice, Linear, Miro, Notion, Slack, Vanta, Vercel, VoidZero, and more to try out pre-release builds of TypeScript 7.0 on their codebases. The feedback has been overwhelmingly positive, with many teams reporting similar speedups, shaving off a majority of their build times, and enjoying a much more lightweight and fluid editing experience. In turn, we feel confident that the beta is in great shape, and we can’t wait for you to try it out soon.

Using TypeScript 7.0 Beta

To get TypeScript 7.0 Beta, you can install it via npm:

npm install -D @typescript/native-preview@beta

Note: the package name will eventually be typescript in a future release.

From there, you can run tsgo in place of the tsc executable.

> npx tsgo --version
Version 7.0.0-beta

The tsgo executable has the same behavior on all TypeScript code as tsc from TypeScript 6.0 – just much faster.

To try out the editing experience, you can install the TypeScript Native Preview extension for VS Code. The editor support is rock-solid, and has been widely used by many teams for months now. It’s an easy low-friction way to try TypeScript 7.0 out on your codebase immediately. It uses the same foundation as the command line experience, so you get the same performance improvements in your editor as you do on the command line. Notably, it’s also built on the language server protocol, making it easy to run in most modern editors or even tools like Copilot CLI.

Running Side-by-Side with TypeScript 6.0

To help you transition from TypeScript 6.0 to TypeScript 7.0, this beta release is available through the @typescript/native-preview package name using the tsgo entry point. This enables easy validation and comparison between tsc and tsgo.

However, as we mentioned above, the stable release of TypeScript 7.0 will be published under the typescript package and will use the tsc entry point.

Additionally, even though 7.0 Beta is close to production-ready, we won’t have a stable programmatic API available until at least several months from now with TypeScript 7.1. Given this, we have made it a priority to ensure TypeScript can be run side-by-side with TypeScript 6.0 for the foreseeable future without any conflicts around “which tsc is which?”

As part of the 6.0/7.0 transition process, we’ve published a new compatibility package, @typescript/typescript6. This package exposes a new entry point tsc6, so that (if needed) you can run the next release of TypeScript 7.0 (which will provide a tsc binary) side-by-side without naming conflicts. It will also re-export the TypeScript 6.0 API, so that you can use tsc for TypeScript 7, while other tooling can continue to rely on 6.0.

Because some tools like typescript-eslint expect to import from typescript directly via peer dependencies, we recommend achieving this via npm aliases. You should be able to run the following command

npm install -D typescript@npm:@typescript/typescript6

or modify your package.json as follows:

{
  "devDependencies": {
    "typescript": "npm:@typescript/typescript6@^6.0.0",
  }
}

In the future we will have more specific guidance for using a TS7-powered tsc alongside a TS6-powered tsc6.

Parallelization and Controls

TypeScript 7.0 now performs many steps in parallel, including parsing, type-checking, and emitting. Some of these steps, like parsing and emitting can mostly be done independently across files. As such, parallelization automatically scales well with larger codebases with relatively little overhead. But not every step in a TypeScript build is easily parallelizable.

Checker Parallelization

Other steps, like type-checking, have more complex dependencies across files. Most files end up relying on the same type information from their dependencies and the global scope, and so running type-checkers completely independently would be wasteful – both in computation and memory. On the other hand, type-checking occasionally relies on the relative ordering of information in a program, and so type-checking from scratch must always check the same files in an identical order to ensure the same results.

To enable parallelization while avoiding these pitfalls, TypeScript 7.0 creates a fixed number of type-checker workers with their own view of the world. These type-checking workers may end up duplicating some common work, but given the same input files, they will always divide them identically and produce the same results.

The default number of type-checking workers is 4, but it can be configured with the new --checkers flag. You may find that increasing this number can further speed up builds on larger codebases where typical machines have more CPU cores, but will typically come at the cost of increased memory usage. Likewise, machines with fewer CPU cores (e.g. CI runners) may want to decrease this number to avoid unnecessary overhead.

In rare cases, varying the number of --checkers may surface order-dependent results. Specifying a fixed number of checkers across your team can help ensure everyone is getting the same results, but is up to the discretion of each team.

Project Reference Builder Parallelization

TypeScript 7.0 can parallelize builds within a project, but it can now also build multiple projects at once as well. This behavior can be configured with the new --builders flag, which controls the number of parallel project reference builders that can run at once. This can be particularly helpful for monorepos with many projects.

Like --checkers, increasing the number of builders can speed up builds, but may come at the cost of increased memory usage. It also has a multiplicative effect with --checkers, so it’s important to find the right balance for your machine and codebase. For example, building with --checkers 4 --builders 4 allows up to 16 type-checkers to run at once, which may be excessive.

Unlike --checkers, varying the number of builders should not produce different results; however, building project references is fundamentally bottlenecked by the dependency graph of projects (with the exception of type-checking on codebases that leverage --isolatedDeclarations and separate syntactic declaration file emit).

Single-Threaded Mode

In some cases, it can be helpful to enforce single-threaded operation throughout the compiler. This may be useful for debugging, comparing performance with TypeScript 6 and 7, when orchestrating parallel builds externally, or for running in environments with very limited resources. To enable single-threaded mode, you can use the new --singleThreaded flag. This will not only cap the number of type-checking workers to 1, but also ensure parsing and emitting are done in a single thread.

Updates Since 5.x, and New Behaviors from 6.0

TypeScript 7.0 is made to be compatible with TypeScript 6.0’s type-checking and command-line behavior. Any TypeScript code that compiles cleanly with TypeScript 6.0 (with the stableTypeOrdering flag on, and without the ignoreDeprecations flag set) should compile identically in TypeScript 7.0.

With that said, TypeScript 7.0 adopts 6.0’s new defaults, and provides hard errors in the face of any flags and constructs deprecated in TypeScript 6.0. This is notable as 6.0 is still relatively new, and many projects will need to adapt to its new behaviors. We encourage developers to adopt TypeScript 6.0 to make the transition to TypeScript 7.0 easier, and you can also read the TypeScript 6.0 release blog post for more details on these deprecations.

At a glance, the notable default changes to configuration are:

strict is true by default.
module defaults to esnext.
target defaults to the current stable ECMAScript version immediately preceding esnext.
noUncheckedSideEffectImports is true by default.
libReplacement is false by default.
stableTypeOrdering is true by default, and cannot be turned off.
rootDir now defaults to ./, and inner source directories must be explicitly set.
types now defaults to [], and the old behavior can be restored by setting it to ["*"].

We believe the rootDir and types changes may be the most “surprising” changes, but they can be mitigated easily. Projects where the tsconfig.json sits outside of a directory like src will simply need to include rootDir to preserve the same directory structure.

  {
      "compilerOptions": {
          // ...
+         "rootDir": "./src"
      },
      "include": ["./src"]
  }

For the types change, projects that depend on specific global declarations will need to list them explicitly. For example,

  {
      "compilerOptions": {
          // Explicitly list the @types packages you need (e.g. bun, mocha, jasmine, etc.)
+         "types": ["node", "jest"]
      }
  }

The deprecations that have turned into hard errors with no-op behavior are:

target: es5 is no longer supported.
downlevelIteration is no longer supported.
moduleResolution: node/node10 are no longer supported, with nodenext and bundler being recommended instead.
module: amd, umd, systemjs, none are no longer supported, with esnext or preserve being recommended in conjunction with bundlers or browser-based module resolution.
baseUrl is no longer supported, and paths can be updated to be relative to the project root instead of baseUrl.
moduleResolution: classic is no longer supported, and bundler or nodenext are the recommended replacements.
esModuleInterop and allowSyntheticDefaultImports cannot be set to false.
alwaysStrict is assumed to be true and can no longer be set to false
The module keyword cannot be used in namespace declarations.
The asserts keyword cannot be used on imports, and must use the with keyword instead (to align with developments on ECMAScript’s import attribute syntax).
/// <reference no-default-lib /> directives are no longer respected under skipDefaultLibCheck.
Command line builds cannot take file paths when the current directory contains a tsconfig.json file unless passed an explicit --ignoreConfig flag.

JavaScript Differences

As we ported the existing codebase, we also took the opportunity to revisit how our JavaScript support works.

TypeScript originally supported JavaScript files by using JSDoc comments and recognizing certain code patterns for analysis and type inference. Lots of the time, this was based on popular coding patterns, but occasionally it was based on whatever people might be writing that Closure and the JSDoc doc generating tool might understand. While this approach was helpful for developers with loosely-written JSDoc codebases, it required a number of compromises and special cases to work well, and diverged in a number of ways from TypeScript’s analysis in .ts files.

In TypeScript 7.0, we have reworked our JavaScript support to be more consistent with how we analyze TypeScript files. Some of the differences include:

Values cannot be used where types are expected – instead, write typeof someValue
@enum is not specially recognized anymore – create a @typedef on (typeof YourEnumDeclaration)[keyof typeof YourEnumDeclaration].
A standalone ? is no longer usable as a type – use any instead.
@class does not make a function a constructor – use a class declaration instead.
Postfix ! is not supported – just use T.
Type names must be defined within a @typedef tag (i.e. /** @typedef {T} TypeAliasName */), not adjacent to an identifier (i.e. /** @typedef {T} */ TypeAliasName;).
Closure-style function syntax (e.g. function(string): void) is no longer supported – use TypeScript shorthands instead (e.g. (s: string) => void).

Additionally, some JavaScript patterns, like aliasing this and reassigning the entirety of a function’s prototype are no longer specially treated.

While some of our JS support is in flux, we have been updating this CHANGES.md file to capture the differences between TypeScript 6.0 and 7.0 in more detail.

Editor Experience

TypeScript 7.0’s performance improvements are not limited to the command line experience – they also extend to the editor experience too. The TypeScript Native Preview extension for VS Code provides a seamless way to try out TypeScript 7.0 in your editor, and has seen widespread use.

Since it first debuted, we’ve added in missing functionality like auto-imports, expandable hovers, inlay hints, code lenses, go-to-source-definition, JSX linked editing and tag completions, and more. Additionally, we’ve rebuilt much of our testing and diagnostics infrastructure to make sure the quality bar is high.

This extension respects most of the same configuration settings as the built-in TypeScript extension for Visual Studio Code, along with most of the same features. While a few things are still coming (like semantics-enhanced highlighting, more-specific import management commands, etc.), the extension is already powerful, stable, and fast.

Upcoming Work

In the coming weeks, we expect to ship a more efficient implementation of --watch, and meet parity on declaration file emit from JavaScript files. We will also be working on minor editor feature gaps like “find file references” from the file explorer, and surfacing the more granular “sort imports” and “remove unused imports” commands instead of just the more general “organize imports” command.

Beyond this, we’ll be developing a stable programmatic API for TypeScript 7.1 or later, improving our real-world testing infrastructure, and addressing feedback.

The Road to TypeScript 7.0

With TypeScript 7.0 Beta now available, the team is focusing on bug fixes, compatibility work, editor polish, and performance improvements as we move toward a stable release. Our current plan is to release TypeScript 7.0 within the next two months, with a release candidate available a few weeks prior. The release candidate will be the point where we expect TypeScript 7’s behavior to be finalized, with changes after that focused on critical fixes to regressions.

Between now and then, we would especially appreciate feedback from trying TypeScript 7.0 on real projects. If you run into any issues, please let us know on the issue tracker for microsoft/typescript-go so we can make sure the stable release is in great shape.

We also encourage you to share your experience using TypeScript 7.0 and tag @typescriptlang.org on Bluesky or @typescript@fosstodon.org on Mastodon, or @typescript on Twitter.

Our team is incredibly excited for you to try this release out, so try it today and let us know what you think. Happy hacking!

– The TypeScript Team

The post Announcing TypeScript 7.0 Beta appeared first on TypeScript.

Read the whole story

emrox

12 hours ago

Hamburg, Germany

alvinashcraft

1 day ago

Pennsylvania, USA

Drunk Post: Things I’ve Learned as a Senior Engineer
Wednesday April 22^nd, 2026 at 4:36 AM

https://transcendloneliness.substack.com/

A few years ago, a data engineer on r/ExperiencedDevs got drunk and wrote down everything he learned in 10 years of engineering. The original account is deleted, but the post captures something real — the kind of honesty you only get after a few glasses of wine. Preserving it here, typos and all.

Contains the language you’d expect from someone who opened with ‘I’m drunk’.

I’m drunk and I’ll probably regret this, but here’s a drunken rank of things I’ve learned as an engineer for the past 10 years.

The best way I’ve advanced my career is by changing companies.
Technology stacks don’t really matter because there are like 15 basic patterns of software engineering in my field that apply. I work in data so it’s not going to be the same as webdev or embedded. But all fields have about 10-20 core principles and the tech stack is just trying to make those things easier, so don’t fret overit.
There’s a reason why people recommend job hunting. If I’m unsatisfied at a job, it’s probably time to move on.
I’ve made some good, lifelong friends at companies I’ve worked with. I don’t need to make that a requirement of every place I work. I’ve been perfectly happy working at places where I didn’t form friendships with my coworkers and I’ve been unhappy at places where I made some great friends.
I’ve learned to be honest with my manager. Not too honest, but honest enough where I can be authentic at work. What’s the worse that can happen? He fire me? I’ll just pick up a new job in 2 weeks.
If I’m awaken at 2am from being on-call for more than once pesr quarter, then something is seriously wrong and I will either fix it or quit.

pour another glass

Qualities of a good manager share a lot of qualities of a good engineer.
When I first started, I was enamored with technology and programming and computer science. I’m over it.
Good code is code that can be understood by a junior engineer. Great code can be understood by a first year CS freshman. The best code is no code at all.
The most underrated skill to learn as an engineer is how to document. Fuck, someone please teach me how to write good documentation. Seriously, if there’s any recommendations, I’d seriously pay for a course (like probably a lot of money, maybe 1k for a course if it guaranteed that I could write good docs.)
Related to above, writing good proposals for changes is a great skill.
Almost every holy war out there (vim vs emacs, mac vs linux, whatever) doesn’t matter... except one. See below.
The older I get, the more I appreciate dynamic languages. Fuck, I said it. Fight me.
If I ever find myself thinking I’m the smartest person in the room, it’s time to leave.
I don’t know why full stack webdevs are paid so poorly. No really, they should be paid like half a mil a year just base salary. Fuck they have to understand both front end AND back end AND how different browsers work AND networking AND databases AND caching AND differences between web and mobile AND omg what the fuck there’s another framework out there that companies want to use? Seriously, why are webdevs paid so little.
We should hire more interns, they’re awesome. Those energetic little fucks with their ideas. Even better when they can question or criticize something. I love interns.

sip

Don’t meet your heroes. I paid 5k to take a course by one of my heroes. He’s a brilliant man, but at the end of it I realized that he’s making it up as he goes along like the rest of us.
Tech stack matters. OK I just said tech stack doesn’t matter, but hear me out. If you hear Python dev vs C++ dev, you think very different things, right? That’s because certain tools are really good at certain jobs. If you’re not sure what you want to do, just do Java. It’s a shitty programming language that’s good at almost everything.
The greatest programming language ever is lisp. I should learn lisp.
For beginners, the most lucrative programming language to learn is SQL. Fuck all other languages. If you know SQL and nothing else, you can make bank. Payroll specialtist? Maybe 50k. Payroll specialist who knows SQL? 90k. Average joe with organizational skills at big corp? $40k. Average joe with organization skills AND sql? Call yourself a PM and earn $150k.
Tests are important but TDD is a damn cult.
Cushy government jobs are not what they are cracked up to be, at least for early to mid-career engineers. Sure, $120k + bennies + pension sound great, but you’ll be selling your soul to work on esoteric proprietary technology. Much respect to government workers but seriously there’s a reason why the median age for engineers at those places is 50+. Advice does not apply to government contractors.
Third party recruiters are leeches. However, if you find a good one, seriously develop a good relationship with them. They can help bootstrap your career. How do you know if you have a good one? If they’ve been a third party recruiter for more than 3 years, they’re probably bad. The good ones typically become recruiters are large companies.
Options are worthless or can make you a millionaire. They’re probably worthless unless the headcount of engineering is more than 100. Then maybe they are worth something within this decade.
Work from home is the tits. But lack of whiteboarding sucks.
I’ve never worked at FAANG so I don’t know what I’m missing. But I’ve hired (and not hired) engineers from FAANGs and they don’t know what they’re doing either.
My self worth is not a function of or correlated with my total compensation. Capitalism is a poor way to determine self-worth.
Managers have less power than you think. Way less power. If you ever thing, why doesn’t Manager XYZ fire somebody, it’s because they can’t.
Titles mostly don’t matter. Principal Distinguished Staff Lead Engineer from Whatever Company, whatever. What did you do and what did you accomplish. That’s all people care about.
Speaking of titles: early in your career, title changes up are nice. Junior to Mid. Mid to Senior. Senior to Lead. Later in your career, title changes down are nice. That way, you can get the same compensation but then get an increase when you’re promoted. In other words, early in your career (<10 years), title changes UP are good because it lets you grow your skills and responsibilities. Later, title changes down are nice because it lets you grow your salary.
Max out our 401ks.
Be kind to everyone. Not because it’ll help your career (it will), but because being kind is rewarding by itself.
If I didn’t learn something from the junior engineer or intern this past month, I wasn’t paying attention.

Oops I’m out of wine.

Paying for classes, books, conferences is worth it. I’ve done a few conferences, a few 1.5k courses, many books, and a subscription. Worth it. This way, I can better pretend what I’m doing.
Seriously, why aren’t webdevs paid more? They know everything!!!
Carpal tunnel and back problems are no joke. Spend the 1k now on good equipment.
The smartest man I’ve every worked for was a Math PhD. I’ve learned so much from that guy. I hope he’s doing well.
Once, in high school, there was thing girl who was a great friend of mine. I mean we talked and hung out and shared a lot of personal stuff over a few years. Then there was a rumor that I liked her or that we were going out or whatever. She didn’t take that too well so she started to ignore me. That didn’t feel too good. I guess this would be the modern equivalent to “ghosting”. I don’t wish her any ill will though, and I hope she’s doing great. I’m sorry I didn’t handle that better.
I had a girlfriend in 8th grade that I didn’t want to break up with even though I didn’t like her anymore so I just started to ignore her. That was so fucked up. I’m sorry, Lena.
You know what the best part of being a software engineer is? You can meet and talk to people who think like you. Not necessarily the same interests like sports and TV shows and stuff. But they think about problems the same way you think of them. That’s pretty cool.
There’s not enough women in technology. What a fucked up industry. That needs to change. I’ve been trying to be more encouraging and helpful to the women engineers in our org, but I don’t know what else to do.
Same with black engineers. What the hell?
I’ve never really started hating a language or technology until I started becoming intimately familiar with it. Also, I think a piece of tech is good if I hate it but I simultaneously would recommend it to a client. Fuck Jenkins but man I don’t think I would be commuting software malpractice by recommending it to a new client.
That being said, git is awful and I have choice but to use it. Also, GUI git tools can go to hell, give me the command line any day. There’s like 7 command lines to memorize, everything else can be googled.
Since I work in data, I’m going to give a data-specific lessons learned. Fuck pandas.
My job is easier because I have semi-technical analysts on my team. Semi-technical because they know programming but not software engineering. This is a blessing because if something doesn’t make sense to them, it means that it was probably badly designed. I love the analysts on the team; they’ve helped me grow so much more than the most brilliant engineers.
Dark mode is great until you’re forced to use light mode (webpage or an unsupported app). That’s why I use light mode.
I know enough about security to know that I don’t know shit about security.

Crap I’m out of wine.

Being a good engineer means knowing best practices. Being a senior engineer means knowing when to break best practices.
If people are trying to assign blame to a bug or outage, it’s time to move on.
A lot of progressive companies, especially startups, talk about bringing your “authentic self”. Well what if your authentic self is all about watching porn? Yeah, it’s healthy to keep a barrier between your work and personal life.
I love drinking with my co-workers during happy hour. I’d rather spend time with kids, family, or friends.
The best demonstration of great leadership is when my leader took the fall for a mistake that was 100% my fault. You better believe I would’ve walked over fire for her.
On the same token, the best leaders I’ve been privileged to work under did their best to both advocate for my opinions and also explain to me other opinions that conflict with mine. I’m working hard to be like them.
Fuck side projects. If you love doing them, great! Even if I had the time to do side-projects, I’m too damn busy writing drunken posts on reddit
Algorithms and data strictures are important — to a point. I don’t see pharmacist interviews test trivia about organic chemistry. There’s something fucked with our industry’s interview process.
Damn, those devops guys and gals are f’ing smart. At least those mofos get paid though.
It’s not important to do what I like. It’s more important to do what I don’t hate.
The closer I am to the product, the closer I am to driving revnue, the more I feel valued regardless of how technical my work is. This has been true for even the most progressive companies.
Linux is important even when I was working in all Windows. Why? Because I eventually worked in Linux. So happy for those weekend where I screwed around installing Arch.
I’ve learned to be wary for ambiguous buzz words like big data. WTF is “big” data? I’ve dealt with 10k rows streaming every 10 minutes in Spark and Kafka and dealt with 1B rows batched up hourly in Python and MySQL. Those labels can go fuck themselves.
Not all great jobs are in Silicon Valley. But a lot are.

Oh shit I found beer: let’s keeping going.

I once hated a programming language (C#) until I started using it. Now I hated it but think it’s useful.
Then I started hating a programming language (C#) and left it and came back. Wow, that programming language has really improved.
The greatest thing about functional languages is that functions are first class and all other programmers know that.
No matter how great or superior a language is, it doesn’t matter if people don’t use it.
Learning a language isn’t hard. It’s learning the ecosystem.

Pair programming is great, it just takes a lot of time — time that the company usually doesn’t want to spend.
Working with smart engineers has made me a better coder. Working with smart non-technical co-workers has made me a better engineer.
Don’t spend time outside of the 9-5 working. Unless you want to because you got a banging project and you’re in the groove. That shit is awesome.
Happy hours and social hours across teams are 99% just chilling and getting to know coworkers. That’s cool. Every once in a while, the 1% is about a critical project with a critical piece of code and you’re glad you brought up work in a social setting because shit would’ve hit the fan otherwise. I’m not saying that I should hang out with other teams outside of work because of this. I just want to bond. But it sure as hell is a nice perk.

If the company is half remote and half on-site, it’s important to determine if the remote people aren’t treated as second-class citizens. If major decisions are made “at the water cooler”, then it’s better to try to change the company culture (hard) or move on to a different company that treats its remote employees as first class citizens.
The second worst major downside of working from home is no whiteboard.
The first major downside of working from home is that it’s hard to learn from coworkers. Unless I’m (a) confident and assertive to ask questions and (b) the company has a culture where remote workers are equivelent to on-site workers, I think it was best that I worked on-side for the first 5 years of my career.

Everyone knows that tech changes. The tech landscape of the past 10 years has changed dramatically. But fundamentals don’t change very much, especially fundamentals that apply to my field.
Hacker news and r/programming is only good to get general ideas and keep up-to-date. The comments are almost worthless.
There’s a lot of vocal amateurs with strong opinions about technology. Even amateurs published on “respectable” journals and blogs. I found it to keep abreast of the rumors but to figure things out for myself.
I work at a cutting edge startup and we don’t use the latest XYZ tech that was present at ABC cutting edge tech company. And it turn out, what they usually present is only a small percentage of their engineering department and that most of them are using the same tech we are.
That being said, it’s important to read the signs. If you want to work with modern tech and you’re company is still doing the majority of it’s development in jQuery, might be time to re-evauluate.

Fuck it I’m a data engineer so I might as well give more specific, target advice/experience
SQL is king. Databases like MySQL, Postgres, Oracle, SQL Server, SQLite is still supreme. Even if you work with new tech, most of it transfers anyway.
Most companies aren’t doing streaming. It’s hard and complicated. If you’re 10 years into your career and you don’t know how to work with 10k records per second, don’t worry about it, there’s still jobs out for you.
Airflow is shit, yes. There are other products out there, but fuck me if Airflow isn’t the most widely used.
Machine learning projects are highly prone to failure. They’re complicated and hard to implement. Don’t believe me? How easy is it to write fucking unit test a machine learning model? Yeah.
Our field is new. There’s no good book on data engineering, just go and “do it”. Can’t learn it through a bootcamp and shit. This will probably change in 10 years as we all figure out what the fuck we’re doing.

People die. Do you want your code to be your legacy? If yes, then spend a lot of time on it because that’s your fucking legacy and you go! But if you are like me, your legacy is surrounded with family, friends, and people in your life and not the code you write. So don’t get too hung up on it.
Good people write shitty code. Smart people write shitty code. Good coders and good engineers write shitty code. Don’t let code quality be a dependent variable on your self worth.
I got into tech and coding because tech was my hobby. Now my hobby is is the same as work and work has ruined my hobby. So now if I want to enjoy tech I need to quit my hobby. Or I need to be OK that tech is no longer my hobby and find new hobbies.
Programming and computer science is like, what, 80 years old? Compare that with any other engineering discipline. Yeah, we collectively don’t know what the fuck we’re doing.
I’m making pretty good money. Be grateful and appreciate. Also, save.

I’ve built large platforms and libraries that are used by multiple teams and people for many years. Yet for some reason, the most proud I was of the code I wrote was the small script that was used by me.
The proudest accomplishment of my career has been helping other people be better at their jobs. That’s probably because I’m destined to be a people manager, so this is probably not helpful to other people.
When I was looking for a job, I created an updated my Linkedin. I got shit replies and deleted it. Now I use Linkedin to find other candidates to join my company. Bottom line, Linkedin is a lot of noise. I only find it valuable because now, part of my job is contributing to that noise.
Once, I found out in college that a girl liked me. I didn’t believe it because I had poor self esteem, but then she asked me out. I told her I wasn’t interested even though she was really cool. That was one of the proudest moments in my life because I as mature enough at 19 to say “no” in a mature way.
r/cscareerquestions is such a cesspool of ego and misinformation that I don’t know what to do about it. Like, WTF. I want to shake all those people and try to explain to them how the world really is, but they wouldn’t believe me.

I’m drunk and I usually don’t drink, so I would think that everything I say is probably cringy or terrible
I feel strongly that people should save and invest money. If you have a 6 figure salary, do your best to max our your 401k please.
I’ve become what I’ve always hated: someone who works in tech in a career but avoid tech in real life. Maybe that comes with being old.
r/ExperiencedDevs is a pretty cool community. Thank you mods. You get way less appreciation than you deserve. Seriously, thank you.
I probably owe my career, my salary, my life to Reddit. Reddit gets a lot of shit but the communities here have lifted me out of poverty (working at a gas station earning min wage) to learning Linux, SQL, python, C#, Python, and others to get me where I am.
Kids are great. I don’t have kids by choice. Why? Because I love kids and I’m scared about what kind of father I would be. Oh shit, is that too personal for a post here?
Once, someone asked me who I looked up to and I said Conan O’Brien, and they laughed at me. But I was being serous because on his last show on the Tonight Show, he told his audience to be kind and work hard. It happend during a difficult period of my life, and when I watched him say that, I said, you know what, I’m going to do just that. Because what would I have to lose? And you know what? I’ve met some brilliant people who I’ve learned from over 10+ years because I was kind to them. And I’ve grown a lot by working hard and not being afraid to try new things. And my life is infinitely, infinitely better because of those words. So yes, it might seem silly and even ridiculous to say that I’ve achieved a level of fulfillment in my life because of a late night talk show. But you know what, fuck it, it’s my life and I will proudly say that I owe any success I’ve achieved because a fucking comic on late night television.

I’m highly intoxicated so please disregard anything I say. Also apologies for ranting.

I saved this because it’s one of the most honest things I’ve read about our industry. As a data engineer with 10+ years in, I agree with almost all of it — especially the parts about SQL being king, tech stacks not mattering as much as you think, and the best code being no code at all. The only thing I’d push back on is the dynamic languages take. But hey, the man was drunk.

Read the whole story

emrox

14 hours ago

Hamburg, Germany

The Bag of Tricks for View Transitions
Tuesday April 21^st, 2026 at 3:49 AM

@vtbag: The Bag of Tricks for View Transitions

The vtbag logo

Your browser does not support view transitions. For details visit the test page.

We honor your request for reduced motion. View transitions are switched off on this site.

Spark up a discussion on the Bag’s Discord or on 🦋 Bluesky! Hit the Discuss on 🦋 buttons to share your thoughts and please stay connected with The Bag and me for all the latest!

The Basics

Everything you ever wanted to know about the View Transition API, in one place. Explore what your browser is capable of and what is new in the API specification.

Dive into examples and see what holds the world of pseudo elements and their styling together at its core.

Tools & Libraries

As you dig deeper into View Transitions, you will quickly see how a little JavaScript here and there can unlock much more and make things even more fun.

You do not have to build everything yourself. The Bag provides battle tested libraries and tools that make working with View Transitions easier, more enjoyable, and practical for real projects.

Fun with View Transitions

A journey told in episodes, starting with simple use cases and moving toward more advanced applications.

Along the way, it covers basic setup, image morphing, fixing broken text transitions, and extended same page examples.

Tips & Tricks

What would a bag of tricks be without a few tips and tricks along the way? Everything here comes straight from real world practice, built for real world use.

I have stumbled through the rough edges, chased down the weird bugs, and made all the mistakes already, so you do not have to.

Tech Demos

Last but not least, it is all about “show, don’t tell”. New techniques are always easier to grasp when you can see them in action instead of just reading about them.

The Tech Demos section at the end of the navigation links to all the examples, and there are, if I may say so with a bit of modesty, a few real gems in there.

Read the whole story

emrox

1 day ago

Hamburg, Germany

Fructose: metabolic signal and modern hazard
Saturday April 18^th, 2026 at 3:51 PM

Nature Metabolism

Malik, V. S. & Hu, F. B. The role of sugar-sweetened beverages in the global epidemics of obesity and chronic diseases. Nat. Rev. Endocrinol. 18, 205–218 (2022).

Article PubMed PubMed Central Google Scholar

World Health Organization. Guideline: sugars intake for adults and children. WHO https://www.who.int/publications/i/item/9789241549028 (2015).

Yang, Q. et al. Added sugar intake and cardiovascular diseases mortality among US adults. JAMA Intern. Med. 174, 516–524 (2014).

Article CAS PubMed PubMed Central Google Scholar

Russell, C., Baker, P., Grimes, C., Lindberg, R. & Lawrence, M. A. Global trends in added sugars and non-nutritive sweetener use in the packaged food supply: drivers and implications for public health. Public Health Nutr. 26, 952–964 (2023).

Article PubMed Google Scholar

Magkos, F. et al. On the pathogenesis of obesity: causal models and missing pieces of the puzzle. Nat. Metab. 6, 1856–1865 (2024).

Article PubMed Google Scholar

Herman, M. A. & Birnbaum, M. J. Molecular aspects of fructose metabolism and metabolic disease. Cell Metab. 33, 2329–2354 (2021).

Article CAS PubMed PubMed Central Google Scholar

Woods, H. F. & Krebs, H. A. Lactate production in the perfused rat liver. Biochem. J. 125, 129–139 (1971).

Article CAS PubMed PubMed Central Google Scholar

Johnson, R. J. et al. The fructose survival hypothesis for obesity. Philos. Trans. R. Soc. Lond. B. Biol. Sci. 378, 20220230 (2023).

Article CAS PubMed PubMed Central Google Scholar

Diggle, C. P. et al. Ketohexokinase: expression and localization of the principal fructose-metabolizing enzyme. J. Histochem. Cytochem. 57, 763–774 (2009).

Article CAS PubMed PubMed Central Google Scholar

Li, Y. et al. Ketohexokinase-dependent metabolism of cerebral endogenous fructose in microglia drives diabetes-associated cognitive dysfunction. Exp. Mol. Med. 55, 2417–2432 (2023).

Article CAS PubMed PubMed Central Google Scholar

Helsley, R. N. et al. Tissue-specific fructose metabolism in obesity and diabetes. Curr. Diab. Rep. 20, 64 (2020).

Article CAS PubMed PubMed Central Google Scholar

Maenpaa, P. H., Raivio, K. O. & Kekomaki, M. P. Liver adenine nucleotides: fructose-induced depletion and its effect on protein synthesis. Science 161, 1253–1254 (1968).

Announcing TypeScript 7.0 Beta by Daniel Rosenwasser Wednesday April 22nd, 2026 at 5:58 AM

Using TypeScript 7.0 Beta

Running Side-by-Side with TypeScript 6.0

Parallelization and Controls

Checker Parallelization

Project Reference Builder Parallelization

Single-Threaded Mode

Updates Since 5.x, and New Behaviors from 6.0

JavaScript Differences

Editor Experience

Upcoming Work

The Road to TypeScript 7.0

Drunk Post: Things I’ve Learned as a Senior Engineer Wednesday April 22nd, 2026 at 4:36 AM

The Bag of Tricks for View Transitions Tuesday April 21st, 2026 at 3:49 AM

Your browser does not support view transitions. For details visit the test page.

We honor your request for reduced motion. View transitions are switched off on this site.

Fructose: metabolic signal and modern hazard Saturday April 18th, 2026 at 3:51 PM

The Physics Of GPS | An Interactive Exploration Sunday April 12th, 2026 at 3:29 PM

The Ruler

One Satellite, One Ring

Three Satellites, One Point

The Clock Problem

The Relativity Tax

A Joint Effort

Thank you!

Morale by Doug Tuesday March 24th, 2026 at 4:14 AM

Announcing TypeScript 7.0 Beta by Daniel Rosenwasser
Wednesday April 22^nd, 2026 at 5:58 AM

Drunk Post: Things I’ve Learned as a Senior Engineer
Wednesday April 22^nd, 2026 at 4:36 AM

The Bag of Tricks for View Transitions
Tuesday April 21^st, 2026 at 3:49 AM

Fructose: metabolic signal and modern hazard
Saturday April 18^th, 2026 at 3:51 PM

The Physics Of GPS | An Interactive Exploration
Sunday April 12^th, 2026 at 3:29 PM

Morale by Doug
Tuesday March 24^th, 2026 at 4:14 AM