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

71–80 of 122 posts

Re: Oven: The Company Behind Bun

#71

Post by iainmerrick »

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…

Besides being Linux-only, the GH page lists intentional restrictions like “commonjs modules, no support for ES modules” -- that seems like a biggie!

The benchmarks seem to focus exclusively on startup time, which is certainly important but not the only important thing. (And unless I misread those tweets it’s only a tiny bit ahead of bun.)

More competition is good and helps keep everyone honest, of course, but it looks like extremely early days for this project.

Re: Oven: The Company Behind Bun

#72

Post by iainmerrick »

naikrovek wrote: post #38
latenightcoding wrote: post #3

"Oven, the company behind Bun, has raised $7m in funding" "Oven will provide incredibly fast serverless hosting & continuous integration for backend & frontend JavaScript apps" Isn't trying to dethrone node.js (by making Bun better and more popular) something worth pursuing on its own, or there is no money in that?

I am surprised every day at how much raw human effort has gone (and continues to go) into making JavaScript into a good language, when at most 1/20th of that effort could have been used to simply replace it with something that is good to begin with.

The positive interpretation is that this is an example of Gall’s law: https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law

Today’s JavaScript works because it has gradually evolved from the primordial JS which (just about) worked; at each stage in the chain it’s seen real-world usage as an in-browser language.

The alternative would be to build something better from scratch -- but that never works, says Gall’s law -- or to take some other battle-hardened language (C? Java? Python?) -- but trying to adapt those to work well in the browser would hit just as many technical and political barriers as JS did in becoming a decent general-purpose language.

Re: Oven: The Company Behind Bun

#73

Post by fizx »

hardwaregeek wrote: post #50

I have a lot of respect for Jarred and bun. The lean approach of just one person working for a year is rather underrated imo. No funding and therefore no pressure for growth. No overhead from scaling up a team and having to implement process, standards, etc. And at the same time, incredible content marketing by just tweeting about every little detail. Me and many others got hooked just because Jarred was posting inte…

I've done this solo sprint for a year to get a startup running a few times in my career.

The time it worked, I worked 10-4pm (heads down) in the ideation phase, ate well, slept well, got two hours of exercise daily, and had an interesting social life. Once the startup took on a life of its own, the personal life started to suffer and I got up to 80+hrs for a month or two before settling into ~60.

The two times it didn't work, I embraced the 60hr/week grind and was a bit more isolated, perhaps drank a bit more to unwind, and my focus deeply suffered.

I really love the solo thing, but in the early days, be creative and happy. The grind will find you. Market fit means more work. No doubt Jarred will find building a company and Bun at the same time even more challenging that just building Bun.

Re: Oven: The Company Behind Bun

#74

Post by AaronFriel »

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.

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 when the compiler's borrower checker is insufficient.

What this means is that to verify memory safety, one can restrict their search to unsafe blocks. And hypothetically if the Rust compiler were to get much smarter, it should be possible to prove to the compiler that those blocks are safe (via theorem prover, perhaps?) and remove the "unsafe" declaration.

In most languages, there is no such distinction between the "memory safe" common set users ought to use and the subset that has to be verified independently. Neither Zig, C, C++, nor even Go have a clear delineation between safe and unsafe code.

Re: Oven: The Company Behind Bun

#75

Post by AaronFriel »

rileyphone wrote: post #60
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.

Is there not a gradient though? Are C++ smart pointers equally as bad as regular old malloc? Can safer abstractions not render most buffer overflows impossible?

I misspoke. Yes, security is on a gradient and the things I've listed have caught and prevented many, many bugs, but memory safety is a binary proposition. Those things have not made C++ "memory safe".

Re: Oven: The Company Behind Bun

#76

Post by AaronFriel »

cocoto wrote: post #55
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.

There is definitely a gradient in safety and almost everybody agree with that. What is controversial is how much safety you actually need.

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

Re: Oven: The Company Behind Bun

#77

Post by throwawaymaths »

cocoto wrote: post #55
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.

There is definitely a gradient in safety and almost everybody agree with that. What is controversial is how much safety you actually need.

And it's not clear that safety has to be in the compiler: it could be in a static analysis tool, for example.

Re: Oven: The Company Behind Bun

#78

Post by AaronFriel »

Jarred wrote: post #64
AaronFriel wrote: post #31

It's an incredible achievement, though I worry about the use of an unproven language (Zig) that lacks memory safety by design. JavaScript runtimes, especially those with JITs, have been plagued by vulnerabilities from memory safety, type confusion, and data races. Node.js, despite being based on V8, is still susceptible independently of V8 and introduces its own vulnerabilities. It's not sufficient for the runtime to…

> 1. Will Oven adopt a security policy for Bun? ( https://github.com/oven-sh/bun/security ) Yes. > 2. What measures is Oven taking to proactively detect and mitigate vulnerabilities? (e.g.: fuzzing, audits, bug bounties) Fuzzing will begin soon. Regular security audits will happen around the 1.0 release. Bug bounty seems like a good idea, but it's too early today to know when this will start. > 3. Will Oven support Z…

Thanks for answering Jarred, and I appreciate your answers given the early stage you're at. Runtime diversity in Node is quite exciting, and I'm sure you've more interesting challenges ahead than just security.

I look forward to seeing what you can make of it with Oven.

Re: Oven: The Company Behind Bun

#79

Post by lucakiebel »

10000truths wrote: post #41
lucakiebel wrote: post #28

Earlier quoted context omitted.

I feel like there’s two reasons why I don’t understand your comment at all. Either you made a pun somewhere in there that just went way over my head, or it’s way too early for me to be up. But I have no idea what „of in the cold food of out hot eat the food“ could mean

It’s a reference to a meme: https://knowyourmeme.com/memes/why-do-they-call-it-oven

Wow, thanks for enlightening me!

Re: Oven: The Company Behind Bun

#80

Post by _vufv »

tsujp wrote: post #54

While obviously extremely impressed with Bun and Jarred's achievement (especially because I really like Zig being similar to C) I'm also shocked that he was able to get a 3-letter `.sh` domain (bun) _and_ a 4-letter `.sh` domain (oven) both real words! Looked to me that Oven was registered shortly after Bun exploded in popularity.

Don't be shocked. There are plenty of short domains left for grab, they're just expensivish for most people (usually $100 - $1000 but could be more). Glad that's the case, otherwise squatters would've "invested" into them already.
Post reply on HN