5 ms·

It's fine but why is Js a good language for agents? I mean sure its faster than python but wouldn't something that compiles to native be much better?

by hoppp 11mo ago

AstroBen 11mo ago
It's widespread and good enough. The language just doesn't matter that much in most cases
- moron4hire 11mo ago
  This is one of those, "in theory, there's no difference between theory and practice. In practice, there is" issues. In their, quality software can be written in any programming language. In practice, folks who use Python or JavaScript as their application programming language start from a position of just not carrying very much about correctness or performance. Folks who use languages like Java or C#, do. And you can see the downstream effects of this in the difference in the production-grade developer experience and the quality of packages on offer in PIP and NPM versus Maven and NuGet.
  - wiseowise 11mo ago
    [flagged]
    - rishabhaiover 11mo ago
      Exactly! In the Java ecosystem, your intelligence is measured by how elaborate an interface hell you can conjure just to do CRUD.
    - CharlieDigital 11mo ago
      > Nonsense. Average Java/C# is an enterprise monkey who barely knows outside of their grotesque codebase. Netflix is Java. Amazon is mostly Java. Some of the biggest open source projects in the world are Java. Unity and Godot both use C# for scripting. I don't know where you're getting the impression that Java and C# are somehow only for "enterprise monkey who barely knows outside of their grotesque codebase"
      - wiseowise 11mo ago
        > Netflix is Java. Amazon is mostly Java. Some of the biggest open source projects in the world are Java. Unity and Godot both use C# for scripting. You can add Meta, Google and Palantir to your list and it won’t change that average Java dev is from an Eastern hemisphere and knows nothing about Java outside of JavaEE/Spring. See how generalizations work?
    - mrcsharp 11mo ago
      Chill out buddy. You're going to pop a vein here. A typical backend developer using C#/Java is likely solving more complicated problems and having all the concerns of an enterprise system to worry about and maintain. Dismissing a dev or a system because it is enterprisy is a weak argument to make against a language. A language being used a lot in an enterprise to carry the weight of the business is a sign the language is actually great and reliable enough.
      - wiseowise 11mo ago
        I’m not dismissing Java, I’ve spent decades writing it and know what it is capable of, but it is laughable to hear that average Java dev cares more about performance or correctness than Python/JS dev. All of them explicitly don’t have to care about performance from the start because of VMs + GC, only when scale starts to matter you start to optimize. Tooling argument is especially funny to me, given how shit tooling ecosystem is. Sure it is ol’ reliable, but average Java dev is so stuck in their ways that they’ve never even tried to dwell out of their Java cave to see what’s out there. IntelliJ consuming ALL of RAM, literally as much as it can get hands on. Gradle taking what’s left, rebuilds taking minutes to complete or requiring elaborate setup to have proper hot reload. Both TS and Python have far more expressive and powerful type systems than even modern Java. “Production grade tooling” my ass. Funny to see Java shmucks looking down at JS/Python folks, as if Java at the time wasn’t picked for literally same reasons as Python/JS nowadays.
  - AstroBen 11mo ago
    That's not a fair comparison. In your example, you're talking about the average of developers in a language. In this situation, it's specific developers choosing between languages. Having the developers you already have choose language A or B makes no difference to their code quality (assuming they're proficient with both)
    - moron4hire 11mo ago
      These are statements these developers will make themselves. They will say they don't like more strictly typed languages because they feel constrained and slowed down in development. They will argue that the performance hit is worth the trade offs.
  - drzaiusx11 11mo ago
    As a developer that switches between java, python and typescript every day I think this is fairly myopic opinion. Being siloed to one lang for long enough tends to brings out our tribalistic tendencies, tread carefully. I've seen codebases of varying quality in nearly every language, "enterprise" and otherwise. I've worked at a C# shop and it was no better or worse than the java/kotlin/typescript ones I've worked at. You can blame the "average" developer in a language for "not caring ", but more likely than not you're just observing the friction imposed by older packaging systems. Modern languages are usually coupled with package managers that make it trivial to publish language artifacts to package hubs, whereas gradle for example is it's own brand of hell just to get your code to build.
  - justatdotin 11mo ago
    perhaps many of those 'Folks who use languages like Java or C#' do so because a boss told them 'thats the way we deal with correctness and performance around here' the fact that their boss made that one decision for them does not somehow transmit the values behind the one decision.
chatmasta 11mo ago
JS has the fastest, most robust and widely deployed sandboxing engines (V8, followed closely by JavaScriptCore which is what Bun uses). It also has TypeScript which pairs well with agentic coding loops, and compiles to the aforementioned JavaScript which can run pretty much anywhere.
- otterley 11mo ago
  Note that "sandboxing" in this case is strictly runtime sandboxing - it's basically like having a separate process per event loop (as if you ran separate Node processes). It does not sandbox the machine context in which it runs (i.e. it's not VM-level containment).
  - Brass_Hopper 11mo ago
    When you say runtime sandboxing, are you referring to JavaScript agents? I haven't worked all that much with JavaScript execution environments outside of the browser so I'm not sure about what sandboxing mechanics are available.
    - otterley 11mo ago
      https://nodejs.org/api/vm.html https://nodejs.org/api/vm.html Bun claims this feature is for running untrusted code (https://bun.com/reference/node/vm https://bun.com/reference/node/vm), while Node says "The node:vm module is not a security mechanism. Do not use it to run untrusted code." I'm not sure whom to believe.
      - Jarred 11mo ago
        The reference docs are auto generated from node’s TypeScript types. node:vm is better than using the same global object to run untrusted code, but it’s not really a sandbox
      - Brass_Hopper 11mo ago
        It's interesting to see the difference in how both treat the module. It feels similar to a realm which makes me lean by default to not trusting it for untrusted code execution. It looks like Bun also supports Shadow Realms which from my understanding was more intended for sandboxing (although I have no idea how resources are shared between a host environment and Shadow Realms, and how that might potentially differ from the node VM module).
aizk 11mo ago
TS is enormous, has endless training data, and can interact with virtually anything on the Internet these days. Also, strong typing is very very useful for AI coding context.
- justatdotin 11mo ago
  > strong typing is very very useful for AI coding context what makes you think so? I believe strong typing is very very useful for human coding, I'm not convinced its so 'very very' for agents.
  - matwood 11mo ago
    When I've use agents with TS, failing tests due to typing seems to help the agent get to the correct solution. Maybe it's not required though.
    - tubthumper8 11mo ago
      What do you mean by "failing tests", are you talking about runtime code? TypeScript erases all types at compile so these wouldn't affect tests. Unless you meant "compile errors" instead. I've noticed LLMs just slap on "as any" to solve compile errors in TypeScript code, maybe this is common in the training data. I frequently have to call this out in code review, in many cases it wasn't even a necessary assertion, but it's now turned a variable into "any" which can cause downstream problems or future problems
      - matwood 11mo ago
        My code has tests and the LLM wrote more tests. I tell the LLM to include typing on any new code. The agent is running the test harness and checking results.
ramoz 11mo ago
The answer is typescript is a much simpler and more pleasant developer experience than any other language. These are products they need to, and often originate from, fast churn of code/features. Otherwise they’d be building these types of things in Rust.
- airstrike 11mo ago
  Surely you jest
  - ramoz 11mo ago
    I wrote the comment while waiting on a 50min rust build pipeline
    - airstrike 11mo ago
      And I wrote mine waiting for my shuttle back from the moon to Earth

It's fine but why is Js a good language for agents? I mean sure its faster than python but wouldn't something that compiles to native be much better?

by hoppp 11mo ago

It's fine but why is Js a good language for agents? I mean sure its faster than python but wouldn't something that compiles to native be much better?

AstroBen 11mo ago

It's widespread and good enough. The language just doesn't matter that much in most cases

moron4hire 11mo ago
This is one of those, "in theory, there's no difference between theory and practice. In practice, there is" issues. In their, quality software can be written in any programming language. In practice, folks who use Python or JavaScript as their application programming language start from a position of just not carrying very much about correctness or performance. Folks who use languages like Java or C#, do. And you can see the downstream effects of this in the difference in the production-grade developer experience and the quality of packages on offer in PIP and NPM versus Maven and NuGet.
- wiseowise 11mo ago
  [flagged]
  - rishabhaiover 11mo ago
    Exactly! In the Java ecosystem, your intelligence is measured by how elaborate an interface hell you can conjure just to do CRUD.
  - CharlieDigital 11mo ago
    > Nonsense. Average Java/C# is an enterprise monkey who barely knows outside of their grotesque codebase. Netflix is Java. Amazon is mostly Java. Some of the biggest open source projects in the world are Java. Unity and Godot both use C# for scripting. I don't know where you're getting the impression that Java and C# are somehow only for "enterprise monkey who barely knows outside of their grotesque codebase"
    - wiseowise 11mo ago
      > Netflix is Java. Amazon is mostly Java. Some of the biggest open source projects in the world are Java. Unity and Godot both use C# for scripting. You can add Meta, Google and Palantir to your list and it won’t change that average Java dev is from an Eastern hemisphere and knows nothing about Java outside of JavaEE/Spring. See how generalizations work?
  - mrcsharp 11mo ago
    Chill out buddy. You're going to pop a vein here. A typical backend developer using C#/Java is likely solving more complicated problems and having all the concerns of an enterprise system to worry about and maintain. Dismissing a dev or a system because it is enterprisy is a weak argument to make against a language. A language being used a lot in an enterprise to carry the weight of the business is a sign the language is actually great and reliable enough.
    - wiseowise 11mo ago
      I’m not dismissing Java, I’ve spent decades writing it and know what it is capable of, but it is laughable to hear that average Java dev cares more about performance or correctness than Python/JS dev. All of them explicitly don’t have to care about performance from the start because of VMs + GC, only when scale starts to matter you start to optimize. Tooling argument is especially funny to me, given how shit tooling ecosystem is. Sure it is ol’ reliable, but average Java dev is so stuck in their ways that they’ve never even tried to dwell out of their Java cave to see what’s out there. IntelliJ consuming ALL of RAM, literally as much as it can get hands on. Gradle taking what’s left, rebuilds taking minutes to complete or requiring elaborate setup to have proper hot reload. Both TS and Python have far more expressive and powerful type systems than even modern Java. “Production grade tooling” my ass. Funny to see Java shmucks looking down at JS/Python folks, as if Java at the time wasn’t picked for literally same reasons as Python/JS nowadays.
- AstroBen 11mo ago
  That's not a fair comparison. In your example, you're talking about the average of developers in a language. In this situation, it's specific developers choosing between languages. Having the developers you already have choose language A or B makes no difference to their code quality (assuming they're proficient with both)
  - moron4hire 11mo ago
    These are statements these developers will make themselves. They will say they don't like more strictly typed languages because they feel constrained and slowed down in development. They will argue that the performance hit is worth the trade offs.
- drzaiusx11 11mo ago
  As a developer that switches between java, python and typescript every day I think this is fairly myopic opinion. Being siloed to one lang for long enough tends to brings out our tribalistic tendencies, tread carefully. I've seen codebases of varying quality in nearly every language, "enterprise" and otherwise. I've worked at a C# shop and it was no better or worse than the java/kotlin/typescript ones I've worked at. You can blame the "average" developer in a language for "not caring ", but more likely than not you're just observing the friction imposed by older packaging systems. Modern languages are usually coupled with package managers that make it trivial to publish language artifacts to package hubs, whereas gradle for example is it's own brand of hell just to get your code to build.
- justatdotin 11mo ago
  perhaps many of those 'Folks who use languages like Java or C#' do so because a boss told them 'thats the way we deal with correctness and performance around here' the fact that their boss made that one decision for them does not somehow transmit the values behind the one decision.

chatmasta 11mo ago

JS has the fastest, most robust and widely deployed sandboxing engines (V8, followed closely by JavaScriptCore which is what Bun uses). It also has TypeScript which pairs well with agentic coding loops, and compiles to the aforementioned JavaScript which can run pretty much anywhere.

otterley 11mo ago
Note that "sandboxing" in this case is strictly runtime sandboxing - it's basically like having a separate process per event loop (as if you ran separate Node processes). It does not sandbox the machine context in which it runs (i.e. it's not VM-level containment).
- Brass_Hopper 11mo ago
  When you say runtime sandboxing, are you referring to JavaScript agents? I haven't worked all that much with JavaScript execution environments outside of the browser so I'm not sure about what sandboxing mechanics are available.
  - otterley 11mo ago
    https://nodejs.org/api/vm.html https://nodejs.org/api/vm.html Bun claims this feature is for running untrusted code (https://bun.com/reference/node/vm https://bun.com/reference/node/vm), while Node says "The node:vm module is not a security mechanism. Do not use it to run untrusted code." I'm not sure whom to believe.
    - Jarred 11mo ago
      The reference docs are auto generated from node’s TypeScript types. node:vm is better than using the same global object to run untrusted code, but it’s not really a sandbox
    - Brass_Hopper 11mo ago
      It's interesting to see the difference in how both treat the module. It feels similar to a realm which makes me lean by default to not trusting it for untrusted code execution. It looks like Bun also supports Shadow Realms which from my understanding was more intended for sandboxing (although I have no idea how resources are shared between a host environment and Shadow Realms, and how that might potentially differ from the node VM module).

aizk 11mo ago

TS is enormous, has endless training data, and can interact with virtually anything on the Internet these days. Also, strong typing is very very useful for AI coding context.

justatdotin 11mo ago
> strong typing is very very useful for AI coding context what makes you think so? I believe strong typing is very very useful for human coding, I'm not convinced its so 'very very' for agents.
- matwood 11mo ago
  When I've use agents with TS, failing tests due to typing seems to help the agent get to the correct solution. Maybe it's not required though.
  - tubthumper8 11mo ago
    What do you mean by "failing tests", are you talking about runtime code? TypeScript erases all types at compile so these wouldn't affect tests. Unless you meant "compile errors" instead. I've noticed LLMs just slap on "as any" to solve compile errors in TypeScript code, maybe this is common in the training data. I frequently have to call this out in code review, in many cases it wasn't even a necessary assertion, but it's now turned a variable into "any" which can cause downstream problems or future problems
    - matwood 11mo ago
      My code has tests and the LLM wrote more tests. I tell the LLM to include typing on any new code. The agent is running the test harness and checking results.

ramoz 11mo ago

The answer is typescript is a much simpler and more pleasant developer experience than any other language. These are products they need to, and often originate from, fast churn of code/features. Otherwise they’d be building these types of things in Rust.

airstrike 11mo ago
Surely you jest
- ramoz 11mo ago
  I wrote the comment while waiting on a 50min rust build pipeline
  - airstrike 11mo ago
    And I wrote mine waiting for my shuttle back from the moon to Earth