likeabbas

That's an elitist mindset

I don’t understand why you want people to be afraid of code though. It’s just code. We don’t need a scary connotation to make people think they should shoot for completely compiler verifiable rust in every line they can write.

But it’s the true definition being stated. Unsafe is subjective, compiler unverifiable isn’t

`compiler_unverifiable` isn't risky enough for you?

I think the incentive to write compiler verifiable Rust would be the same as safe Rust, but with less fear for the situations where you do need to bypass the borrow checker such as with cyclical references in graphs (currently doing this right now by re-writing a basic NN in Rust). Even the standard library uses unsafe for certain situations.

I think `unsafe` would have been more aptly named `compiler_unverifiable`. IMO there would be less apprehension to using `unsafe` when it's needed.

Mozilla may have one path, albeit a long shot. If Apple were to decide that it’s cheaper to give money to Mozilla and have FF be the default iOS browser, that would be their best shot for success. Or maybe Apple could buy out Mozilla entirely. This scenario isn’t likely but I don’t think it’s completely out of the question.

A bail out for the Bay Area. Should’ve just let them bust tbh

ByteDance seems to be putting out a lot of open source Rust libraries (e.g. Monoio). How widely used is Rust within the company?

I am so happy I don't have to touch front end code for my career

On the other side, I have dealt with several merchants who wrote down my debit/credit card numbers and would charge me after I cancelled (specifically several fitness gyms). So I am very happy that chargebacks are in place.

That's a good point.

> I usually find myself wishing I could have some macro where I just write in C and have it exposed as an unsafe back in Rust.

There’s a macro for doing this with Assembly, I can imagine one could be made for C. But why wouldn’t you just write unsafe rust at that point?

A company makes millions of dollars through 4 servers running python?

Name one company that runs 4 servers of ruby and earns millions per year

I guess "successful startup" doesn't equate to "scale" ?

Why do people keep misreading what I'm saying. The argument is specifically for WHEN YOU REACH SCALE

Agreed. Although I like Rust and modern Java too.

> What proof is there that companies built on dynamic typed languages struggle with server costs

The proof is in the limitations of the language. If you have a 4 CPU server and you want to run a web application, you would be able to process far more transactions per second in a Java or Go application than Ruby. This is because Ruby has a GIL which means it can't truly multithread, so to get parallelization you need to multiprocess. These days kernels can spawn threads in 5ms (or with Green threads that can be in nanoseconds), but a new process takes 50ms to spawn. Then, there's the issue of Garbage Collection pauses. Java is one of the best with some very low latency (<10ms) GCs. Ruby far from the state of the art GCs. Then there's the runtime, which Ruby can be 10-100x slower than Java or Go.

It's just a matter of this logic being scaled to big levels

I'm not moving goal posts. I never said you could not be successful with ruby. All I'm saying is that once you hit scale, you would have an easier time cutting costs in a language that could better utilize less infrastructure and thus lowering your operating costs.

You can’t scale Ruby to <25ms which is important for some businesses where every 10ms is millions in lost processing

You edited your response. How many of those companies are profitable?

I'm not saying it's not possible to build a successful start up with the language. My argument is just that the language can become a major expense and limiting factor once you reach scale. Many programmers know multiple languages, and if they have a choice then it may be wise to opt for a language that could help you avoid some of these problems later.

No it's not. You would objectively be better off in Java or Go than Ruby once you reach scale. Java and Go can truly utilize multi-core threading, and have superior garbage collectors. This matters a lot for latency requirements

Once you reach scale, Ruby can be a limiting factor depending on how much latency impacts your revenue. And it's not so easy to remove that dependency as I've seen.

Your argument is based on a fallacy that you can build something faster in a dynamic language than a typed one. IMO that argument fails when you need to onboard new people to read the codebase and contribute to it. I'd argue you will be able to onboard people faster to a typed codebase than a dynamic one. And for me personally, I don't see a difference in my ability to produce code between Java/Go and a dynamically typed language.

The majority of people laid off were hired in 2021 (including myself), and then 2022. There was a graph posted to Blind before we lost access

I learned there that if you build a successful startup on Ruby, your infrastructure costs are going to be insanely high trying to make it scale and you'd be better off using a typed language with true multithreading and a solid GC.

It's all about the load though. SO is probably 95% Read-Only which makes sense for removing the cache layer. If you had a more writes, then they would need an external cache to offset the read load.

Thanks man. Been battling weight issues my whole life. It's just about focus on eating well, drinking less, and working out more and the weight comes off on its own.