Live data from Hacker News

Was Rust Worth It?

jsoverson.medium.com

651–660 of 736 posts

Re: Was Rust Worth It?

#651
post #354

Earlier quoted context omitted.

The left pad issue was kind of wild coming from the enterprise Java space. Supply chain attacks against open source software were already being taken pretty seriously, my last company had it's own Maven repository manager running that was used to stage and vet packages before they could be used in production.

I don't think the left-pad problem wasn't about package namespacing it was about the ability to unpublish packages as well the prevalence of micropackages caused by lack of a decent standard library. Also npm's bad policy/decision to transfer control of package in the name of predictability(this should probably be avoided for packages that aren't malicious. You could argue for seizing broken/trivial and unmaintained…

> I don't think the left-pad problem wasn't about package namespacing it was about the ability to unpublish packages as well the prevalence of micropackages caused by lack of a decent standard library.

It was "about" cavalier approach to the dependency supply chain. A dependency disappearing outright is just one of many failure modes it has.

Re: Was Rust Worth It?

#652

> I am a massive proponent of test-driven development. I got used to testing in languages like Java and JavaScript. I started writing tests in Rust as I would in any other language but found that I was writing tests couldn’t fail. Once you get to the point where your tests can run – that is, where your Rust code compiles – Rust has accounted for so many errors that many common test cases become irrelevant. I wonder w…

When writing in loosely typed languages, some folks aim for 100% line coverage, to make it more feasible to refactor down the line. Which then of course ends up being a lot of tests for fairly basic stuff that the type system could help you with...

I think such tests are pretty useless regardless of language. If you work on say a banking system testing whether getBankingStatement() returns something of type string is a waste of time. It just slows you down when you refactor its return value to a BankingStmt instance. While testing what happens in low memory conditions when a user simultaneously deposits and withdraws while another user issues a charge back against them is extremely useful.

Re: Was Rust Worth It?

#653

Earlier quoted context omitted.

> just that they were following the overwhelming majority of mainstream languages at the time. They were trying to do better than mainstream languages in other areas and succeeded. IIRC on this front they just decided Ruby's bundler was the bee's knees.

The same developer who worked on bundler also worked on the initial version of cargo. That’s why they’re similar. And at that time, it was a good idea. Ruby was popular and bundler + gem ecosystem was a big reason for its popularity. No one was worried that Rust might become so popular that it might outgrow the bundler model. That was only a remote possibility to begin with.

A mistake that many programmers make, as if baking one more feature on top would have made any difference that wouldn't be amortized in just a few weeks... Sigh.

Re: Was Rust Worth It?

#654
post #646

Earlier quoted context omitted.

> Rust's type system forces you to deal with the problem early on and saves time towards the end. It's not like that's impossible with Python with addons like mypy. Definitely not - mypy's pretty good these days, and lots of people use it. > But Rust's type system goes beyond just data types - lifetimes are also a part of the type system. I don't know how you can tack that on to Python. Well, Python's objects are gen…

Lifetime analysis matters a lot for way more than just garbage collection. File handles, iterators, mutex guards, database transaction handles, session types, scoped threads, anything where ordering or mutual exclusivity matters.

I don't know about all of those, but Python's context managers and built in constructs handle most of those, I think?

Re: Was Rust Worth It?

#655

Earlier quoted context omitted.

They reduce the risk of supply chain attacks like typo squatting or Dependency confusion.

Namespaces can't be typosquatted?

I don't believe I said that.

The point is that it's much easier to make a mistake typing "requests" than " org.kennethreitz:requests" (as a pure hypothetical.)

It also means that more than one project can have a module called "utils" or "common", which once again reduces the risk of people accidentally downloading the wrong thing.

Re: Was Rust Worth It?

#656
post #231

I wrote a lot of rust, but after some years it still feels unproductive. I do a lot of zig now and I am like 10 times more productive with it. I can just concentrate on what I want to code and I never have to wonder what tool or what library to use. I know rust gives memory safety and how important that is, but the ergonomic is really bad. Every time I write some rust I feel limited. I always have to search libraries…

Give Copilot a try, it completely shift coding experience in Rust. Especially this:

> I always have to search libraries and how to do things.

Once you pass the initial curve with crutch like Copilot, then you can be almost as productive (if not more, considering refactoring and testing) with your native first coding language

Re: Was Rust Worth It?

#657

Earlier quoted context omitted.

These are two issues, which a theoretically orthogonal but in practice not so much. These are known as soundness and completeness. A good talk on topic [1] Rust will reject a lot of sound programs, and that's a huge performance hit. You are hitting the incompleteness wall with multiple mutable borrowing, closures in structures are a huge source of pain as well. And usually the answer from the community is "use handle…

Can you give us examples, please? I use Rust since version 1.0, and I like it a lot.

Cyclic data structures are impossible to represent in safe Rust because there is no clear "owner" in a cyclic data structure.

Re: Was Rust Worth It?

#658
post #487

Earlier quoted context omitted.

The problem with C and to C++ is that it’s 2023 and the CVE list is still loaded with basic memory errors. These come from everywhere too: small companies and open source all the way up to Apple, Microsoft, and Google. We as a profession have proven that we can’t write unsafe code at scale and avoid these problems. You might be able to in hand whittled code you write but what happens when other people work on it, it…

I think nobody is arguing the need for static memory safety, just that the poor Rust ergonomics aren't a good tradeoff, especially for scenarios where C is useful. We need many more Rust alternatives that explore into different directions, Rust is already too big and "established" for any radical changes in direction.

When the pendulum swings it often swings far before normalizing somewhere in the middle. I agree that Rust isn't the answer.

FWIW there is interest in adding bounds checking to C [1]. That discussion includes feedback from at least one member of the C standards committee.

[1] https://discourse.llvm.org/t/rfc-enforcing-bounds-safety-in-...

Re: Was Rust Worth It?

#659

I've tried it a few times and it has great features on paper but to use it gets in your way too much. I can spin up a C# dotnet project write and test the code 10 times faster than in Rust. It might not perform as fast but the hot code can be written in a small C library using code/runtime analysis tools to catch any memory safety issues.

A note on putting the hot path into C component: Writing performance-sensitive code in C/C++ and calling it via interop used to be the way to go during .NET Framework days but since then has become a performance trap. Especially for small methods, calling them through interop is a deoptimization because they cannot be inlined, and involve GC frame transition (which you can suppress) as well as an indirect jump and ma…

Thanks, I haven't had to do dropping to C for a while as the improvement in performance of dotnet along with features like AOT, Span etc close the gap enough for the domain I work in.

Good to know you can remain within the framework and get decent performance though with the unsafe pointers/refs. Would be interesting to see a good benchmark using only C# with latest features and Rust, although I cognisant of the fact there is more to it than pure performance (binary size, dependencies, GC etc).

Re: Was Rust Worth It?

#660

Earlier quoted context omitted.

IMHO Rust's ergonomics problems aren't caused by the borrow checker itself, but have the same cause as similar problems in C++ (mainly a "design by committee" approach to language design and implementing features that should be language syntax sugar in the stdlib instead, which then directly results in the stdlib being too entangled with the language and "too noisy" hard to read code). Apart from the static memory sa…

I agree with this. The borrow checker itself isn't the problem. That's necessary to make you write correct and safe code anyway. The problem is that there is too much syntax, too many symbols, and too many keywords. I just keep forgetting how to use impl and lifetimes and single quotes and whatnot. It makes it really tough to use as an occasional language. And if I can't do that, then how can I get confident enough t…

Maybe Lobster could be an option.

https://strlen.com/lobster/

https://aardappel.github.io/lobster/memory_management.html

It uses compile-time reference counting / lifetime analysis / borrow checking. Which is mostly inlined to the point that there is none of the sort in the compiled output and objects can even live on the stack. It basically looks like Python but is nothing like it underneath, and of course with no GIL. You can run it on JIT or compile it to C++.

There's also Koka with the Perceus algorithm on compile time and looks like a much cleaner language than Rust. It also tracks side effects of every function in a type where pure and effectful computations are distinguished.

https://github.com/koka-lang/koka

Post reply on HN