Earlier quoted context omitted.
Did't know Java had a `Promise` type
That's not Java. I believe they're demoing in Typescript a pattern they like from Java/Spring/Quarkus/Micronaut.
TypeScript 5.0
211–220 of 332 posts
Re: TypeScript 5.0
#212I 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…
I used to think so too, until I tried Rust. By comparison, JavaScript (and by extension, TypeScript) is still lacking fundamental features and the library ecosystem situation is pretty bad. I wish there was a modern language that took all the good non-manual-memory-management things from Rust and added a GC and some immutable data structures. Error handling, enums, macros (with compile_error! / diagnostics API), trai…
Re: TypeScript 5.0
#213I 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…
I used to think so too, until I tried Rust. By comparison, JavaScript (and by extension, TypeScript) is still lacking fundamental features and the library ecosystem situation is pretty bad. I wish there was a modern language that took all the good non-manual-memory-management things from Rust and added a GC and some immutable data structures. Error handling, enums, macros (with compile_error! / diagnostics API), trai…
I feel like the entire industry has had a "kneejerk reaction" to C++ and its abysmally slow compile times. Everyone jumped onto the interpreter bandwagon and ended up throwing the baby out with the bathwater.
It is definitely possible to have sub-second compile times for large, complex software! Just look at Jonathan Blow's Jai language. He can recompile and reload an entire 3D game engine in about that time.
We can have our cake and eat it to. We can have efficient, compiled languages and still have safety and fast compilation.
Re: TypeScript 5.0
#214Earlier quoted context omitted.
Have you tried C#? Sounds like it would fit your needs perfectly, additionally benefitting from a huge ecosystem behind it.
How does the verbosity in C# compare to Java's? And are big C# codebases littered with annotations and "dependency inversion" Java Spring boilerplate-y crap? I ask because I have never delved into C# only heard it's Microsoft's Java. And I am no fan of the original Java at all so C# gives me pause.
DI is almost always in web, but via constructor instead of annotations.
Re: TypeScript 5.0
#215Earlier quoted context omitted.
I don't think decorators being a proposal matters at this point. I know I've been using them for 5+ years now, and libraries such as NestJS already use them extensively. If you like them, you're probably already drowning in them. Me, personally, I could take them or leave them.
What do you use decorators for? I've never used them and I'm curious what the usecases are. The logging thing looks helpful.
Re: TypeScript 5.0
#216Re: TypeScript 5.0
#217Earlier quoted context omitted.
The point of having a utility function is that you don't have to do the redundant checks every time you want to make sure it's both a number and an integer. The critical bit is that you need to define a new type for `integer`s distinct from `number`s to allow reusing the code in a way that doesn't break the type system on the negative path, as Ryan and I demonstrated.
It isn't redundant in terms of the amount of code written, to me. The overhead of having the utility function and type is greater IMO. If it's in terms of performance, that seems like moving the goalposts. I also wonder if it could be optimized away. Next time I run into it I might use this: if (Number.isInteger(s)) { const allowed = (s as number).toExponential() ...and keep the isInteger check close enough that it's…
Whatever floats your boat, as you say.
Re: TypeScript 5.0
#218I 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…
I used to think so too, until I tried Rust. By comparison, JavaScript (and by extension, TypeScript) is still lacking fundamental features and the library ecosystem situation is pretty bad. I wish there was a modern language that took all the good non-manual-memory-management things from Rust and added a GC and some immutable data structures. Error handling, enums, macros (with compile_error! / diagnostics API), trai…
Re: TypeScript 5.0
#219Earlier quoted context omitted.
It isn't redundant in terms of the amount of code written, to me. The overhead of having the utility function and type is greater IMO. If it's in terms of performance, that seems like moving the goalposts. I also wonder if it could be optimized away. Next time I run into it I might use this: if (Number.isInteger(s)) { const allowed = (s as number).toExponential() ...and keep the isInteger check close enough that it's…
You asked for isInteger to work as a type guard and I showed you how. If you prefer explicit casts everywhere that's fine, but it isn't a type guard. You could even use the type anonymously if you really want: (n is number & {Symbol(): never}). Whatever floats your boat, as you say.
Have a nice day.
Re: TypeScript 5.0
#220Earlier quoted context omitted.
Have you tried C#? Sounds like it would fit your needs perfectly, additionally benefitting from a huge ecosystem behind it.
How does the verbosity in C# compare to Java's? And are big C# codebases littered with annotations and "dependency inversion" Java Spring boilerplate-y crap? I ask because I have never delved into C# only heard it's Microsoft's Java. And I am no fan of the original Java at all so C# gives me pause.
Similarly recent libraries such ASP.NET have been working hard to use more of these things to eliminate their own boilerplate. The latest ASP.NET templates use top-level statements and some global usings and are getting very lightweight in terms of starter-level code.
.NET does have annotations and dependency inversion, but those too tend to avoid boilerplate more than create it. Few annotations are "required", depending on your domain and which libraries you are expecting to use. .NET now has a single, mostly standardized dependency injector that almost everyone has agreed to use (Microsoft.Extensions.DependencyInjection) at this point. It intentionally only supports a bare minimum of Dependency Injection needs and is nothing like the Kitchen Sink approach of something like Java's Spring. (For instance, zero out of the box support for wiring Dependency Injection via XML files. .NET's DI is always code driven, often in a Startup.cs, Program.cs, App.cs, or Main.cs file.)
I've been increasingly finding in C# that I'm writing new code with zero templates and almost no snippets-expansion. (There will always be plenty of legacy code out there with much more verbosity, of course.)
The easiest suggestion is to try it for yourself. The `dotnet` tool is cross-platform, generally an easy install, and its `dotnet new` command will help you try many easy template types. You can relatively easily work entirely in VS Code today (as opposed to older versions of C# often "needed" the full bulky Visual Studio install for templates, language servers, and other stuff).