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

Was Rust Worth It?

jsoverson.medium.com

Post reply on HN
Print view View original

221–230 of 736 posts

Re: Was Rust Worth It?

#221

Post by chungy »

Grimburger wrote: post #150
chungy wrote: post #2

Perhaps my biggest critique is that crates.io has no namespacing. Anyone can just claim a global and generic package name and we mostly have to deal with it (unless you avoid using the crates.io repository, but then you'll probably have more problems...). Some of these globally-claimed generic packages are not really the best package to use. Maybe it was a reaction against the Java-style reverse DNS notation, which i…

Yet to see any proof that namespacing has made things better in other ecosystems, are go style links or other types of namespaced imports any less prone to supply chain risks? It's definitely a good thing that people choose new unique names for crates rather than dijan/base64 vs dljan/base64 Do understand the desire of having a crate for audio manipulation called "audio" but at the same time how often do we end up wi…

> Yet to see any proof that namespacing has made things better in other ecosystems

It's really as simple as this: many libraries are generic enough implementing something that already exists. Let's say you want a library to manage the SMTP protocol. On crates.io, of course someone has already taken the "smtp" crate (ironically, this one is abandoned, but has the highest download counts, because it's the most obvious name). Let's say you disagree with the direction this smtp crate has gone, and you make your own. What do you call it?

Namespaces solve this problem. You'd instead of have user1/smtp and user2/smtp competing in feature sets. You can even be user3/smtp if you don't like the first two.

This is precisely what Java enables too. The standard library is in com.java.*; if you don't like how the standard library does something, you can make com.grimburger.smtp and do it yourself. If you choose to publish to the world, all the more power to you. It doesn't conflict with the standard library's smtp implementation.

Re: Was Rust Worth It?

#222

Post by thayne »

chungy wrote: post #2

Perhaps my biggest critique is that crates.io has no namespacing. Anyone can just claim a global and generic package name and we mostly have to deal with it (unless you avoid using the crates.io repository, but then you'll probably have more problems...). Some of these globally-claimed generic packages are not really the best package to use. Maybe it was a reaction against the Java-style reverse DNS notation, which i…

> Some of these globally-claimed generic packages are not really the best package to use.

Or it is just a placeholder from a squatter.

Re: Was Rust Worth It?

#223

Post by trealira »

bjourne wrote: post #215
throwaway914 wrote: post #7

I feel like Rust finally broke the idea that programmers should be in complete control and completely conscious of everything the compiler is doing. It hasn't been that way in decades, compilers are freaking magic. But Rust undid a lot of that with borrowing. People became comfortable with the compiler knowing better than them. I just wish we could relax further: We should never be explicitly iterating forward over a…

That's the approach Haskell took. Didn't work since they didn't realize that waiting for your program to respond is a pretty effing huge side effect.

It has unpredictable performance because of lazy evaluation. Other high-level functional programming languages like OCaml, Standard ML, and Scheme can be compiled and achieve fairly high performance.

Re: Was Rust Worth It?

#224

Post by oconnor663 »

trealira wrote: post #220
oconnor663 wrote: post #197

Earlier quoted context omitted.

I should've said "stabilized" instead of "standardized" to avoid stepping on this conversational landmine. But an important practical difference is that Rust supports inline assembly on Windows. (Correct me if I'm wrong, but I think MSVC mostly does not support inline asm.)

It does support inline assembly [1]. However, it's different than the way GCC supports inline assembly. It seems nicer, TBH. [1]: https://learn.microsoft.com/en-us/cpp/assembler/inline/inlin...

From that source:

> Inline assembly is not supported on the ARM and x64 processors.

Re: Was Rust Worth It?

#225

Post by CGamesPlay »

sunshowers wrote: post #79

Programming in Rust is really not like being in an abusive relationship. The compiler is trying to help out as much as possible, especially since rustc has the best error messages in the world.

> The compiler is trying to help out as much as possible, especially since rustc has the best error messages in the world.

Generally good, but man do I hate how any error in my async function causes every recursive call site to generate an error about how the Future is no longer Send and Sync. Literally an entire console scrollback of errors with the actual syntax error buried somewhere in the middle.

Re: Was Rust Worth It?

#226

Post by tootie »

WatchDog wrote: post #109
chungy wrote: post #2

Perhaps my biggest critique is that crates.io has no namespacing. Anyone can just claim a global and generic package name and we mostly have to deal with it (unless you avoid using the crates.io repository, but then you'll probably have more problems...). Some of these globally-claimed generic packages are not really the best package to use. Maybe it was a reaction against the Java-style reverse DNS notation, which i…

Maven and Java really don’t get enough credit for how well it’s dependency management works. So many inferior dependency management systems for other languages have come along later, and learned nothing from those that came before it.

100% agree. It's unbelievable what a PITA it is dealing with pip or npm compared to Maven even 10 years ago. The descriptors could get convoluted but you could also edit them in an IDE that knew the expected tokens to make things happen.

Re: Was Rust Worth It?

#227

Post by riku_iki »

jowea wrote: post #178
MereInterest wrote: post #51

Earlier quoted context omitted.

I’m not sure. Looking through different Rust libraries, I tend to see three different styles, depending on previous programming experience. Each mimics the prior experience, with benefits. * Everything is a struct with concrete types. This is closest to C. It benefits from the improved memory safety, without sacrificing speed. * Everything is a Box >. This is closest to dynamic garbage-collected languages, but with v…

> * Everything is a Box >. This is closest to dynamic garbage-collected languages, but with vastly improved performance. Wait, reference counting everything all the time is faster than normal garbage collection?

I think more importantly it is reference counting across threads, meaning mutexes and breaking memory barrier with large performance penalty.

Re: Was Rust Worth It?

#228

Post by speed_spread »

baby wrote: post #126
WatchDog wrote: post #109

Earlier quoted context omitted.

Maven and Java really don’t get enough credit for how well it’s dependency management works. So many inferior dependency management systems for other languages have come along later, and learned nothing from those that came before it.

Is this a joke?

Having tried Java and other languages, no, it's not a joke. Other than XML Maven got a lot of things right.

Re: Was Rust Worth It?

#229

Post by trealira »

estebank wrote: post #137
Someone1234 wrote: post #90

Earlier quoted context omitted.

> A good C compiler does this when you turn on all the flags. I like languages/compilers that let you selectively disable the screaming and let you write bad code on purpose. Bad code that works but can be written fast is often better than perfect code that takes forever to write. Once you have a bad but working POC, you can make it less bad. Rust supports that. Just mark everything unsafe.

That doesn't really work. All unsafe lets you do is dereference pointers or call unsafe functions. That's not gonna speed your development up during prototyping. You can instead wrap everything in Arc > and .clone() liberally, though.

It will work if you only use raw pointers everywhere, like it's C. Don't use slices or strings; just pass a pointer to the first element of an array, and either pass its length separately or provide a sentinel value (like C's null terminated strings). Navigate balanced search trees using aliasing, raw, mutable pointers. Etc. This person compares the translation of C to Rust, literally versus idiomatically: https://cliffle.com/p/dangerust/

There will probably be weird behavior, though, because Rust optimizes based on assumptions about boxes and references. For example, if you have 3 raw pointers to some object live at once, and you give some library function a mutable reference made from one of those pointers, the compiler will optimize assuming it has exclusive access to that object, and it may make incorrect assumptions.

Re: Was Rust Worth It?

#230

Post by epage »

> It also looks like (soon) you’ll finally be able to configure global lints for a project. Until now, you had to hack your solution to keep lints consistent for projects. In Wick, we use a script to automatically update inline lint configurations for a few dozen crates. It took years for the Rust community to land on a solution for this, which brings us to…

Wow, as the author of that feature, I'm surprised to see someone was so passionate about it. I've found that many times I've been having to tell people why they should care about it.

> I don’t know why. Maybe the pressure to maintain stable APIs, along with Rust’s granular type system, makes it difficult for library owners to iterate. It’s hard to accept a minor change if it would result in a major version bump.

There is a tension between people wanting features and people not wanting to deal with version bumps. I've seen this a lot in maintaining clap, especially when it went from unmaintained for years to having active releases.

As for cargo, the compatibility guarantees are tough. Take the lints table. We can't throw in a first try, knowing we can fix in in a cargo 2.0. We are tied into the rust project itself which means we have the same compatibility guarantees. This is one reason we generally encourage trying ideas out in third-party plugins before we integrate them in directly since they can break compatibility.

> You can’t even publish a crate that has local dev dependencies

You can; cargo automatically strips them. However, if you tell cargo that there is a version of it in the registry (by setting the version), then it must be published. This is why when I redesigned `cargo add` for being merged into cargo, I made it so `cargo add --path ../foo --dev` will not add the `version` field. We do need to find ways to clarify that the purpose of the version field is for looking it up in the registry.

Allowing the dev dependencies to be stripped also helps with issues of circular dev-dependencies.

> However, many developers break large projects down into smaller modules naturally, and you can’t publish a parent crate that has sub-crates that only exist within itself.

We do have an RFC for this: https://github.com/rust-lang/rfcs/pull/3452

The most complex part is the Index, figuring out how to represent it in the metadata tables we maintain so we avoid having to download every `.crate` file.

I also worry there might be tech debt around assumptions of there being a single version of a package when nested packages will easily break that.

> You can see the problem manifest in the sheer number of utility crates designed to simplify publishing workspaces. Each works with a subset of configurations, and the “one true way” of setting workspaces up still eludes me. When I publish Wick, it’s frequently an hour+ of effort combining manual, repetitive tasks with tools that only partially work.

I'm a bit confused on this point. While there are things to improve around publishing workspaces, I'm not sure how this relates to setting workspaces up or what problems they've had with that. I'd also be curious what problems they had with releasing packages. I don't think I've seen issues from them in cargo-release's Issues.

Post reply on HN