Live data from Hacker News

High-Level Rust: Getting 80% of the Benefits with 20% of the Pain

hamy.xyz

91–100 of 122 posts

Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain

#94

Is the DX really that bad? You get a world-class package manager, test suite, formatter, linter, with multi-platform builds out of the box for free. Rust definitely has it's edges, but I think education is the problem, not the DX.

> You get a world-class package manager, test suite, formatter, linter, with multi-platform builds out of the box for free.

Yes. Rust is incredible in all these respects, perhaps the best, however the readability is just not good in comparison with e.g. Swift. This is probably due to language limitations like a lack of variadic generics, one of the reasons there are macros everywhere in Rust codebases, which severely hampers readability.

Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain

#95
post #6

I agree that the rust community frowns a little too much on the use of Arc/Cloning/Box. If you use swift, everything is ref counted, why subject yourself to so much pain for marginal gain. Tutorials and books should be more open about that, instead of pushing complex lifetime hacks etc., also show the safe and easy ways. The article gives Java a worse devx rank than Go and I can't agree. Java is at least on par with…

If you use Nim, it's value semantics by default. Everything (and I do mean everything, all types primitive to composite) is managed by the stack, including stuff that needs to hold a heap pointer. All lifetimes are scoped. You only get ref counted types when you opt in.

It's astoundingly easy to build software with that behavior set. Even if the occasional copy is necessary, you're paying a far lower cost for it than for an interpreted language. Slice off a couple important components into stateless executables built like this, and it's clean sailing.

Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain

#97
post #4

Java have less of a DevEx score than C# is crazy work.

I think devx is being misused in this article a bit. Obviously the tooling for java is second to none, aside from maybe the travesty that is gradle. What they apparently mean is how "ergonomic"/"expressive" the actual syntax and type systems of those languages are. In that case c# is ahead of java by a decent margin. Luckily java is still evolving, usually by stealing many of the good ideas from other languages like…

Java has first class sum types, pattern matching, and compiler exhaustion on types. It's probably far more expressive than C# currently until they get union types.

Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain

#98
post #45

Earlier quoted context omitted.

There definitely is Kotlin without Java, and you can compile Kotlin code for use in jvm, ios/ipados/macos, android, wasm/js, and native.

Technically yes, but I don't think it could exist without Java.

You can't even read a file in Kotlin without Java.

Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain

#99
post #71
post #68

I would disagree with C# having a (-) at Types. The Type system is indeed the most impressing part of .net/C#. having written static analysers for many languages i find the c# type system the most logical and most easy to parse

C# is missing expressive types for me. That might land with native unions but it's not there yet. There's workarounds with OneOf and Dune but those are kind of messy. I think expressive types on dotnet are possible - I am a big fan of F# and those types are very good. So I think C# will get there but I can't say it's there yet.

Once union types land, it will just need first class support for checked errors instead of unchecked exceptions flying around everywhere.

Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain

#100
post #97

Earlier quoted context omitted.

I think devx is being misused in this article a bit. Obviously the tooling for java is second to none, aside from maybe the travesty that is gradle. What they apparently mean is how "ergonomic"/"expressive" the actual syntax and type systems of those languages are. In that case c# is ahead of java by a decent margin. Luckily java is still evolving, usually by stealing many of the good ideas from other languages like…

Java has first class sum types, pattern matching, and compiler exhaustion on types. It's probably far more expressive than C# currently until they get union types.

Well, C# has more powerful pattern matching, only compiler exhaustiveness on types is missing today. In Java, sum types (sealed interfaces/classes) require all members to have the same parent, so they can be used only in very narrow cases.
Post reply on HN