761–770 of 943 posts
For previous attempts at a faster tsc, but in rust, see: 1. https://github.com/dudykr/stc - Abandoned ( https://github.com/swc-project/swc/issues/571#issuecomment-1... ) 2. https://github.com/kaleidawave/ezno - In active development. Does not have the goal of 1:1 parity to tsc.
I think Deno and Bun are the two successful attempts at a faster tsc :)
Earlier quoted context omitted.
Doubt is human, but it isn’t always warranted. In C++ can use a concurrent, completely pause‐free garbage collector, where the programmer decides which data is managed by the GC. This enables code optimizations in ways that aren’t possible in C# and Java.
You realize that is literally not the same thing? I said equivalent code. The whole reason of using a managed language with GC is to not think about those things because they eat up thought and development time. Of course the language that will let you hand optimize every little line will eventually be more performant. I really think you’re discounting both C#’s ability to do those things and just how good Java’s GCs…
Earlier quoted context omitted.
I'm not denying the facts of the matter, I am denying the conclusion. The circumstances of the situation are relevant. Marshalling cost across IPC boundaries come into play in every single possible situation regardless of language. It is why shared memory architectures exist. It doesn't matter what language is on the other side of the IPC, if the performance gained by using a separate process is not greater than the…
The fact that many software products are moving to lower-level languages is not a general point in favour of lower-level languages being somehow better—rather, it simply aligns with general directions of software evolution. 1. As products mature, they may find useful scenarios involving runtime environments that don’t necessarily match the ones that were in mind back when the foundation was laid. If relevant parts ar…
Of course, LLMs may stay as "autocomplete" forever. Or for decades. But my intuition is telling me that in the next 2-3 years they are going to increase in capability, especially for coding, at a pace greater than the last 2 years. The evidence that I have (by actually using them) seems to point in that direction.
I'm perfectly capable of writing programs in Perl, Python, JavaScript, C++, PHP, Java. Each of those languages (and more actually) I have used professionally in the past. I am confident I could write a perfectly good app in Go, Rust, Elixir, C, Ruby, Swift, Scala, etc.
If you asked me 6 months ago "what would you choose to write a basic CRUD web app" I probably would have said TypeScript. What I am questioning now is: why? What would lead me to choose TypeScript? Do the reasons I would have chosen TypeScript continue to make sense today?
There are no genies here, only questioning of assumptions. And my new assumptions include the assumption that any coding I would do will involve a code assisting LLM. That opens up new possibilities for me. Given LLM assistance, why wouldn't I write my web app layer in Rust or Zig?
Your assumptions about the present and near future will guide your own decisions. If you don't share the same intuitions you will come to different conclusions.
Earlier quoted context omitted.
> Pity that they didn't go with AOT compiled .NET, though. Yeah. It seems to be unfashionable somewhat even within Microsoft. (edit: it seems to be you and me and barely anyone else on HN advocating for C#)
Also, this is surprising because this was presented and led by Anders Hejlsberg, who is the creator of both C# and Typescript. If anyone should have picked C# it would be him.
Earlier quoted context omitted.
Hejlsberg seemed quite negative when it came to cross platform AOT compiled C# in several comments he's made, hinting at problems with both performance and maturity on certain platforms.
Projects like this are needed to improve C#'s cross platform AOT. Missed opportunity IMO.
But I think it's also an indication that Typescript may be bigger and more important for Microsoft than C#/.NET is at this time. It's definitely much more used than C# is according to this non-representative survey of Stack Overflow (https://survey.stackoverflow.co/2024/technology).
Earlier quoted context omitted.
One unrelated team at Microsoft doesn't 'believe' in .NET is enough to make you change direction?
More specifically, the guy who created C# doesn't believe in it (for this particular project). But, of course, that is not unusual. There is no language in existence that is best suited to every project out there.
Earlier quoted context omitted.
I wrote 362 words on why language rewrites are a faulty indicator of language quality with multiple examples and anecdotes, and you hyper-fixated on the very first sentence of my comment, instead of addressing the substance of my claim. In what alternate universe is that a good faith argument? If you were truly arguing in good faith you'd restate your position in whichever way you'd like your argument represented, an…
You said: "Inevitable means impossible to evade. That's about as close to a black and white statement as possible." I used Google to point out that your argument, which hinged on your definition of what the word "inevitable" means is the narrowest possible interpretation of my statement. An interpretation so narrow that it indicates you are arguing in bad faith, which I believe to be the case. You are accusing me of…
My argument does not hinge upon the definition of the word inevitable. You originally said "I mean, I can't think of a time a high profile project written in a lower level representation got ported to a higher level language."
I gave a relatively thorough accounting of why you've observed this, and why it doesn't indicate what you believe it to indicate here: https://news.ycombinator.com/item?id=43339297
Instead of addressing the substance of the argument you focused on this introductory sentence: "I'd like to address your larger point which seems to be that all greenfield projects are necessarily best suited to low level languages."
Regardless of how narrowly or widely you want me to interpret your stance, my point is that the data you're using to form your opinion (rewrites from higher to lower level languages) does not support any variation of your argument. You "can't think of a time a high profile project written in a lower level representation got ported to a higher level language" because developers tend to be more hesitant about reaching for lower level languages (due to the higher barrier to entry), and therefore are less likely to misuse them in the wrong problem domain.
I notice this time and time again: projects start with a flexible scripting language and a promise that the performance will be sufficient. I mean, JS is pretty performant as scripting languages go and it is hard to think of any language runtimes that get more attention than the browser VMs. And generally, 90% of the things people do will run sufficiently fast in that VM. Yet projects inevitably get to the stage wher…
> the lowest level representation that allows me some ergonomics The ergonomics of compiling your code for every combination of architecture and platform you plan to deploy to? It's not fun. I promise. > my default assumption to use JS runtimes on the server AWS Lambda has a minimum billing interval of 1ms. To do anything interesting you have to call other APIs which usually have a minimum latency of 5 to 30ms. You a…
I mean, on the one hand you are arguing for C FFI and on the other worrying about compiling for every combination of architecture. Those positions seem to be contradictory. Although I guess you're assuming that other people who write the C libraries for you did that work. I guess you better hope libraries exist for every possible performance issue you come across in your cross platform scripting library.
And why limit your runtime to AWS Lambda? That is a constraint you are placing on yourself. Nowadays with docker you can have pretty much any Linux you want as an image. But why not just implement on top of cgroups from scratch? I guess we live a world where that is unthinkable to many. Probably just better to pay AWS. But if you do use docker, all of a sudden worrying about compiling for all of those architectures seems like less of an issue. And you can use ECS, so you can still pay AWS!
As for tooling issues, and there are definitely tooling issues with every language, it is a pick your poison kind of thing. I remember really liking Pascal tooling way back in the day. Smalltalk images have some nifty features. Who doesn't like Lisp, the language that taught us all REPL. Not sure I'd choose them for a project today though.
As LLMs get better, I just assume what constitutes "developer experience" is going to change. Will I even care about how unergonomic writing test cases in Go can be if I can just say "LLM, write a test that covers X, Y, Z case". As long as I can read the resultant output and verify it meets my expectations, I don't care how many characters of code or boilerplate that will force the LLM to generate.
edit: I misread your point about Go test cases but I'll leave my mistake standing. My overall point was the stuff I find annoying to do myself I can just farm out to the LLM. If the cost of writing an experiment is "LLM, give this a try" and if it works great and if not `git checkout`, then I will be ok with something less optimal.
Earlier quoted context omitted.
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 functi…
“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 v…
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.
I notice this time and time again: projects start with a flexible scripting language and a promise that the performance will be sufficient. I mean, JS is pretty performant as scripting languages go and it is hard to think of any language runtimes that get more attention than the browser VMs. And generally, 90% of the things people do will run sufficiently fast in that VM. Yet projects inevitably get to the stage wher…
Just two years ago, a friend of mine described it as quite a hassle to get a RESTful backend running in Go. He got it working but it was more work than usual. Was he an outlier or have things been getting better in the framework department?