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

TypeScript 5.0

devblogs.microsoft.com

Post reply on HN
Print view View original

281–290 of 332 posts

Re: TypeScript 5.0

#281

Post by postdb »

kaba0 wrote: post #224
theshrike79 wrote: post #170

Earlier quoted context omitted.

C# is pretty much Java done right. Speaking as someone who started with Java 1.2 and saw all the crap that happened to it. C# is currently lightyears ahead of Java in every way, especially now that MS is not Micro$oft to people on the internet any more =)

> C# is currently lightyears ahead of Java in every way Let’s not claim things that can’t be objectively proven. C# does have much more features than Java, but that is not necessarily a plus in case of a programming language. There are features that are definitely better, but I am not bought that the whole would be. Plus, ecosystem-wise Java is much bigger and much more open-source. The runtime is also better on the…

Also C# is really meant to run on MS servers (Azur). Yes you can compile C# asp core projects on Linux, but the hell of dll when the there are many projects in a solution is quit annoying. Development experience in C# without Visual Studio is quite cumbersome.

Re: TypeScript 5.0

#282

Post by theshrike79 »

postdb wrote: post #281
kaba0 wrote: post #224

Earlier quoted context omitted.

> C# is currently lightyears ahead of Java in every way Let’s not claim things that can’t be objectively proven. C# does have much more features than Java, but that is not necessarily a plus in case of a programming language. There are features that are definitely better, but I am not bought that the whole would be. Plus, ecosystem-wise Java is much bigger and much more open-source. The runtime is also better on the…

Also C# is really meant to run on MS servers (Azur). Yes you can compile C# asp core projects on Linux, but the hell of dll when the there are many projects in a solution is quit annoying. Development experience in C# without Visual Studio is quite cumbersome.

Nope. This is the M$ == bad era thinking.

I've been doing C# on a MacBook with JetBrains Rider for years. Some code runs in Linux containers, some on AWS Lambda.

Re: TypeScript 5.0

#283

Post by postdb »

illiarian wrote: post #150
jdlshore wrote: post #143

Earlier quoted context omitted.

Threads are a function of the environment, and are available in TS and other compiles-to-JS languages: Node.js: https://nodejs.org/api/worker_threads.html Browser: https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers... However, threads are very rarely needed. The common use case in other languages is I/O, and JS environments handle that with async I/O—a superior choice, IMO.

Neither of those are proper threads, and they have various limitations placed on them. And the language and the VM has been, and will be for any foreseeable future, single-threaded.

Deno supports vastly superior threading model (such as green threads). Again depending on what you are coding, threading may not be the best model. Look at Ngnix vs Apache (event driven vs threading).

Re: TypeScript 5.0

#284

Post by postdb »

ggregoire wrote: post #137
i_am_toaster wrote: post #115

I’m always surprised by how much others like typescript. Out of all the languages I have to use, typescript is the one that feels the most like pulling teeth. Maybe I just don’t know how bad it truly was to work with a really large JavaScript project without types and that’s why people love it, but without that experience it just feels like all the hassle of types without most of their benefits.

Your experience probably differs from people who like TS. Personally I don't feel any hassle from using it and I couldn't even start listing all the benefits it offers. Even for very small personal projects, first thing I do is installing TS. Not saying it's your case, but I noticed that a lot of people who hate TS like to use techniques and patterns that are usually considered bad practices, which often trigger erro…

>Not saying it's your case, but I noticed that a lot of people who hate TS like to use techniques and patterns that are usually considered bad practices, which often trigger errors in TS. Mutating an object to add a new property, mutating an array to add an element of a different type, processing apples and oranges in the same function without using generics or the correct union type, etc. Code works but TS doesn't like it and forces them to rewrite it properly and it feels like a hassle with no benefits.

Not sure, people who like TS are usually for large corporate projects with OOP background. Most functional lispish type developer would be fine just using ES6 and above.

Re: TypeScript 5.0

#285

Post by rk06 »

giraffe_lady wrote: post #141
dimitropoulos wrote: post #2

Without Angular, we may very well not have TypeScript today. The top thing listed in this release (TypeScript doesn't follow semver, btw) is about Decorators. I find the whole story about Angular's role in TypeScript early days to be very fascinating because I don't hear people talk about it anymore (just search "AtScript TypeScript" if you weren't around at the time). It was the Angular team that forced Decorators t…

god just think how good life would be if we had all switched to elm or reason instead.

Elm was never an option with how hard it is on "no js" policy

Re: TypeScript 5.0

#286

Post by jiggawatts »

kaba0 wrote: post #234
jiggawatts wrote: post #223

Earlier quoted context omitted.

They're both JIT compiled, not ahead-of-time compiled. This severely limits the type of optimisations that they can perform, because they have to do it "on the fly" during runtime.

Being pedantic, both have AOT compilers readily available. But sure, though I don’t really buy the argument that JIT compilers would “severely limit” the type of optimizations - there is no significant performance difference - if any - between AOT compiled managed languages and JIT-compiled ones. Sure, there are more constraints in case of a JIT, but it’s not like going in the other direction and letting gcc/clang ch…

The AOT compiled managed languages are hamstrung in no small part by their fundamental design, which was intended for virtual machines. Java and C# were designed in the 1990s. Since then, hardware has changed. For example, indirect calls are much more expensive in relative terms, and the memory bloat introduced by template metaprogramming is much less of a limitation.

Imagine a language as easy to use as Python, with the strong typing of Typescript, but designed from the ground up to always be fully compiled and hence running as fast as C++, but with build times measured in fractions of a second... fast enough to feel interpreted.

Re: TypeScript 5.0

#287

Post by kaba0 »

jiggawatts wrote: post #286
kaba0 wrote: post #234

Earlier quoted context omitted.

Being pedantic, both have AOT compilers readily available. But sure, though I don’t really buy the argument that JIT compilers would “severely limit” the type of optimizations - there is no significant performance difference - if any - between AOT compiled managed languages and JIT-compiled ones. Sure, there are more constraints in case of a JIT, but it’s not like going in the other direction and letting gcc/clang ch…

The AOT compiled managed languages are hamstrung in no small part by their fundamental design, which was intended for virtual machines. Java and C# were designed in the 1990s. Since then, hardware has changed. For example, indirect calls are much more expensive in relative terms, and the memory bloat introduced by template metaprogramming is much less of a limitation. Imagine a language as easy to use as Python, with…

The biggest speedup one could get on modern hardware (in single-threaded context) comes from effectively using the CPU caches and in certain cases, vectorization. Clever use of these can give you 10-100x speedups.

This extra optimization is somewhat offset by the very point of a managed language: the programmer don’t want memory layout details to leak into the design/APIs, but in the rare case it is needed it can be done just as well with the escape hatches they provide (byte buffers, value types also bring you quite far). But business logic seldom involve these scorching hot loops to begin with, so there may not even be anything to optimize in this manner.

Re: TypeScript 5.0

#288

Post by pjmlp »

theshrike79 wrote: post #282
postdb wrote: post #281

Earlier quoted context omitted.

Also C# is really meant to run on MS servers (Azur). Yes you can compile C# asp core projects on Linux, but the hell of dll when the there are many projects in a solution is quit annoying. Development experience in C# without Visual Studio is quite cumbersome.

Nope. This is the M$ == bad era thinking. I've been doing C# on a MacBook with JetBrains Rider for years. Some code runs in Linux containers, some on AWS Lambda.

Nope, see you're using Rider, because VS4Mac and VSCode only offer a subset of Visual Studio capabilities for .NET development.

I rather do .NET than Java, but the FOSS story isn't as Microsoft sells it, hence why on our agency .NET is mostly used on Windows projects, and usually loses against Java or node in UNIX like RFP, even after .NET Core reboot, because of dependencies and existing enterprise tooling.

Re: TypeScript 5.0

#289

Post by awestroke »

iainmerrick wrote: post #247
endisneigh wrote: post #50

I have a strange take - I think Typescript types are better most other languages, including Java, C++ and Go. It's strange since TypeScript is adding types to a weakly typed language. If we could push JavaScript performance to be another order of magnitude faster it wouldn't be necessary to use other languages, imho. Of course, pushing it that far without effectively creating a new one would be difficult, to say the…

One thing I wonder is whether a “strict mode” subset of TS could be compiled to efficient code. Disallow “any” and most of the dynamic and meta programming features of JS so it’s fully typesafe. The type system is really nice, so even without being able to use the full range of JS hacks and escape hatches, I think it’d still be a nice language to work in.

TS by itself is not fully sound which could complicate such a compiler.

Example: https://www.typescriptlang.org/play?#code/MYewdgzgLgBAtgTwLI...

In the example above, the problem is that typescript allows casting function types to omit optional arguments, and also allows using a function with n arguments as a value where a function with >n arguments is expected

Re: TypeScript 5.0

#290

Post by tomduncalf »

JamesSwift wrote: post #8
dimitropoulos wrote: post #2

Without Angular, we may very well not have TypeScript today. The top thing listed in this release (TypeScript doesn't follow semver, btw) is about Decorators. I find the whole story about Angular's role in TypeScript early days to be very fascinating because I don't hear people talk about it anymore (just search "AtScript TypeScript" if you weren't around at the time). It was the Angular team that forced Decorators t…

One of my most regretted decisions was evaluating Flow vs Typescript and going with Flow. Years later I had the opportunity to use Typescript and it was so nice comparatively. I've enjoyed it ever since. Of course, that was with years of development in its belt so maybe the experience wouldn't have been as nice if I went with it originally.

It’s hard to imagine if you weren’t in the React community at the time, but I feel like most people were pushing Flow at the time and choosing TS was quite controversial. I think it was the combination of Flow being from Facebook, and the “no build step/its just JS with annotations” thing which people made a big deal out of, but I never saw as a big differentiator.

I had a hard time convincing a couple of places I worked to use TS rather than Flow for greenfield projects, but I’d tried them both out and concluded Flow just felt too unstable - the server would consume all my memory and crash and it just didn’t feel like a good dev experience. I managed to convince them by showing them how you could strip out Typescript types in much the same way as Flow if TS did turn out to be a dead end. I also recall having vigorous debates at React meetups where I was the only person in favour of TS haha.

How times changed - you definitely can’t be blamed for choosing Flow at the time though as TS was the outsider. Also MS weren’t such a trusted brand for developers, people still associated them with proprietary stuff like .net/full fat Visual Studio and I think a few people had burned out in the MS ecosystem before and didn’t want to touch their stuff again!

Post reply on HN