5 ms·

Very interesting. I wish they had gone into a little more detail about the other technologies involved. Was the Java Service in Spring (boot)? What other tech

by zapnuk 1y ago

Very interesting. I wish they had gone into a little more detail about the other technologies involved. Was the Java Service in Spring (boot)? What other technologies were considerd? I'd assume Go was among them. Was it just the fact that Go's type system is to simplistic or what were the other factors?

geodel 1y ago
Swift is Apple's own language. They have all the experts from lowest to highest level . Writing a long winded report/article for fair technical evaluation of competing technologies would utter waste of time and no one would believe if answer were still Swift. > I'd assume Go was among them. ... I don't see any reason to evaluate Go at all.
- latchkey 1y ago
  > I don't see any reason to evaluate Go at all. https://devblogs.microsoft.com/typescript/typescript-native-port/ https://devblogs.microsoft.com/typescript/typescript-native-...
  - dontlaugh 1y ago
    That still seems like a long term mistake to me, an evolutionary dead end.
    - latchkey 1y ago
      Does it matter? Today, they get a 10x improvement by switching. Mission accomplished. X years from now, another language will come along and then they can switch to that for whatever benefit it has. It is just the nature of these things in technology.
      - dontlaugh 1y ago
        It can be a limitation much faster than that. They are in a situation where they won’t be able to improve further by much due to unavoidable costly abstractions in Go. If they’d picked something lower level there would be more possible after this first switch.
        latchkey 1y ago
        My mistake, I shouldn't have put a number there since that is what you focused on. Rewriting it in assembly is the way to go, but that has other tradeoffs.
        dontlaugh 1y ago
        I’m not focused on a number, I’m just pointing out Go’s optimisation potential is lower than other options. Of course it’s a trade off and their reasons are fine, but rewrites are expensive and disruptive. I would have picked something that can avoid a second rewrite later on.
        latchkey 1y ago
        [flagged]
        dontlaugh 1y ago
        I'm well aware of how they're doing it. It makes sense to start with a mostly-automated rewrite, what they confusingly call a "port". But after that step, the end result will be maintained and changed manually. It makes perfect sense to make improvements (including to performance) this way. All I'm questioning is the choice of target, since it excludes some possible future improvements. If you're rewriting (semi-automated or not), it's an opportunity to future-proof as well. I don't understand why you're being so confrontational about mere technical disagreement.
        latchkey 1y ago
        I'm not disagreeing with you and it is weird that my comment above got flagged given that I'm not attacking you. ¯\_(ツ)_/¯
    - hardwaresofton 1y ago
      It absolutely was. All it takes is a quick look around other language ecosystems and JS itself. Rust is an excellent language for embedding in other languages And underpinning developer tools. That said, someday the new typescript binary will compile to WebAssembly, and it won’t matter much anyway.
      - dontlaugh 1y ago
        There is that opposite approach, yes. Add low-level control to TypeScript and get it to compile to WebAssembly, then the compiler itself can be fast as well. I suspect they wanted the compiler speed more than they wanted a WASM target, though.
  - MBCook 1y ago
    But that ignores the fact Apple has a MASSIVE investment in Swift. I think they already use Go in places, but they’ve clearly stated their intention to use Swift as much as possible where it’s reasonable. I suspect they didn’t evaluate C++, Rust, Go, Erlang, Node, and 12 other things. They have the experience from other Swift services to know it will perform well. Their people already know and use it. If Swift (and the libraries used) weren’t good enough they’d get their people to improve it and then wait to switch off Java. If you go to a Java shop and say you want to use C# for something Java can do, they’ll probably say to use Java. I don’t read this post as “Swift is the best thing out there” but simply “hey Swift works great here too where you might not expect, it’s an option you might not have known about”.
    - latchkey 1y ago
      Microsoft has a massive investment in C#, but they still evaluated (and picked) golang.
      - MBCook 1y ago
        For TypeScript’s compiler, yes. I can see some real benefits, like Go is already common for some open source software they want to collaborate with non-MS people on. I suspect C# is much less common for that, and when targeting pure performance I suspect a bytecode language like C# wouldn’t have the same large gain. I’m not in the .NET ecosystem so I don’t know if native AOT compilation to machine code is an option. But anyway, in this case Apple is making an internal service for themselves. I think a better comparison for MS would be if they chose to rewrite some Windows service’s server back end. Would they choose Go for that? I don’t know.
        latchkey 1y ago
        The real question isn’t whether they would choose it, but whether they’d be willing to evaluate it. Given their past behavior, as I mentioned above, it seems they are open to assessing options and selecting the best tool for the job.
  - geodel 1y ago
    Yeah, while they are at it they can also learn on how to write OS for ARM architecture from Microsoft.
  - pjmlp 1y ago
    I don't buy the reasoning. First of all, it is a missed opportunity for Microsoft to have another vector for people to learn C#. Secondly at BUILD session, Anders ended up explaning that they needed to rewrite the AST data structures anyway, given that Go type system is much inferior to Typescript. And Go's story on WebAssembly is quite poor, when compared with Blazor toolchain, they are hopping Google will make the necessary improvements, required for the TypeScript playground and when running VSCode on the browser. Finally, some of the key develpers involved on this effort have been layed off during the latest round.
    - uticus 1y ago
      This is fascinating. I really bought into the original explanation [0], but seems like it was not the (full) truth. [0] https://devblogs.microsoft.com/typescript/typescript-native-port/ https://devblogs.microsoft.com/typescript/typescript-native-...
anuragsoni 1y ago
Apple maintains servicetalk[1] (java networking framework built on top of netty), so I'm guessing this is one potential JVM framework that was being used. [1] https://github.com/apple/servicetalk https://github.com/apple/servicetalk

by zapnuk 1y ago

geodel 1y ago

Swift is Apple's own language. They have all the experts from lowest to highest level . Writing a long winded report/article for fair technical evaluation of competing technologies would utter waste of time and no one would believe if answer were still Swift. > I'd assume Go was among them. ... I don't see any reason to evaluate Go at all.

latchkey 1y ago
> I don't see any reason to evaluate Go at all. https://devblogs.microsoft.com/typescript/typescript-native-port/ https://devblogs.microsoft.com/typescript/typescript-native-...
- dontlaugh 1y ago
  That still seems like a long term mistake to me, an evolutionary dead end.
  - latchkey 1y ago
    Does it matter? Today, they get a 10x improvement by switching. Mission accomplished. X years from now, another language will come along and then they can switch to that for whatever benefit it has. It is just the nature of these things in technology.
    - dontlaugh 1y ago
      It can be a limitation much faster than that. They are in a situation where they won’t be able to improve further by much due to unavoidable costly abstractions in Go. If they’d picked something lower level there would be more possible after this first switch.
      - latchkey 1y ago
        My mistake, I shouldn't have put a number there since that is what you focused on. Rewriting it in assembly is the way to go, but that has other tradeoffs.
        dontlaugh 1y ago
        I’m not focused on a number, I’m just pointing out Go’s optimisation potential is lower than other options. Of course it’s a trade off and their reasons are fine, but rewrites are expensive and disruptive. I would have picked something that can avoid a second rewrite later on.
        latchkey 1y ago
        [flagged]
        dontlaugh 1y ago
        I'm well aware of how they're doing it. It makes sense to start with a mostly-automated rewrite, what they confusingly call a "port". But after that step, the end result will be maintained and changed manually. It makes perfect sense to make improvements (including to performance) this way. All I'm questioning is the choice of target, since it excludes some possible future improvements. If you're rewriting (semi-automated or not), it's an opportunity to future-proof as well. I don't understand why you're being so confrontational about mere technical disagreement.
        latchkey 1y ago
        I'm not disagreeing with you and it is weird that my comment above got flagged given that I'm not attacking you. ¯\_(ツ)_/¯
  - hardwaresofton 1y ago
    It absolutely was. All it takes is a quick look around other language ecosystems and JS itself. Rust is an excellent language for embedding in other languages And underpinning developer tools. That said, someday the new typescript binary will compile to WebAssembly, and it won’t matter much anyway.
    - dontlaugh 1y ago
      There is that opposite approach, yes. Add low-level control to TypeScript and get it to compile to WebAssembly, then the compiler itself can be fast as well. I suspect they wanted the compiler speed more than they wanted a WASM target, though.
- MBCook 1y ago
  But that ignores the fact Apple has a MASSIVE investment in Swift. I think they already use Go in places, but they’ve clearly stated their intention to use Swift as much as possible where it’s reasonable. I suspect they didn’t evaluate C++, Rust, Go, Erlang, Node, and 12 other things. They have the experience from other Swift services to know it will perform well. Their people already know and use it. If Swift (and the libraries used) weren’t good enough they’d get their people to improve it and then wait to switch off Java. If you go to a Java shop and say you want to use C# for something Java can do, they’ll probably say to use Java. I don’t read this post as “Swift is the best thing out there” but simply “hey Swift works great here too where you might not expect, it’s an option you might not have known about”.
  - latchkey 1y ago
    Microsoft has a massive investment in C#, but they still evaluated (and picked) golang.
    - MBCook 1y ago
      For TypeScript’s compiler, yes. I can see some real benefits, like Go is already common for some open source software they want to collaborate with non-MS people on. I suspect C# is much less common for that, and when targeting pure performance I suspect a bytecode language like C# wouldn’t have the same large gain. I’m not in the .NET ecosystem so I don’t know if native AOT compilation to machine code is an option. But anyway, in this case Apple is making an internal service for themselves. I think a better comparison for MS would be if they chose to rewrite some Windows service’s server back end. Would they choose Go for that? I don’t know.
      - latchkey 1y ago
        The real question isn’t whether they would choose it, but whether they’d be willing to evaluate it. Given their past behavior, as I mentioned above, it seems they are open to assessing options and selecting the best tool for the job.
- geodel 1y ago
  Yeah, while they are at it they can also learn on how to write OS for ARM architecture from Microsoft.
- pjmlp 1y ago
  I don't buy the reasoning. First of all, it is a missed opportunity for Microsoft to have another vector for people to learn C#. Secondly at BUILD session, Anders ended up explaning that they needed to rewrite the AST data structures anyway, given that Go type system is much inferior to Typescript. And Go's story on WebAssembly is quite poor, when compared with Blazor toolchain, they are hopping Google will make the necessary improvements, required for the TypeScript playground and when running VSCode on the browser. Finally, some of the key develpers involved on this effort have been layed off during the latest round.
  - uticus 1y ago
    This is fascinating. I really bought into the original explanation [0], but seems like it was not the (full) truth. [0] https://devblogs.microsoft.com/typescript/typescript-native-port/ https://devblogs.microsoft.com/typescript/typescript-native-...

anuragsoni 1y ago

Apple maintains servicetalk[1] (java networking framework built on top of netty), so I'm guessing this is one potential JVM framework that was being used. [1] https://github.com/apple/servicetalk https://github.com/apple/servicetalk