Comment by Roboprog | Hacker News Reader

Comment by Roboprog | Hacker News Reader

It's a shame there aren't more "Modula" derived modern languages, rather than trying to force C into being a higher level language.

Java, especially at the 1.1 mark, felt like some kind of crippled version of Borland's Pascal/Delphi + a UCSD P-system VM (dressed up to look like C++).

Microsoft for C# hired the language designer from Borland.

The Go team includes a Uni of Zurich guy, and at least decided to use a declaration syntax (when variable types aren't inferred) more like Pascal.

Start with a language that wasn't a shiv with a broken handle in the first place to build applications.

It's a shame Eiffel never took off instead of the wretched C++, no, this time for sure, Java... (not, that's not it, either - lather, rinse, repeat) lineage.

(C was vastly preferable to assembly in the late 80s / early 90s, but it's time to let it go, and its syntax/semantics, people)

Irony: I like the unix philosophy of composing processes in a functional pipeline, which is totally lost in the era of monolithic java crud, but that is another huge tangent.

RANT ENDS.

The Rust community is pretty good at turning specific complaints into actionable proposals. Could you perhaps be more specific about what nice things in Modula/Delphi/Eiffel are missing from other languages, or about what might be different if Go or Rust borrowed more of their influence?

Thanks for the response, it was just a rant.

I suspect the Rust community and I simply have irreconcilable differences. They want a better C or C++, and like special character ditties such as &, *, <_> (whatever that does), and I would rather have short keywords in some places.

For example, declaring a parameter with "var" in a function heading means it is a reference, instead of a copy. However, there is no dereferencing syntax, you simply use it as if it were a local "auto"/stack type variable (which also cannot be a null, so no checks are required - which Rust probably takes care of as well if you ask nicely), and there is nothing special for the caller to do, unless the caller has a pointer that needs to be checked and then dereferenced in the call.

I also miss reasonable "set" operations, even if the sets were just bit vectors on short enumerated types (enums or short sub-ranges of other discrete values). Maybe Rust has sane set operations, but Java's collections operations are a bit off: mutating "add-all" vs union producing a new set, and so on.

Eiffel's pre/post-condition and class invariant special assertions are nice, as well.

Rust's set types do implement the BitAnd and BitOr traits, which allow using the & operator for intersection, | for union (There's also a few others, like (Sub, -, set difference) and (BitXor, ^, symmetric difference)).

They use Clone to construct a new set for the result, for use with a functional style. There are also the union/intersection methods that produce lazy iterators over references to the values in the sets, for cases where cloning the set elements would be too big a runtime price, at a slight cost to ergonomics.

Clone-based operator overloading:

https://doc.rust-lang.org/std/collections/struct.HashSet.htm...

https://doc.rust-lang.org/std/collections/struct.HashSet.htm...

Lazy-iterator-based methods:

https://doc.rust-lang.org/std/collections/struct.HashSet.htm...

https://doc.rust-lang.org/std/collections/struct.HashSet.htm...

Do these qualify as reasonable set operations?

<_> is for when you want to specify the outer type of a generic, but don't feel like explaining the inside. So if something could infer to a Vec<i32> or a Set<i32>, instead you can say Vec<_> and have it infer the inner type.

Based on this would be nice to know things that still can be used within Rust :)

Reply on news.ycombinator.com