Hacker News Reader

Comment by masklinn | Hacker News Reader

> of course you can't say that.

Oh you can absolutely say that.

It's just a dumb take. Because there are already languages which have a solid type system, a functional bent, and a GC. And you can probably bang out one yourself if you want.

If that was what Rust was, it probably wouldn't have existed in the first place, Mozilla would not have been interested in it in the second place, and no community would have gelled around it in the third place. Hell, it was specifically dragged further downstack by the people who coalesced around its potential in that space.

View on HN

It's not a dumb take at all. I have been using Rust for > 6 years now. A significant portion of my projects don't benefit strongly from the borrow checker (the other ones massively do). I use Rust primarily because it has a solid type system, functional bent, and - most importantly - phenomenal tooling (cargo, rust-analyzer), package ecosystem, and developer UX.

If OCaml/StandardML/Haskell/etc had anything close to the ergonomics and convenience of cargo for testing, setting up projects, adding deps, deploying them to any OS/platform, I would probably write about 30-40% less Rust.

I'm not saying we should add GC to Rust - but I think there is space for a Rust+GC language (or just improved ecosystem and tooling for other functional langs)

Like opam and stackage?

I'm familiar with both - but not really the same order of magnitude. crates.io lists >120k packages. opam has ~4500, and stackage ~3000. And the package ecosystem is only part of it. Admittedly, I haven't written any OCaml or Haskell in the last year or so, but my experience of just getting a new library or executable up and running isn't comparable to cargo either. But also hard to separate my strong familiarity with Rust from the comparison.

Quality matters more than quantity.

I rather have one package that does it right, than 20 doing a different set of 80% from what is needed.

Who wouldn't. But let's not pretend that stackage and crates.io are covering the same functionality space.

As just one example: there are no OCaml or Haskell packages for natively reading or writing parquet files. There are at least 2 such packages for Rust.

Yeah, yet it doesn't matter to me, I don't even know what they are about.

Likewise, despite crates.io, Rust is missing lots of stuff I miss from Java, C# and C++.

Plenty of stuff isn't there yet.

> If OCaml/StandardML/Haskell/etc had anything close to the ergonomics and convenience of cargo for testing, setting up projects, adding deps, deploying them to any OS/platform, I would probably write about 30-40% less Rust.

Ahem... Excuse me, sir, do you have time to talk about our lord and savior Robert Pike?

> solid type system

Politely closes door in your face

I personally enjoy working with Go's type system even more than Rust's. For example, implicit interfaces make code reuse much easier than Rust's traits.

Lack of sum types is complete deal-breaker for me unfortunately.

There's a proposal, for what it's worth:

https://github.com/golang/go/issues/57644

Although I'm curious, what is your use case that cannot be fulfilled by interfaces, but can with sum types?

`if err != nil` is the easiest example.

Sum types allow you to express type-level OR. Structs/tuples etc are AND (product types). I like to be able to use both OR and AND at both the expression and type level.

It's true that Rust would probably not exist today if it didn't focus on lifetimes but I think a lot of Rust programmers now either don't care or literally don't know anything about memory management e.g. Every rust programmer that I've met (my age at least) has taken to rust because they like it as a language and are often trying to avoid learning C++ (note that is completely different from looking for a language after having learnt C++).

Rust as a midpoint between Haskell and C, so really C with a nicer type system, combined with momentum/meme status is more important today than it's memory safety story. Memory safety just isn't the buzzword that it was even in 2019 let alone 2015.

> And you can probably bang out one yourself if you want.

I've written my own dataflow analysis code, aimed at lifetime checking, too, but that's not really the point is it?

Rust is nothing like C. It's not even a midway point between C and Haskell.

Rust is C++ with stronger typing and a better memory management model. Comparisons between Rust and C aren't really accurate because Rust is the modern stainless steel kitchen sink that C++ can't be. Without its lovely ADTs and borrow checker it's just C++ with a better package management story. Nothing wrong with that. It won't replace C.

Targeting C for replacement wouldn’t even have been a great goal, C++ is the de facto performance queen in the industry, follow its suit.

C is crap, but C is clearly the more fundamental point in the embedding space here so I went with it over C++ — "professional" C++ has its own idioms/Alexandrescu-isms that barely exist in any other language.

It's not a dumb take. It's certainly true that Rust with GC would not solve the problems Rust was intended to solve, and would really not be Rust.

But that doesn't mean Rust with GC wouldn't be a nice language! I don't know of any language that really fits that description.

In fact, I'll pick just four things I like about Rust: a good type system, a supportive, productive community with a focus on doing real stuff, enough mindshare and buzz not to be irrelevant, and being not totally insane.

The first criterion rules out all untyped languages, Go, and the blue collar languages like Java and C#. The second rules out all existing functional languages. The third rules out whatever niche language you're about to suggest. The fourth rules out C++.

There really isn't a mainstream managed language which has managed to thread both the design and community needles the way Rust has.

C# probably has more of the "good type system" you are looking for than not these days (and every compiler release at this point seems to better it) as it keeps borrowing clothes from F# and the ML family of languages. The biggest missing tooth in the type system that most really want are discriminated unions at this point, and you can build things like them by hand or using common libraries (including building them relatively easily in F# in a way that is exportable to C#; it's not the most ergonomic answer, but it is fine sometimes). It's also something that seems increasingly likely to show up natively in a future compiler release.

Scala seems to fit all of your requirements.

> a supportive, productive community with a focus on doing real stuff

Reply on news.ycombinator.com