@lucianomicrostop
What an incredible class by Anders Hejlsberg!
@stepanhakobyan
I like how Anders explains anything. Great speech again.
@GaryJohnWalker1
Fascinating material. And Anders is a great public speaker
@GoDjMike
It was a mistake to lay off Ron Buckton.
@aresaurelian
This overhaul of all major systems working together as a meta-verse like structure is brilliant.
@xtreatdev
Did you talk about how you laid off the engineers responsible for this accomplishment?
@arvindynr
Microsoft fired Ron Buckton, the man behind TypeScript and now uploading typescript tutorials.
@ArcticPrimal
Great showcase, golang for porting this was the right choice
@zuraforreg3088
Didn't you just lay off the person responsible for that 10x improvement? Is it because the target was 20x?
@FabulousFadz
I find it very interesting that Microsoft had a Gophercon talk right in the middle of Build.
@guru5383
Angular and typescript-go will boost the framework and native mobile app development 🎉❤😊
@minhazhalim2097
I like TypeScript, Anders Hejlsberg and his presentation.
@mloskot
Grabbing some popcorn & fizzy drink and waiting for Rust'ies to chime in to prove how Hejlsberg's team decision was wrong ;)
@gilbertsenyonjo963
Great speech! Cheers to opensource
@ByteSizedSociety
Aside: @10:30 Beyond Compare Is a wonderful diffing tool. Allowing easy comparison of nested folders, EG when you have made changes to one code base and another person has another version of it, this allows quick comparison between the two and migration of changes from one to the other. Closed source, reasonable cost, high-speed, worth it.
@MartinMalmsten
Anders Hejlsberg: making non-standard versions of popular languages since the 80s for fun and profit
@snotchy2
Can't wait for them to rewrite c# compiler in go
@typeof_nan
the goat 🐐
@itaironen1
Why not C#? No actual reason. You were just "intrigued" by Go. Let's talk about the presented reasons. 08:18 Because it's object Oriented? Because it supports classes? Functional programming in C# is extremely superior to Go due to great generics and extension methods. Native code generation isn't "quite as mature"? Any research to estimate whether native C# is slower? By how much? 08:47 No reason presented for choosing Go, unless you count "intrigued". Every reason listed later is supported in both Rust and C#, mostly better than Go: - Older than 10 years old - not a real reason - "It's on all major platforms, highly optimized stuff" - Same for Rust and C#. Any benchmark comparison? - "It doesn't actually have classes" - Why is this a reason to choose Go? - First class functions - Same for Rust and C#. - Function "close over outer state" - I assume he means "closures" - C# support it just the same. - Data layout control - Go is the weakest on this point. On C# and Rust you can define explicit data layout. To be frank, I don't see why it matters if you don't rewrite (00:14, 15:51) as javascript doesn't support it. - Concurrency - Go doesn't support async-await or something like C#'s Task. 09:39 Started with Go, and guess what they found out? That javascript is slow. Big surprise! No need to try Rust or C#, because we never used Go before and it's intriguing. Now let's commit "the entire team to actually porting the code". It's so funny that at 23:17 he explains some of the issues they had with Go. Those issues would not exist on C#, you just shot yourself in the leg (and I don't think different issues would have surfaced with C# to the same degree if at all). They had to do "extensive refactoring" and find clever ways to work around those issues. 28:50 Strings - Putting aside the unclear saying of "Go uses UTF8 encoding". He compares the memory taken when holding the code to compile in memory, when it is held in UTF16 and UTF8, because javascript and C# use UTF16 for their string type. You don't have to hold the entire text as UTF16, hold it however you want, you don't even have to use the string type. In Go a string is just a sequence (slice) of bytes, that's it, nothing special, pointer and length (for some reason it is very interesting 29:44). The equivalent in Go to an actual string type is a sequence (slice) of "runes" which are int32, 4 bytes compared to UTF16 with 2 bytes (I don't really think it's actually important but played the game). He mentions that "substring" is an allocation free operation. It's just a reference and offset. A C# Span is the same as a Go slice (as said a Go string is a slice of bytes). 32:28 Pool Allocation "In C# or Java or Javascript" you have to allocate one object at a time and in Go you can allocate an array and implement a pool. Why can't you create a pool in any language? Are you comparing allocation of structs to classes? Ok let's say an "identifier" (the example used) needs to be used by-ref. Is it really that much better than the default allocator? Ok let's say it is. With all the above restrictions (unclear why you would be restricted) it is nice to have pointers. In C# you could allocate unmanaged memory then use pointers. Would even save some GC work (and in this example sounds like the compiler holds and releases the entire pool together or never releases). Otherwise, you'll need a small struct with 2 fields, the array and the index. 34:10 Concurrency Go has no async-await, but somehow it's great because you don't "color" your functions. No, it's not great. Error handling and synchronization are harder. Isn't the original typescript code written with async-await anyway on the relevant parts of the code? "Green threads" in this case just hide the important details. You probably want to start reading all the files (not read yet) referenced by the current file, then wait for all to finish. - Writing simple sync code would make you read the files one after another. Obviously, it's not what you want, and going to explicitly open a go-routine per file, then use a wait-group. - In C# you can start each file read, collecting the Tasks to a list, then wait for all the tasks to finish. He then says the implementation they chose is to parse all the files in parallel regardless of the dependencies between the files. In this case you don't need to "color" the functions (with async-await). After the first step, all files are in memory, there is no IO passed this point (until writing the output). I've worked with C# for a long time. I've been working with Go on my full-time job for over 6 years, and due to the same reason that you chose Go, because someone 9 years ago was intrigued. Go is not a great language. It's okay at best. I don't know enough about Rust, but I sure know C# would have been a much better option.
@isakdahlstrom