I recently read a great article exploring what would change if they were to switch from processes to threads for each connection. Running a connection pooler didn't seem so bad to me after reading it. https://medium.com/@tusharmalhotra_81114/why-postgresql-choo...
FWIW, there actually are some ongoing efforts towards that - including several preparatory changes in PG 18. Still lots more work, but we are working towards it.
Do you know, how well pgbouncer works with prepared statement nowadays? We slowly migrating our clusters to pg16/new bouncer and feel unsure on stability and reliability of prepared statements support
Maybe once all of this is a bit more mature we can just get down to the minimal subset of features that are really important.
I’d love a nvim plugin that is more or less just a split chat window that makes it easy to paste code I’ve yanked (like yank to chat) add my commentary and maybe easily attach other files for context. That’s it really.
I can highly recommend gp.nvim, it has a few features but by default it's just a chat window with a yank-to-chat function. It also supports a context file that gets pasted into every chat automatically (for telling the AI about the tools you use etc)
Thanks for sharing this! Like many others, we're at a scale where we use postgres for almost everything to reduce operational overhead, and there are some ETL,log and audit tables that would love a 30% speed bump for such a small risk window.
The post title is a bit misleading. It should say a 10x faster build time, or a 10x faster TypeScript compiler. tsc (compiler) is 10x faster, but not the final TS program runtime. Still an amazing feat! But doom will not run faster
"To meet those goals, we’ve begun work on a native port of the TypeScript compiler and tools. The native implementation will drastically improve editor startup, reduce most build times by 10x, and substantially reduce memory usage."
To clarify why it's actually not that ambiguous: TS is not (and does not have) a runtime at all. Even TS-first runtimes like Deno are (1) not TS but its own thing and most importantly (2) just JS engines with a frontend layer that treats TS as a first-class citizen (in Deno's case, V8).
It's hard to tell if there will even be a runtime that somehow uses TS types to optimize even further (e.g. by proving that a function diverges) but to my knowledge they currently don't and I don't think there's any in the works (or if that's even possible while maintaining runtime soundness, considering you can "lie" to TS by casting to `unknown` and then back to any other type).
“faster typescript” would also be a valid way to say the typescript compiler found a way to automatically write more performant javascript.
Just like if you said faster C++ that could mean the compiler runs faster, or the resulting machine code runs faster.
Just because the compile target is another human readable language doesn’t mean it ceases to be a typescript program.
I didn’t think this particular example was very ambiguous because a general 10x speed up in the resulting JS would be insane, and I have used typescript enough to wish the compiler was faster. Though if we’re being pedantic, which I enjoy doing sometimes, I would say it is ambiguous.
> “faster typescript” would also be a valid way to say the typescript compiler found a way to automatically write more performant javascript.
That still wouldn't make sense, in the same way that it wouldn't make sense to say "Python type hints found a way to automatically write more performant Python". With few exceptions, the TypeScript compiler doesn't have any runtime impact at all — it simply removes the type annotations, leaving behind valid JavaScript that already existed as source code. In fact, avoiding runtime impact is an explicit design goal of TypeScript [1].
They've even begun to chip away at the exceptions with the `erasableSyntaxOnly` flag [2], which disables features like enums that do emit code with runtime semantics.
But typescript isn't a minifier or an optimizer. No part of typescript compiles it to anything that looks significantly different (besides enums).
Sure, lots of build tools do this, but that's not Typescript.
With very few exceptions, Typescript is written so that removing the Typescript-specific things makes it equivalent to the Javascript it transpiles to.
Thanks for the clarification. For those of us who don't use TypeScript day to day, I feel that it is ambigious. Without clicking the link, you wouldn't know if it's about a compiler or a runtime. What if they announced a bun competitor?
Those are javascript runtimes, not TypeScript runtimes. The point stands.
If you don't know enough about TypeScript to understand that TypeScript is not a runtime, I'm not sure why you would care about TypeScript being faster (in either case).
that's not the point I was making - gp was wondering why someone who didn't even know typescript compiled to javascript and ran atop a javascript engine would care that it had gotten 10x faster.
From the title, my initial assumption was someone wrote a compiler & runtime for typescript that doesn't target javascript, which was very exciting. And I do work with typescript.
It has become a sport here to criticize titles for not explaining any random thing the commenter doesn't know. Generally these things are either in the article or they are very easily findable with a single web search.
It was ambiguous to me. I've used TS a few times over the years, so I thought "native TypeScript compiler" meant AOT TS, not a TS compiler written in Go
there is static hermes from Meta that do AoT compilation to native so I find it actually ambiguous. For a second I thought they did a compiler instead of transpile r.
I don't think this is misleading for anyone familiar with Typescript. Typescript itself has no impact on performance, and it is known that the compilation and type-checking speed is often a problem. So I immediately assumed that it was about exactly that.
When I read the title I thought maybe they implemented a typescript to binary (instead of javascript) code compiler that speeds up the program by 10x, it would also have the added benefit of speeding up the compiler by 10x!
I don't think that is too far fetched either since typescript already has most of the type information.
For anyone who uses TypeScript on a daily basis it's not ambiguous at all. Everyone who works with TS knows the runtime code is JavaScript code that is generated by the TypeScript compiler. And it's also pretty common knowledge that JavaScript is quite fast, but TS itself is not.
I don't think it's misleading at all, because you can't run Typescript. Typescript is either compiled, transpiled or stripped down into another language and that's what gets run in the end.
You can't run Java either as it's compiled to bytecode, yet when someone says "we made Java 10x faster" you wouldn't assume that just the compilation got faster, right? When people market Rust projects as blazingly fast nobody assumes it's about compilation, in part because a blazingly fast Rust compiler would be a miracle. Outside of this comment section people have always been using a programming language name for this because everyone knows what they mean.
It would be possible that MS wrote a TypeScript compiler that emits native binaries and that made the language 10x faster, why not?
You could make the same argument of anything but bytecode and even then some would debate if it's really running directly enough on modern CPUs. In the end it still remains that you have the time it takes to build your project in a given language and the runtime performance of the end result. Those remain very useful distinctions regardless of how many layers of indirection occur between source code and execution.
The difference here is that with Typescript, you're not really measuring Typescript's performance, but whatever your output language is. If transpile to Javascript, you're measuring that, if you output Wasm, you measure that, etc, and the result isn't really dictated by Typescript.
Transpiling isn't the only possibility to run TypeScript code, it's just the way to do it right now. A long time ago interpreting was the most common way to run JavaScript, now it's to JIT it, but you can also compile it straight to platform byte code or transpile it to C if you really want. That you could transpile JavaScript to C doesn't mean all ways of doing it would be equally performant though.
Transpiling in itself also doesn't remove the possibility of producing more optimized code, especially if the source has more information about the types. The official TypeScript compiler doesn't really do any of that right now (e.g. it won't remove a branch about how to handle a variable if its type equals a number even if it has the type information to know it can't have been set to one). Heck, it doesn't even (natively, you can always bolt this on yourself) support producing minified transpiled code to improve runtime parsing! In both examples it's not because transpilation prevents optimization though, it's just not done (or possibly worthwhile if TS only ever targets JS runtimes as JS JIT is extraordinarily good these days).
Not really in the case of TypeScript, because (with very small exceptions) when you “compile” TypeScript you are literally just removing the TypeScript, leaving plain JavaScript. It’s just type annotations; it doesn’t describe any runtime behavior at all.
That depends on both the target and the typescript features you use. In many cases, even when down leveling isn't involved, transpiled code can result in more than just stripping type info (particularly common in classes or things with helper functions). There's also nothing stopping a typescript compiler from optimizing transpiled (or directly compiled) code like any other compiler would, though the default typescript tools don't really go after any of that (or even produce a minified version itself using the additional type hints).
Agreed, at least usually right now (it doesn't have to be forever, which would probably be the most realistic way for TypeScript to make meaningful runtime gains). That does not preclude the possibility of producing more optimal JavaScript code for the runtime to consume. I give a couple examples of that in the other comments.
This seems pedantic. As a TypeScript user who is aware of the conversations about build performance, the title is not ambiguous at all. I know exactly they are talking about build time.
It was ambiguous to me. When someone says making a language X-times faster, it's natural to think about runtime performance, not compile times. I know TS runs on JS runtimes, but I assumed, based on the title, they created/modified a JS runtime to natively run TS fast.
look, not to argue with a stranger on hacker news, lol, but genuine calm question here: is this really a helpful nit? I know what you're getting at but the blogpost itself doesn't imply that JavaScript is 10x faster. I could complain, about your suggested change, that it's really `build and typecheck` time. It's a title. Sometimes they don't have _all_ the context. That's ok.
It is for me. If someone says TypeScript is faster than X, they rarely mean the build time. I understand other people's points about TypeScript not being a runtime at all and only being a compiler, but when casually saying "TypeScript is faster than say ruby", people do not mean the compiler.
But no one actually says "TypeScript is faster than say ruby". They probably say "node is faster than say ruby" or maybe "bun is faster than say ruby". Perhaps they say "JavaScript is faster than say ruby", although even that is underspecified.
Then read the article? I don't get it - Typescript, to anyone familiar, is not a language runtime. It does not optimize. It is a transpiler. If you don't even know this much about Typescript, you aren't the audience and lack prerequisite knowledge. Go read anything on the topic.
If someone posted an article talking about the "handedness" of DNA or something, I wouldn't complain "oh, you confused me, I thought you were saying DNA has hands!"
well, thanks for explaining. we might just simply disagree here. when I hear "TypeScript" I think of TypeScript, and when I hear "JavaScript" I think of JavaScript. I know what you mean re: casually speaking, but this is a blogpost from the TypeScript team. That context is there, too. I think if the same title were from an AWS release note, I'd totally see what you mean.
Typescript is JavaScript at runtime. It’s not a separate language, just like Python with type annotations (TypePython?) is just Python at runtime. Both are just type annotations that get stripped away before anything tries to run the code. That’s the genius of the idea and why it’s so easily adopted.
It is quite literally a separate language. Python's type hints are a part of the Python specification and all valid Python type hints will run in any compliant Python runtime. Typescript is not, in any way, valid JavaScript. The moment you add any type syntax, you can no longer run the code in Node or Browsers without enabling a special preprocess step.
I agree with pseudopersonal in that the title should be changed. technically it's not misleading, but not everyone uses or is familiar with typescript.
The explanations are of course correct, but I think you're right and there's not much downside to being clearer in the title. Maybe they decided against saying "compiler" because the performance boost also covers the language server.
Is there a contradiction? I'm not aware about Rust or C# REPLs (a lot of results comes up, but no clue how serious are those), but GHCi surely proves that you can have both.
I've seen comments like this a few times, and I think there's a misunderstanding at play. I think people who are used to using REPLs look at people who aren't and conclude that, since they don't have a REPL in their toolbox, they don't have a tool in there that does what a REPL does. But I think most of the time, they are accomplishing the same tasks with a different workflow.
For instance, I use throwaway files instead of REPLs, even when I have access to one. I'm still running small and isolated experiments to build my understanding, but I get to use the editor I'm comfortable with and it's easy to copy the code into my project afterwards.
The other thing I used to use REPLs for was introspection/looking up documentation, which my LSP handles nicely. You can think of the LSP as a sort of REPL integrated seamlessly into the editor; when I have a question, I'll query the LSP by writing a line of dummy code that causes the LSP to generate an annotation with the answer. So for instance if I want to know if `foo` implements a certain trait/interface, I can write a variable declaration like `let x: Box<dyn MyTrait> = Box::new(foo)` and see if my LSP annotated that as a type error. I can do this very quickly and without leaving my editor, so it helps me stay in the flow of things.
Yet another successful loser who somehow continues to ascend corporate ranks despite poor company performance. Just shows how disconnected job performance is from C-suite peer reviews, a glorified popularity contest. Should add the unity and better.com folk here
How do egregiously failed execs continue to get funding and high profile gigs? It's not just with Humane. I've seen this with the Better.com founder, his second failure after UNCLE, and with execs from MSFT Xbox. I can't for the life of me understand how they continue to get opportunities.
The skills required to become an exec are a lot of pitching yourself and networking to the right person to get your next job.
Those skills are only slightly correlated with how good you actually are as an exec.
Add to this that most companies don't like to take risks and will only hire an exec that has already be an exec somewhere else. To some level, once you make it through the exec glass ceiling, you are almost always guaranteed to always be an exec somewhere.
You see this all over the place by the way. I have seen the same thing for Directors, Principal engineers etc. Those people were not always that good at their job to justify their positions. But they for sure knew how to market themselves and interview well.
>The skills required to become an exec are a lot of pitching yourself and networking to the right person to get your next job. Those skills are only slightly correlated with how good you actually are as an exec.
source?
large corporations harnessing and deploying massive resources have led to air travel, skyscrapers, cell phones, MRI machines, medicines, the green revolution, etc. all things that require undertaking risk, but of course effectively managing it. Your claim is that skills don't matter to claim leadership positions in such organizations, only self promotion. OK, let's say that's true: the system sure seems to be working. And of course, people who think they have a better way are free to pursue that avenue... maybe some of the most successful companies in the world have pursued just such avenues.
Almost every economic system in history has had some impressive wins, but that doesn't mean that they are all perfectly efficient. Modern corporate capitalism isn't the worst system ever but that doesn't mean there aren't massive flaws and blindspots.
Becoming a large company CEO is highly correlated with who a person has spent time around. If it were a true meritocracy you would expect a roughly even distribution across regions and backgrounds, which is very much not the case.
If you ever work in a large corporation I can almost guarantee that you will encounter managers who are much better at networking and marketing themselves than they are at doing productive work.
Hypothesis: most VCs have a hive mentality and would prefer betting on low risk founders through their network of "highly accomplished" individuals: usually white males - false aura of achievement, survivorship and in-group bias, Matthew effect.
In-group membership tends to be sticky. People can stay in a tribe even when their qualifications in someone outside of the tribe would be insufficient to let them in.
I imagine that's partially driven by a feeling that one's previous qualifications lend some predictive power that they will earn their place again in the future even if right now they're foundering. Also, I suspect a lot of it is that people don't want to be in groups where it's too easy to get kicked out because it makes themselves feel to tenuous. So the kinds of in-groups that stick around are the ones that are a little more generous to their members once they get in.
> Infactory has thus raised a pre-seed, though its founders declined to confirm the amount or investors. Seed funding will be a focus for the next “six to 18 months,” per Hartley Moy.
A pre-seed round with anonymous investors doesn't mean much. It can be as simple as friends or even themselves.
