Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A 10x Faster TypeScript

devblogs.microsoft.com

Post reply on HN
Print view View original

861–870 of 943 posts

Re: A 10x Faster TypeScript

#861

Post by jerf »

melbourne_mat wrote: post #530
zoogeny wrote: post #230

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…

I think it's smart to start with a high level language which should reduce development time, prove the worth of the application, then switch to a lower level language later. What was that saying again? Premature optimisation is the root of all evil

I think a lot of people are running on facts that are between 10 to 25 years out of date. There was a time when the scripting languages had a very, very large step up in prototyping capability, because the static languages of the time were frankly terrible.

But the static languages have changed, a lot, for the better since then. I now find that when I'm greenfielding something, if I have even a clue how I want to structure it overall, that static languages end up being faster somewhere around a week into the development process. Dynamic languages are superficially easier to refactor, but the refactorings tend to take the form of creating functions that take more and more possible inputs and this corrodes the design over time. Static programs stay working the whole time, and I can easily transform the entire program to take some parameter differently or something and get assurance I'm not missing a code path.

I personally actively avoid dynamic languages for initial development now, for anything that is going to be over a week in size. The false economies are already biting by that point and it gets progressively and generally monotonically worse over time.

This comes from someone who was almost 100% dynamic scripting language in the first 15 years of my career. It's not from lack of understanding of dynamic scripting languages, used at scale.

Re: A 10x Faster TypeScript

#862

Post by nasretdinov »

zozbot234 wrote: post #854
nasretdinov wrote: post #853

Earlier quoted context omitted.

The standard library uses unsafe for syscalls, for higher-performance primitives like strings.Builder, etc, so it's support is mandatory to run any non-trivial Go program

Somehow I don't think Wasm-GC is going to support bare metal syscalls anytime soon. That stuff all has to be rewritten anyway if you want to target WASM.

It's not just system calls. E.g. reflection package uses unsafe too: https://github.com/golang/go/blob/master/src/reflect/value.g... . Many packages from Go standard library use unsafe one way or the other, so it's not fair to say that unsafe package is separate from the rest of the language

Re: A 10x Faster TypeScript

#863

Post by pjmlp »

zozbot234 wrote: post #851
pjmlp wrote: post #832

Earlier quoted context omitted.

It does, via unsafe package, yes it does look ugly, that is on purpose. item := *(*int)(unsafe.Pointer(uintptr(start) + size*uintptr(i))) A random example taken from Internet.

That's not the base language, it's an unsafe superset. There's no reason why a Wasm-GC backend for Golang should be expected to support that by default.

If it is part of the language reference it is part of the language.

Usually when language reference books used to be printed, or we used ISO languages, what is there on paper, is the language.

We are only discussing semantics, if it is hardcoded primitives, or made available via the standard library, specially in case of blessed packages like unsafe which aren't fully implemented, rather magical types for the compiler.

Hence why the only thing you will see here is mostly documentation, https://github.com/golang/go/blob/master/src/unsafe/unsafe.g...

Which is nothing new since the 1960's that there are systems languages with some way to mark code unsafe, the C linage of languages are the ones that decided to ignore this approach.

Re: A 10x Faster TypeScript

#864

Post by agos »

Cthulhu_ wrote: post #778
zestyping wrote: post #643

That's a pretty misleading clickbait title. TypeScript isn't getting 10x faster; the TypeScript compiler is getting 10x faster. I would argue it needs editing, as it violates the HN guideline: > use the original title, unless it is misleading or linkbait; don't editorialize.

Yeah, it's a bit linkbaity as it implies that the runtime is 10x faster; just adding the word 'compiler' or 'type checker' to the title would fix it.

There isn't a single runtime, it's quite clear that Typescript here means the compiler

Re: A 10x Faster TypeScript

#865

Post by 999900000999 »

runevault wrote: post #695
999900000999 wrote: post #543

Earlier quoted context omitted.

While I'm dreaming of things that will never ever happen, I would absolutely love for them to buy the game engine side of Unity and open source it.

Unless I missed Unity sorting a ton of stuff out, I assume they're going to have to sell themselves off for parts at some point after the runtime fee fiasco that was supposed to make them profitable lead to developers being angry or outright leaving the ecosystem. My assumption if that happens unless the DOJ gets involved for some reason is MS buys it for this reason.

Unity isn't really worth 9 billion imo.

I would like MS to buy them out and FOSS the engine. Maybe if they split the ad business off into its own thing.

Unity feels like a bizarre almost abusing business relationship. They can change the terms of service at will.

The licensing is confusing. Billy is a freelancer. He makes a small game for his friend company. His friends company raises a funding round.

Depending on how much money is raised, Unity is going to call Billy up and extort him to upgrade to a higher license tier.

I don't particularly like Godot, but every few months I try and learn it again.

The game engine landscape is like picking the least worst option.

All that to be fair, Unity provided a high quality game engine for effectively nothing for over a decade to the vast majority of its users. It's time to pay the piper.

Re: A 10x Faster TypeScript

#866

Post by psd1 »

maxloh wrote: post #125
lytedev wrote: post #100

Earlier quoted context omitted.

Reading the article, it looks like they are writing go, so will probably be distributing go binaries.

Maybe they'll also be distributed in WASM too, which is easier to be integrated with JavaScript codebases.

Do a n00b a favour... would you ever run wasm outside of a client browser? Are you suggesting that wasm is a viable platform for local services or commands?

Or do you mean that there's a use case for a compilation in the browser?

Re: A 10x Faster TypeScript

#867

Post by whattidywhat »

Imustaskforhelp wrote: post #829
commandersaki wrote: post #815

Earlier quoted context omitted.

> it ideally could have been written in rust in my opinion What exactly would that buy and would the outcome matter much? In my opinion: pragmatism > idealism.

exactly , it sounds as if he is entitled to rust software. Golang is generally very fast and simple as well , the only problem is of memory allocation / garbage collector overhead but the benefits outweigh the loss.

I do like rust and like I said, ideally in my opinion. I also did say choosing go was more pragmatic. We are on the same page believe it or not.

Re: A 10x Faster TypeScript

#868

Post by whattidywhat »

zveyaeyv3sfye wrote: post #839
whattidywhat wrote: post #809

Earlier quoted context omitted.

The automatic gc doesn't seem like an actual deal breaker though. They probably just didn't want to redesign a bunch of data types that assumed one existed. I'm not arguing saying they made a bad call. I think what they did was smart with the options in front of them and whatever budget they have. The world isn't good for idealism, but it ideally could have been written in rust in my opinion.

> They probably just didn't want to redesign a bunch of data types that assumed one existed. Dude, just read the article being discussed, this is addressed so you can just stop making shit up. The audacity of people like you to just keep adding speculations upon speculations on a subject without even bothering to learn what is being discussed.

Yes they said there were issues with cyclic data structures. Not really speculating just wrote it funny. I get why they chose what they did and even said I agree with it.

Re: A 10x Faster TypeScript

#869

Post by whattidywhat »

oldmanhorton wrote: post #843
zveyaeyv3sfye wrote: post #838

Earlier quoted context omitted.

> I think they missed out by not going with Rust. It seems like the social factors weighed out. They absolutely address this in the linked article, so why are we even speculating here? > Probably hard to quickly assemble a rust team within msft. The same MSFT that is rewriting their Windows OS in rust as we speak? I think you should stop commenting when you don't know anything about the subject.

Saying that Microsoft is "Rewriting Windows in rust" suggests you might not be as informed as you think... Very specific components with history of performance or security issues are getting ported in a very uncoordinated effort. Windows will be primarily C, C++, and C# for a very long time to come

Also those are two different skill sets. Writing critical sections of an OS is not the same thing as writing a compiler. And completely agree, windows to what I have read, is being deliberate and isn't doing a total rewrite at all. Thanks for chiming in so I could type less.

Re: A 10x Faster TypeScript

#870

Post by mpweiher »

zoogeny wrote: post #230

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…

Yes, I think the promises of the "we can JIT all the overhead away"-camp were always overblown, and never materialized in practice. This is another very strong datapoint for that hypothesis[1].

However, it is important not to conflate "scripting language" and "dynamic language" and "interpreted". While there is some correlation there, it is not a necessary one.

Objective-C is an example of a fast AOT-compiled pretty dynamic language, and WebScript was an interpreted scripting language with pretty much identical syntax and semantics.[2]

What do I mean with fast? In my experience, Objective-C can be extremely fast [3], though it can also be used very much like a scripting language and can also be used in ways that are as slow or even slower than popular scripting languages. That range is very interesting.

So I don't actually think the tradeoff you describe between low-level unergonomic fast and high-level ergonomic slow is a necessary one, and one of the goals of Objective-S is to prove that point.[4]

So far, it's looking very good. Basically, the richer ways of connecting components appear to allow fairly simple "scripted" connections to achieve reasonably high performance [5]. However, I now have a very simple AOT compiler (no optimizations whatsoever!) and that gives another factor 2.6 [6].

Steve Sinowsky wrote: "Does developer convenience really trump correctness, scalability, performance, separation of concerns, extensibility, and accidental complexity?"[7].

I am saying: how about we not have to choose?

And I'd much rather debug/modify semantically rich, high-level code that my LLM generated.

[1] https://blog.metaobject.com/2015/10/jitterdammerung.html

[2] https://blog.metaobject.com/2019/12/the-4-stages-of-objectiv...

[3] https://www.amazon.com/gp/product/0321842847/ref=as_li_tl?ie...

[4] https://objective.st

[5] https://blog.metaobject.com/2021/07/deleting-code-to-double-...

[6] https://dl.acm.org/doi/10.1145/3689492.3690052

[7] https://darkcoding.net/research/IEEE-Convenience_Over_Correc...

Post reply on HN