851–860 of 943 posts
Earlier quoted context omitted.
I don't think Go supports any pointer arithmetic out-of-the-box? What it has in the base language is effectively references.
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.
Earlier quoted context omitted.
I generally agree that C# == Java == Go in most aspects and have far more and generally think C# is nicer to use and probably faster for many use cases. But, it is not the same as Go at all in terms of AOT. In golang that is just the default and always works - basically on all platforms, in C#, that is not the case. Do you really want to find out that a popular library uses some reflection and therefore doesn't work…
You may want to read the documentation first before responding.
Earlier quoted context omitted.
I don't think Go supports any pointer arithmetic out-of-the-box? What it has in the base language is effectively references.
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.
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.
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
Earlier quoted context omitted.
Hey Daniel. I write a lot of tools that depend on the TypeScript compiler API, and they run in a lot of a lot of JS environments including Node and the browser. The current CJS codebase is even a little tricky to load into standard JS module supporting environments like browsers, so I've been _really_ looking forward to what Jake and others have said will be an upcoming standard modules based version. Is that still h…
I think they answered in their FAQ here: https://github.com/microsoft/typescript-go/discussions/455#d... . If I got it correctly, they created a node native module that allows synchronous communication on standard I/O between external processes. So, this node module will make possible the communication between the typescript compiler GO process, that will expose an “API server compiler”, and a client side JavaScript…
I have API use that falls into a few categories, that aren' just LSP-ish type cases:
- Transforms, which presumably there has to be some solution for, even if it's porting to Go.
- Linters, which integrate with typescript-eslint and need the type-checker.
- Codemods, which create and modify AST nodes and re-emit them.
- Static analyzers, which build us app-specific models of the code and rely on AST traversal and the type-checker.
- Analyzer libraries that offer tools to other libraries and apps that expose the TypeScript AST and functions that operate on AST nodes.
Traversing the AST over IPC is going to be too chatty, so I presume there will have to be some sort of way to get a whole SourceFile in one call, but then I wonder about traversal. You'll need a visitor library on your side of the IPC at least, but that's simple. But then you also need all the predicates. You don't want to be calling ts.isTemplateExpression() on every node via IPC.
And I do all this stuff in web workers too, so whatever this IPC is has to work there.
Earlier quoted context omitted.
> While we’re not yet feature-complete This is a big concern to me. Could you expand on what work is left to do for the native implementation of gsc? In particular, can you make an argument why that last bit of work won't reduce these 10x figures we're seeing? I'm worried the marketing got ahead of the engineering
It’s fine, if it’s 2x faster after being feature complete, I don’t really mind. It still is a free speedup to all existing code-bases. Developers don’t need to anything than install the latest version of TypeScript I presume
Earlier quoted context omitted.
You may want to read the documentation first before responding.
Where in the documentation does it state that everything just works (as it would in go)? I see a list of incompatibilities / limitations etc., that not only apply to your own code but any 3rd party library.
Very specific areas require reflection which is not analyzable with the main user being serialization and serialization just happens to be completely solved.
Earlier quoted context omitted.
.NET executables requires a runtime environment to be installed. Go executables do not. TSC is installed in too many places for that burden to be placed all of a sudden. It is the same reason why Java has had a complicated acceptance history too. It's fine in the places that it is pre-installed, but no where else. Node/React/Typescript developers do not want to install .net all of a sudden. If you react that poorly,…
.NET has been able to build a self contained single file executable for both the JIT and AOT target for a quite some time. Java also does not require the user to install a runtime. JLink and JPackage have both been around for a long time.
SQL Server connections are one example where I do get .exe with the .pdb in the publish directory but the .exe won't run correctly without the "Microsoft.Data.SqlClient.SNI.dll" file.
Another example are any libraries that have "RequiresDynamicCodeAttribute" requirements.
Earlier quoted context omitted.
funny you bring up this analogy. tons of auto manufacturers these days will license other mfgs' engines and use them in your cars. e.g. a fair number of Ford's cars have had Mazda engines and a fair number of Mazdas have had Ford engines.
Could you give some examples of both? Also, why did they choose to do this?
It’s probably most common when an automaker introduces a new make and wants to save time and capital on developing and getting into production a new engine.
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…