|
| ▲ | magicalist 4 hours ago | parent | next [-] |
| > That doesn't hold anymore? AI doesn't care how hard or easy a migration is if a test suite exists. Sure, but that only matters if migration is going to be the last thing anyone does on a project. Unless you think typescript 7.1 ought to be enough for anybody, it also matters what the typescript team wants to write/read/reason in. |
| |
|
| ▲ | platinumrad 3 hours ago | parent | prev | next [-] |
| I just vibecofed tsasm. tsrs is obsolete now and anyone who still uses it is hopelessly behind the times. The tsrs team should delete the repository immediately and join my project. |
| |
| ▲ | written-beyond an hour ago | parent | next [-] | | Too late I just shipped tsvhdl so you have a hardware implementation of the actual TS compiler. Why steal valuable CPU cycles from agent workflows, off load all transpilation and type checking to a dedicated TSC chip. | |
| ▲ | cute_boi an hour ago | parent | prev [-] | | I am okay if agents can write code that is very safe in ASM. I am sure code written in Rust are naturally safe compared to asm or c. Waiting for tsasm to be significantly faster and safer than tsrs. |
|
|
| ▲ | wavemode 4 hours ago | parent | prev | next [-] |
| Your answer is within the comment you wrote. AI is maintaining tsrs whereas humans are maintaining tsgo. Your question boils down to "why would humans maintain something?" which could have a variety of answers depending on context. |
| |
| ▲ | 4 hours ago | parent | next [-] | | [deleted] | |
| ▲ | greenavocado 4 hours ago | parent | prev [-] | | No, the question is now: "How much human mental momentum, ego, and investment is there in and behind any particular project or its forks?" | | |
| ▲ | stephbook 3 hours ago | parent [-] | | I for one would be demotivated. Why maintain an official compiler that's not even half as fast as the vibe-coded one? "Just" publish the language specs and be done. | | |
| ▲ | Rapzid an hour ago | parent | next [-] | | These ports are borrowing large parts of the architecture, algorithms, and data structures from the official implementation. I don't think a spec would facilitate them at such a low effort level and cost. | |
| ▲ | greenavocado an hour ago | parent | prev [-] | | > Why maintain an official compiler that's not even half as fast as the vibe-coded one? Because at the end of the day, someone has to actually care and put in effort, even if the thing is machine generated, because it can go off the rails. |
|
|
|
|
| ▲ | melodyogonna 3 hours ago | parent | prev | next [-] |
| I never understand why people say things like this. It is not uncommon for languages to have multiple implementations, everything must not be abandoned for Rust man. |
|
| ▲ | fallingbananna 3 hours ago | parent | prev | next [-] |
| Because TSGO is stable and compatible? I assume that most of the speedup in ts-rs does not simply stem from using a language without garbage collection, but actually from doing smart optimizations that can be done in any langauge. Similar to how uv in the Python world explained that their implementation being in Rust has very little to do with the most impactful speedups they did. |
| |
|
| ▲ | skybrian 34 minutes ago | parent | prev | next [-] |
| Another advantage of AI, though, is that it becomes easier to maintain more than one TypeScript compiler. Perhaps there's some benefits to having some diversity? |
|
| ▲ | pier25 4 hours ago | parent | prev [-] |
| TSGO is already plenty fast and overkill for most projects. Sure the Rust version is faster but the difference is probably only noticeable in the top 1% largest projects. |
| |
| ▲ | theappsecguy 4 hours ago | parent | next [-] | | Fast is one thing, TSGO is fast enough I think, but my god does it suck up memory | |
| ▲ | alain_gilbert 4 hours ago | parent | prev [-] | | I'm always mind-blown when I read stuff like "speed is overkill". Speechless! | | |
| ▲ | pier25 3 hours ago | parent [-] | | do you go to the supermarket with an F1 car? | | |
| ▲ | tialaramex 6 minutes ago | parent | next [-] | | I walk to the supermarket. I'm pretty sure an F1 car would be noticeably slower. On foot I cross the little residential street where I live, walk to the corner, cross the busier road using a Zebra that was installed by thoughtful "pedestrian first" local government, then walk to the next corner where the main entrance to the supermarket is. In the F1 car lets assume somebody already pre-warmed it and so it's ready to go (F1 cars do not "just work" like your family car because that's not required in the F1 rules) I walk to the car park and get in, I need to accelerate quite hard to get the slippery F1 car up the steep drive, but then brake hard to stop and have somebody else check both ways since an F1 car isn't equipped for this in a side street. Now I pull out, takes no time to reach that street where pedestrian me crossed but I can't use that route in a car, so, go through another residential area, turn onto an old main road, turn again, to a roundabout, go into the underground carpark of the supermarket. Once I've parked I'm about as close to the front door as if I were walking from the Zebra. Huh. | |
| ▲ | AnnikaL 20 minutes ago | parent | prev | next [-] | | If you are travelling a long distance, say over 1000 miles/km, do you always drive? Or do you take an airplane (or a train)? | |
| ▲ | wiseowise an hour ago | parent | prev | next [-] | | No, but I sure wouldn’t mind if I opened my fridge and the food was already there. | |
| ▲ | suriyaG 2 hours ago | parent | prev | next [-] | | the cost between an F1 car and a "regular" car is high, both financially and functionally. but tsrs and tsgo are not a similar comparison. they cost the same (you download a binary and run it) and are functionally identical. in that case why would you not use the faster & better one? the question should be, do you always want your groceries 50% faster ? | |
| ▲ | sophacles 44 minutes ago | parent | prev | next [-] | | Bad comparrison. The less time my computer spends doing things the less battery I use. An F1 car goes faster but also uses more fuel to do so. Any one tool being a bit faster doesn't make my batter last noticeably longer, but defaulting to using the efficient tooling gets me results I can see. | |
| ▲ | alain_gilbert 3 hours ago | parent | prev [-] | | Do you usually dig up your garden by hand with a shovel, or do you use a rototiller? | | |
| ▲ | pier25 3 hours ago | parent | next [-] | | Now we're getting somewhere. This is a great example because obviously speed depends on the context. Obviously a shovel is quite an improvement for home gardeners but big constructions need a completely different tool. For +99% of TS projects going from eg 10ms to 1ms is not going to make any difference even though it's a 10x improvement. In part because most monitors refresh at 60hz (16ms per frame) but even with +120hz monitors this is not going to have an impact on any workflow. Even for CI network latency is going to be a much bigger factor than improving TS compilation beyond the performance that TSGO already provides. | | |
| ▲ | eyelidlessness 2 hours ago | parent [-] | | I think it might have more meaningful impact on high volume use cases, i.e. where cumulative run time is still significant. That’s already meaningful for at least a couple of companies I’ve seen investing in these ports. It might be niche for individual dev workflows now, but as those evolve it could become less niche (albeit probably still less uniform). |
| |
| ▲ | seanw444 3 hours ago | parent | prev [-] | | Do you dig your garden with an excavator? | | |
| ▲ | wiseowise an hour ago | parent | next [-] | | Why are bringing Java into this? | |
| ▲ | Tadpole9181 2 hours ago | parent | prev [-] | | I mean... If I had an excavator it beats using a shovel? This is such a silly "gotcha" analogy because the only reason I wouldn't is cost. And cost is not a reason for tsgo to be slower? "Would you rather have worse software for literally no benefit?" We should aim to make software as performant, bug free, feature-complete, and maintainable as is cost effective. It's asinine to argue that software shouldn't be fast, not because of some trade off, but just because someone doesn't need it to be fast for small tasks. Which, mind you, isn't even the case here. Thousands of businesses use typescript for millions of lines of code. Performance gains can mean tens of thousands of dollars in compute or hardware or time; tons of carbon saved from being emitted. | | |
| ▲ | afiori 2 hours ago | parent | next [-] | | Yep cost is the reason, allegedly the ts team found go a better language for a port and both using a less ergonomic language and switching target every six months have associated costs | | |
| ▲ | Tadpole9181 an hour ago | parent [-] | | And that's a fine argument to make! But this stupid garden analogy is nonsense. |
| |
| ▲ | 2 hours ago | parent | prev [-] | | [deleted] |
|
|
|
|
|
|