4 ms·

This seems to achieve a similar type safety<->complexity tradeoff as Gleam [1] does. However, Gleam compiles to Erlang or JavaScript, which require a runtime an

This seems to achieve a similar type safety<->complexity tradeoff as Gleam [1] does. However, Gleam compiles to Erlang or JavaScript, which require a runtime and are not as performant as Go. I wonder if Borgo's compiler messages are as nice as Rust's/Gleam's, though. [1] https://gleam.run/ https://gleam.run/

ffsm8 2y ago
> are not as performant as Go. Ymmv, you might be surprised if you actually bothered to benchmark. Depending on the workload, either JS or erlang can ultimately turn out on top. They're all optimized to a degree that each has a niche it excells at and leaves the others in the dust. even with heavily scewed benchmark like techempower fortunes (https://www.techempower.com/benchmarks/#hw=ph&test=fortune&section=data-r22 https://www.techempower.com/benchmarks/#hw=ph&test=fortune&s...) you end up with JS getting ahead of Go with raw requests. And not just slightly, but by 1.5 times the throughput. In other benchmarks, Golang does indeed win out with similar or even bigger advantages... so the only thing you can ultimately say is ... that it depends. Its a different story if you chose other languages though. But JS, Golang and Erlang are all extremely optimized for their ideal usecase.
- lolinder 2y ago
  I'd add Java to that list as well. JIT compilers have come a long way, and OpenJDK was on par with Rust for performance on the last project I tried porting.
- hombre_fatal 2y ago
  Well hold on a second. The JS impl that you're talking about uses a minimal custom runtime (https://github.com/just-js/just https://github.com/just-js/just) that you would never use—it barely implements JS. It's basically only used for this benchmark. It doesn't make sense to compare that to Go when we're talking about Javascript vs. Go performance. Scroll down to the "nodejs" entry for a more realistic comparison.
  - ffsm8 2y ago
    Feel free to switch to json serialization and the the same pattern repeat with uwebsockets.js. I'm not saying that JS is "just as fast as golang" generally. My argument is specifically that it's optimized to a degree that there are cases in which JS, an interpreted language, does end up on top. The same applies to erlang and it's optimization for efficient concurrency. On average you'll likely get better performance with go, but depending on the workload the results can differ

ffsm8 2y ago

> are not as performant as Go. Ymmv, you might be surprised if you actually bothered to benchmark. Depending on the workload, either JS or erlang can ultimately turn out on top. They're all optimized to a degree that each has a niche it excells at and leaves the others in the dust. even with heavily scewed benchmark like techempower fortunes (https://www.techempower.com/benchmarks/#hw=ph&test=fortune&section=data-r22 https://www.techempower.com/benchmarks/#hw=ph&test=fortune&s...) you end up with JS getting ahead of Go with raw requests. And not just slightly, but by 1.5 times the throughput. In other benchmarks, Golang does indeed win out with similar or even bigger advantages... so the only thing you can ultimately say is ... that it depends. Its a different story if you chose other languages though. But JS, Golang and Erlang are all extremely optimized for their ideal usecase.

lolinder 2y ago
I'd add Java to that list as well. JIT compilers have come a long way, and OpenJDK was on par with Rust for performance on the last project I tried porting.
hombre_fatal 2y ago
Well hold on a second. The JS impl that you're talking about uses a minimal custom runtime (https://github.com/just-js/just https://github.com/just-js/just) that you would never use—it barely implements JS. It's basically only used for this benchmark. It doesn't make sense to compare that to Go when we're talking about Javascript vs. Go performance. Scroll down to the "nodejs" entry for a more realistic comparison.
- ffsm8 2y ago
  Feel free to switch to json serialization and the the same pattern repeat with uwebsockets.js. I'm not saying that JS is "just as fast as golang" generally. My argument is specifically that it's optimized to a degree that there are cases in which JS, an interpreted language, does end up on top. The same applies to erlang and it's optimization for efficient concurrency. On average you'll likely get better performance with go, but depending on the workload the results can differ