News for hackers. Stuff that matters.
[dead]
Re:Why Discord is switching from Go to Rust by echelon on Tuesday February 04, 2020 @07:45PM (#22242900)
I write Java during the day but wish I could write Rust instead.

Rust has a much nicer standard library, and the semantics and abstractions are so incredibly beautiful. It's a language that has learned from the millions of human-years that went into other languages and ecosystems. Every corner and seam in the language design speaks to this.

Traits, union type enums, pattern matching, option and result types, derive(), error handling semantics - it's all incredibly intuitive and expressive.

If I had a choice to write Rust everywhere, I would.

Re:Why Discord is switching from Go to Rust by millstone on Tuesday February 04, 2020 @08:45PM (#22243243)
Rust has its share of random-feeling nonsense, like requiring PhantomData to "work around" unused type params, or that you can't compare arrays longer than 32 elements.
Re:Why Discord is switching from Go to Rust by gridspy on Tuesday February 04, 2020 @09:07PM (#22243348)
1. I've never had to use PhantomData since I started coding in rust pretty much fulltime 2 years ago. 2. You can compare arrays longer than 32, but the compiler will no longer create an automatic comparison for you. So it's not that you "can't" do it. -- That said, using == to compare >32 elements sounds inefficient, perhaps check your use-case?
Re:Why Discord is switching from Go to Rust by Jweb_Guru on Wednesday February 05, 2020 @02:57AM (#22244841)
It's not really a workaround (it didn't used to be required), it asks for PhantomData so it can figure out variance and infer auto traits.
Re:Why Discord is switching from Go to Rust by xmprt on Tuesday February 04, 2020 @09:39PM (#22243511)
Not comparing arrays longer than 32 elements by == sounds like a feature to me.
Re:Why Discord is switching from Go to Rust by millstone on Tuesday February 04, 2020 @10:02PM (#22243631)
The 32-count cliff is not just for Eq - it also defeats niceties like Debug, Hash, Default. This isn't a deliberate design decision, it's due to a (current) limitation of Rust's value-type generics.

The point is to illustrate that when you WTF using Rust, sometimes it's not you, it really is Rust.

Re:Why Discord is switching from Go to Rust by ElderKorihor on Tuesday February 04, 2020 @11:33PM (#22244055)
I think there are a few places were Rust didn't get it quite right, but this seems like a weird example. The 32 length limit is a temporary limitation, not a corner that Rust is painted into. Indeed, my understanding is that the limitation at this point is being maintained artificially due to an overabundance of caution (via https://doc.rust-lang.org/std/array/trait.LengthAtMost32.htm... ). That's not WTF, that's just TODO.
Re:Why Discord is switching from Go to Rust by lumost on Tuesday February 04, 2020 @10:46PM (#22243830)
A great example of this can be seen writing any recursive data-structure such as a doubly linked list.
Re:Why Discord is switching from Go to Rust by adamnemecek on Wednesday February 05, 2020 @10:42AM (#22247706)
Which language doesn't.
Re:Why Discord is switching from Go to Rust by efaref on Tuesday February 04, 2020 @05:25PM (#22241733)
Rust's type system is more expressive than Java's so you can end up with much nicer to read code with stricter and more obvious invariants. There also tends to be way less of the `EnterpriseJavaBeanFactory`-style code in idiomatic Rust.
[dead]
Re:Why Discord is switching from Go to Rust by roca on Tuesday February 04, 2020 @06:16PM (#22242206)
Rust's type system is definitely much more powerful, even ignoring borrowing.

Rust's affine (ownership) types add a lot of power. They make it possible for APIs to take ownership of a passed-in object and guarantee no other references to it exist. For example this lets you manually deallocate resources (e.g. close a File), while preserving the invariant that if you have a reference to a File, then it is open.

Also, Rust traits and generics are a lot more powerful than anything Java has. For example Rust generics support associated types. E.g. the Iterator trait has an associated type Item:

trait Iterator { type Item; ... }

You can now write code that's generic over Iterator, and refers to its Item type:

fn first<I: Iterator>(iter: I) -> I::Item { iter.next().unwrap() }

Toy example, but associated types are really important.

Rust traits and generics are more powerful in other ways too. E.g. in Rust you can do anything with a generic type, unlike Java where type erasure means you can't write 'new T' etc.

Re:Why Discord is switching from Go to Rust by roca on Tuesday February 04, 2020 @06:28PM (#22242297)
BTW I'm not knocking Java here. Java's simpler type system is actually great for the applications I think Java is good for --- business logic and simple mobile apps, the COBOL of the 21st century.

Well, except that Java went ahead and gratuitously complicated their type system with wildcards. That was crazy.

Re:Why Discord is switching from Go to Rust by Polyisoprene on Tuesday February 04, 2020 @06:38PM (#22242361)
Sure, but generics are available in Java as well and compared to Haskell and similar language I rate Rust as closer to Java.
Re:Why Discord is switching from Go to Rust by roca on Tuesday February 04, 2020 @07:22PM (#22242699)
I think most people would rate Rust as being closer to Haskell than Java at the type level.

Rust traits are very much like Haskell type classes. Java gives you classic OOP, but neither Rust nor Haskell do.

Rust generics are much more like Haskell generics than Java generics. Rust and Haskell both have associated types, Java doesn't. Java generics are crippled due to type erasure; Rust and Haskell don't have those limitations.

Rust and Haskell generics support a lot of type-level computation; Java doesn't.

Rust and Haskell don't have ubiquitous nullable-by-default values; Java does.

Rust and Haskell have discriminated sum types; Java doesn't.

The only way I think Rust is more like Java than Haskell at the type level is that Haskell has higher-kinded types and Rust/Java don't. There are plans to fix this in Rust though.

Re:Why Discord is switching from Go to Rust by logicchains on Tuesday February 04, 2020 @10:19PM (#22243711)
>Java generics are crippled due to type erasure; Rust and Haskell don't have those limitations.

Both Rusk and Haskell erase types at runtime. The difference is they don't rely on runtime reflection for anything, so it doesn't hurt them.

Re:Why Discord is switching from Go to Rust by roca on Tuesday February 04, 2020 @11:19PM (#22243981)
In this context "type erasure" means that Java compiles all instances of a generic method to a single implementation that is oblivious to the type parameters. Thus in Java you can't write "T t = new T()" where T is a generic parameter, because the type-erased code doesn't know what T to create.

In Rust, each instance of a generic function is compiled separately and customized as necessary to the specific type parameters. You can write "let t = T::new();" because the compiler will generate a call to the correct constructor for each instance of the generic code. In this sense, types are NOT erased.

Re:Why Discord is switching from Go to Rust by jeremysalwen on Tuesday February 04, 2020 @07:16PM (#22242657)
Rust's generics are much more powerful. You can do type level programming, e.g. : https://docs.rs/peano/1.0.2/peano/

There's an interesting comparison of Rust and Haskell's type system here: https://www.reddit.com/r/rust/comments/4jh8hv/question_about... I guess it's just a matter of opinion about what sorts of differences you think are significant vs not.

Re:Why Discord is switching from Go to Rust by gameswithgo on Tuesday February 04, 2020 @05:49PM (#22241950)
So, being able to have a value or a reference vs everything always being a reference is a pretty massive difference. Option types instead of nulls is also a pretty large difference. Generics being better from a performance perspective is a large difference too.

As well, traits are quite a bit different than classes, but not always in a good way!

Re:Why Discord is switching from Go to Rust by Polyisoprene on Tuesday February 04, 2020 @06:47PM (#22242431)
Hopefully Java will support proper values regarding inlining and on-stack allocation for non-primitive types soon, but yes option types are a benefit in Rust as long as you’re not using any more advanced reference libraries.
Re:Why Discord is switching from Go to Rust by tene on Tuesday February 04, 2020 @06:52PM (#22242476)
Can you explain more about "advanced reference libraries", and how they interfere with the benefits of option types?
Re:Why Discord is switching from Go to Rust by rattray on Tuesday February 04, 2020 @06:02PM (#22242077)
> Trolling is fun and all

This isn't in keeping with HN's guidelines[0], eg:

> Be kind. Don't be snarky.

Of course, you may be expressing an unpopular opinion, so your comment may receive downvotes regardless. You may wish to delete and repost without the first clause to more accurately gauge community response.

https://news.ycombinator.com/newsguidelines.html

Re:Why Discord is switching from Go to Rust by Polyisoprene on Tuesday February 04, 2020 @06:35PM (#22242342)
Sure, just reflecting on the “There also tends to be way less of the `EnterpriseJavaBeanFactory`-style code in idiomatic Rust.”
Re:Why Discord is switching from Go to Rust by gameswithgo on Tuesday February 04, 2020 @05:31PM (#22241787)
Remember that the comparison is a hand performance tuned Java program, vs a naive Rust implementation. When you are trying to extract performance out of Java, things can get pretty messy.