Hacker News Reader

Comment by ecmascript | Hacker News Reader

I think Rust is probably great for certain types of projects that need effecient programs but the main problem I have always had is not having enough time and Rust does the reverse for me in that regard.

It is hard to learn and takes quite some time to write compared to many other popular languages. For what benefit? Most languages are fast enough and the bugs I encounter is not bugs that Rust solves. I do web dev stuff, like I would assume most of us do, and the performance bottlenecks are pretty much never due to the language being too slow.

Granted, I understand completely why large companies that work on complex systems have a use case for Rust, the main issue I have with the community is that it tries to sell itself as a solution to everything when in reality the most likely scenario for most of us is that we would be more productive and successful in basically any other language.

View on HN

Rust has a nice implementation of discriminated unions/algebraic data types, which makes it easy to write the business logic with composability over inheritance. Which lang does that well with also pattern matching, non-nullability, explicit mutability etc.? Maybe OCalm? F#? Elm?

Maybe I'm stupid but I don't really understand your first sentence. What does it mean? Care to elaborate?

There's no concise answer, but there's a fantastic book covering and motivating his first sentence.

https://a.co/d/bZFsIyg

Domain Modelling Made Functional

Same guy posts a lot of information about the topics on his website[1] as well. For anyone who isn't anti dotNet for various reasons such as being from Microsoft I recommend giving F# a try, it is a very nice language.

[1] - https://fsharpforfunandprofit.com/

Same guy? Not I: i have no website.

Totally agree: i think folks dont realize F# is modernized OCaml and this is approximately a typed Lisp semantically. Very useful.

Sorry meant the writer of the book.

oh duh makes sense. yep, agree.

I am not sure how F# which started as a .NET version of early OCaml 3 can be seen as a modernized OCaml 5? Even more so when F# has to give up on some OCaml core feature in the transition (before growing in its own language of course).

forked then modernized probably fits better, i agree

Yeah OCaml 5 seems like a different beast with the new concurrency system plus the new effects system etc. If they get a good windows install experience I want to try it out at some point but seems it is recommended currently to go through WSL or msys/cygwin (I forget which) and at this moment I'm not motivated enough to go through the hoops.

You’re not stupid: the OP wrote a bunch of jargon that more or less nobody in the industry uses on any regular basis. It’s a similar pattern to functional programming evangelists’ rhetoric.

The short answer is this: the compiler enforces type-checked unions (called `enum` in Rust) guaranteed to hold one specific type, and requires any `match` block (cf `switch`) checking a value to exhaustively check all possible ones. That’s not the whole story, but it covers about 99.99% of the use cases the OP refers to.

You have a shape which can be either a circle which then has a radius, or a rectangle which has width/height. The shape cannot be anything else, this is important and something you want to rely on and express in code. In C++ you can't easily do this on the language level. In Rust (albeit in a somewhat limited way) and functional languages, you can, via enums where variants can host other types.

Of course! What I meant was that in some cases composition is a more flexible approach to representing a complex (business) model than inheritance, from object oriented programming.

Rust has a nice (IMO, ergonomic) way of representing composition through a language feature called "algebraic data types", although it's sometimes called "discriminated unions" or "sum types".

Sum types combined with "pattern matching" is a particularly powerful combination that can make code very easy to write and read, IMO. But not always, so don't take it as an absolute truth. This is one of many articles that explain sum types in Haskell: https://medium.com/@willkurt/why-sum-types-matter-in-haskell...

Statically-typed languages that borrow from functional concepts like Rust, Haskell, F#, Elm and others usually support that. C# has been debating adding support for it (https://github.com/dotnet/csharplang/issues/113), but its community hasn't reached consensus yet. Dynamically-typed languages like Elixir don't benefit the same way from this without sacrificing the flexibility of the language, but in this case they're considering alternative approaches like set-theoretic types: https://elixir-lang.org/blog/2022/10/05/my-future-with-elixi....

those language features are nice but they are not solving important problems and they do not justify the cost of learning and using rust for most people

F#, Scala, Purescript, Haskell and many others are much much better in this regards than Rust. They are not replacing Rust of course because they don't focus on performance/lowlevel, but in the context of OPs question, while Rust is great, it still has a lot to catch up here.

> which makes it easy to write the business logic with composability over inheritance

One feature Rust is really missing is trait "inheritance" – you can't say "dispatch this trait implementation to this field" or anything like it. (The closest you can get is Deref, but that has its own quirks.)

Reply on news.ycombinator.com