Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oven: The Company Behind Bun

oven.sh

Post reply on HN
Print view View original

101–110 of 122 posts

Re: Oven: The Company Behind Bun

#101

Post by geodel »

1shooner wrote: post #21
behnamoh wrote: post #8

I love these funny names. First time I introduced HomeBrew to my gf, she was all laughing at the funny terms: keg - Program binaries created from source bottle - Program binaries downloaded cellar - Directory where kegs / binaries are stored tap - git repository cask - macos native binary (not used in Linux)

Ok, but I'm not really looking to my package manager for entertainment. To me this jargon is just needlessly obtuse.

I mean in a way its right. One then need to go for professional companies, sign profession contracts, pay professional service fee and real professional sounding software

Re: Oven: The Company Behind Bun

#102

Post by indymike »

b_fiive wrote: post #57
alberth wrote: post #42

My moneys on Just-JS. It’s consistently in the top 5 fastest web framework (beating out Rust, etc). Just-JS is already faster than Bun. Additionally, JSCore appears to be a significant reason why Bun is faster than NodeJS (V8). Just-JS is investigating switching to JSCore as well - which will only extend its lead. https://github.com/just-js/just https://www.techempower.com/benchmarks/#section=data-r21 https://twitter…

Linux only? I think that'll cap adoption regardless of any perf advantages

> Linux only? I think that'll cap adoption regardless of any perf advantages

For web applications, Linux is usually the eventual development target, and running Linux development environments on Windows and MacOS is a solved problem. So no, not really going to be much of a problem.

Re: Oven: The Company Behind Bun

#103

Post by lioeters »

tantalor wrote: post #100
mwexler wrote: post #96

For those like me who didn't know: https://bun.sh/ . "Bun is a fast all-in-one JavaScript runtime. Bundle, transpile, install and run JavaScript & TypeScript projects — all in Bun. Bun is a new JavaScript runtime with a native bundler, transpiler, task runner and npm client built-in."

"Run TypeScript" is misnomer, unless I'm missing something, it compiles TS -> JS and "runs" that.

"Run JavaScript" is a misnomer, it compiles JS -> bytecode and "runs" that.

Re: Oven: The Company Behind Bun

#104

Post by seanw444 »

lioeters wrote: post #103
tantalor wrote: post #100

Earlier quoted context omitted.

"Run TypeScript" is misnomer, unless I'm missing something, it compiles TS -> JS and "runs" that.

"Run JavaScript" is a misnomer, it compiles JS -> bytecode and "runs" that.

"Run bytecode" is a misnomer, it compiles bytecode -> machine code and "runs" that.

Re: Oven: The Company Behind Bun

#105

Post by naikrovek »

AaronFriel wrote: post #74
naikrovek wrote: post #69

Earlier quoted context omitted.

the entire language is partially implemented yet you are judging it as if it is complete and set in stone. Rust isn't even memory safe if you want to be THIS pedantic about it. the unsafe keyword exists in Rust, and it is often used.

Unsafe is perhaps poorly named, and several Rust core team members have commented as such. It doesn't mean memory unsafe, it means "not checked by the compiler". Safe APIs that contain unsafe blocks must still be proven correct, via Miri, a model checker, formal proof, etc. Any safe functions that violate memory safety are considered bugs. The limited number of unsafe functions exist as helpers to build safe APIs whe…

> Unsafe is perhaps poorly named, and several Rust core team members have commented as such. It doesn't mean memory unsafe, it means "not checked by the compiler".

That's lack of memory safety when your memory safety work is done during compilation, as is the case with Rust.

Re: Oven: The Company Behind Bun

#106

Post by brundolf »

nicoburns wrote: post #84
brundolf wrote: post #10

Earlier quoted context omitted.

I'm curious about where all that performance comes from I know it uses the WebKit JS runtime instead of V8, which is super interesting. Does that cause a performance lift? Or is there some other secret sauce that pervades throughout Bun? Or is it just a matter of Jarred giving lots of attention to spot-optimizing the most important bottlenecks outside of the core runtime?

It's worth noting that most of Node's API are written in JavaScript, and often not particularly optimised JavaScript (sometimes constrained by API compatibility). I think bun is taking the approach of implementing a lot of core APIs in zig.

That's surprising, I didn't know that about Node

Re: Oven: The Company Behind Bun

#107

Post by cheeselip420 »

seanw444 wrote: post #104
lioeters wrote: post #103

Earlier quoted context omitted.

"Run JavaScript" is a misnomer, it compiles JS -> bytecode and "runs" that.

"Run bytecode" is a misnomer, it compiles bytecode -> machine code and "runs" that.

"Runs machine code" is a misnomer, the CPU will translate machine code to microcode and "run" that.

Re: Oven: The Company Behind Bun

#108

Post by AaronFriel »

_vvhw wrote: post #97
AaronFriel wrote: post #76

Earlier quoted context omitted.

I misspoke, there is a gradient in safety, but "memory safe" is binary.

There is in fact a spectrum with respect to memory safety. For example, temporal vs spatial safety. Furthermore, no language is “memory safe” in the absolute sense. For example, not even the borrow checker can protect you from buffer bleeds.

Despite the "How Safe is Zig"[1] blog post, it's false that there is a spectrum. A lack of temporal safety implies a lack of spatial safety, and vice versa.

If one can use a use-after-free, invalid write, time of check-time of use error to write a byte to an invalid location, the program's data structures are now in an inconsistent state, violating invariants required for "spatial safety" such as objects being the correct type, buffers and lengths being paired together correctly, etc.

Likewise, if one can accomplish a buffer overflow, a spatial safety violation, or an out of bounds write, then by definition they've made temporal violations as well. Writing objects out of bounds or arbitrary heap writes imply data races.

Offensive security folks use gadgets that exploit one to accomplish the other, as needed.

[1] https://www.scattered-thoughts.net/writing/how-safe-is-zig/

Re: Oven: The Company Behind Bun

#109

Post by ksec »

naikrovek wrote: post #69
AaronFriel wrote: post #46

Earlier quoted context omitted.

I'm afraid "partially implemented" memory safety is also widely known in the offensive security industry as "not memory safe". Many people have fooled themselves into thinking there is a gradient with safer C++ abstractions, libraries in C, custom allocators, static analyzers, valgrind, etc.

the entire language is partially implemented yet you are judging it as if it is complete and set in stone. Rust isn't even memory safe if you want to be THIS pedantic about it. the unsafe keyword exists in Rust, and it is often used.

Last time an Open Source project was using UnSafe it was getting attacked by Rust Evangelism Task Force.

Re: Oven: The Company Behind Bun

#110

Post by _vvhw »

AaronFriel wrote: post #108
_vvhw wrote: post #97

Earlier quoted context omitted.

There is in fact a spectrum with respect to memory safety. For example, temporal vs spatial safety. Furthermore, no language is “memory safe” in the absolute sense. For example, not even the borrow checker can protect you from buffer bleeds.

Despite the "How Safe is Zig"[1] blog post, it's false that there is a spectrum. A lack of temporal safety implies a lack of spatial safety, and vice versa. If one can use a use-after-free, invalid write, time of check-time of use error to write a byte to an invalid location, the program's data structures are now in an inconsistent state, violating invariants required for "spatial safety" such as objects being the co…

Thanks, that's a great insight!

Does it follow that the fact that temporal violations could be used to violate runtime spatial checks, therefore means that spatial safety in itself is entirely without value?

What are your thoughts also on buffer underflows? I ask since I take it you also work on offensive security.

Post reply on HN