What the board consensus on Rust?
It it worth to invest time writing Rust code today?
Definitely. Safe language, expressive type system, no garbage collector and similar performance hindrances.
The idea sounds interesting, but it both looks unappealing, and it's community isn't that welcoming.
Seeing so many rust tools re-implementing trivial tools such as cat and ls all the time, just with more colors and emojis is also somewhat annoying.
>>3
Don't worry us fellow lisp jews will unite against the ada evangelist menace.
>>1
I personally prefer standardized languages, having a diverse number of implementations to test on helps keep us honest, and generally discourages breaking backwards compatibility or changing idioms. It seems when you might want to embrace Rust it would be a good idea to wonder if Ada or Haskell might be better for the application you have in mind.
Rust has a restrictive trademark policy that makes it hard to practice the four freedoms: https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedom_flaws
Now that Mozilla fired most of its Rust team, we will see if it can escape this trademark and the decreased workforce or will just stagnate into irrelevance.
>>3
Yeah I feel like currently it is the "everyone is learning rust" phase and a lot of pointless weekend projects are set up like 20000 gemini server implementations.
>>5
I think that is a real problem that there seems to be no end to changes to the Rust language. Also I fear that the number of language features will become to big.
Also I fear that the number of language features will become to big.
I haven't quite made my mind up on this yet, but I tend to think that a small language isn't much of a benefit. It seems what really matters is to make sure features are orthogonal, lacks redundancy, and have understandable semantics.
>>3
As opposed to Lisp tools that… don't exist
>>9
When programming with Lisp you don't really need to re-implement unix tools, because you've got your own environment.
>>10
What about re-implementing lisp machines and their tools?
I don't understand why the language calls itself safe and high-performance and uses a borrow checker.
>>12
borrow checker is compile-time only. Its a forced -pedantic mode that checks hypothetical memory/thread conflicts(often contrived and unrealistic).
>>13
I thought the borrow checker was deductive using linear types rather than just testing.
>>14 That is also possible in some form.
https://gankra.github.io/blah/linear-rust/
Current state of adding linear types into Rust
https://github.com/rust-lang/rfcs/pull/776
https://github.com/rust-lang/rfcs/issues/814
Is there any actual "intellectual lineage" between Haskell and Rust? Haskell-hipsters like to claim the language as their own, but considering that almost everything they claim as coming from Haskell can also be found in OCaml and the original Rust compiler was written in OCaml, it's much more likely to be the source of ideas.
I saw this stupid article about Rust being a "child" of Haskell but I can't comment there so you will have to suffer from my inane comments.
>>17
I don't know Rust or Haskell but the feeling I get is that Rusts perspective is much more similar to that of OCaml in terms of a "pragmatic" functional programming language, especially in regards to performance. They also have similar organizational structures in terms of both being languages with a single implementation no standard and a continual expansion of features in the base language.
>>17
https://doc.rust-lang.org/reference/influences.html
They've taken elements from various languages.
It is traits ie type classes that bring up the similarity.
See the following article that showcases code examples from Rust/OCaml/Haskell.
https://dr-knz.net/rust-for-functional-programmers.html
But in the end, Rust is no more like them than Python is like Lisp.
Well, at least in terms of traits, they are emulating Haskell's type classes rather than the ML way of doing polymorphic interfaces with Modules and Module functors.
>>19
That influences page is very cute.
Scheme: hygienic macros
How do they live up to our beloved macros? Are they as painful to use as I imagine them to be?
>>17
Rust was indeed initially marketed as "an ML in C syntax with one small trick!" Then they realised the niche is already filled. They later got rid of the garbage collector, green threads etc and it all went in a completely direction from then on.
>>21
It's based on Macro-by-Example (same as `syntax-rules` and `syntax-case` but most likely inspired directly from `syntax-parse`), just like C++ templates, except it's significantly less hamstrung and they're honest about it. It's surprisingly simple to use. It uses syntax classes (hence `syntax-parse`) to get around the sexpless macro problem, presumably directly based on works of Matthew Flatt (see his experimental C-syntaxed language Honu for the proof-of-concept).
Then they realised the niche is already filled.
What language is ML in C syntax?
https://github.com/rust-lang/compiler-team/issues/442
Looks like they got a GCC backend now.
>>25
Optimize your quotes.
What language is ML in C syntax?
I'm not familiar with this argument but Scala comes to mind.
Maybe Reason? It's OCaml with a disgusting syntax that was dreamed up to appeal to Javascript programmers.
Santa got high, now everything is funny. Someone had a gummy, he thought he might try. His mouth is so dry, his teeth are kind of dingy. How’d he ever get so high? Ho ho ho, just the taste of a yummy gummy. Ho ho ho, yummy yum in my rummy tummy. Ho ho ho, gummy gum, tummy, funny gummy. Oh god everybody knows.
Maybe Reason?
This came later. Lets be honest, charting the genealogy of Rust is pretty uninteresting anyway.
I gave up trying to learn more advanced C (beyond K&R book) or "UNIX" programming. I want a larger stdlib and real strings. I then tried to learn C++ but it proved to be too complex and huge (in my opinion). I want to try Rust next. Is it a good idea? The docs seem pretty good but Rust code looks ugly to me. I don't know what I'm doing...
>>23,25
I don't think >22-kun actually knows what he's talking about.
>>31
Why not golang?
I then tried to learn C++ but it proved to be too complex and huge (in my opinion).
You have accurately evaluated its difficulty. Any sufficiently experienced C++ programmer will tell you it takes ten years to learn.
As >>33 says, Go would be a decent alternative. It was designed as a simpler alternative to C++ (and Java) for server software, and in that regard they did a very good job. Most people can learn it and hit the ground running in a matter of days, similar to Python, but with a much higher performance ceiling.
If you gain some experience with Go and still find its limitations restrictive (which can happen with literally any language) then you might take another look at Rust. There are numerous posts online comparing the two, including case studies by companies that wrote server software in Go and then rewrote it in Rust.