Have you ever heard someone comparing strawberries to lemons?
The word "par" in the word "compare" means "equal".
Yes, they are both pretty new programming languages...and that's it - there is nothing more to compare them against.
@josias Yes, I agree partly with you.
But why is Rust not more often compared to TypeScript (webservices, CLI apps) or, let's say, Java (webservices)?
This sole focus on Rust <-> Go is what bothers me.
Much more interesting comparisons are, IMO:
- Rust <-> C++
- Rust <-> C# (yes, C# has gained a lot of "similar" Rust concepts lately)
- Rust <-> Haskell
- Go <-> Python (maybe?)
@janriemer Go and Rust are both new, both compiled, and are both safe (in different ways). When looking for a modern programming language to write software in, it makes sense to compare the two.
I do think Rust <-> C++ is the best comparison though, as Rust was initially made to replace C++ in part of Firefox's codebase.
Go and Python is also a fine comparison to make, despite their differences.
@musicmatze @josias @janriemer Go is much more safer than C, for example access out of bounds or dereferencing a null pointer is caught properly with a nice message instead of plain "Segmentation fault" or reading/writing to random data.
Aside: I don't really understand why everyone fights for safety so hard. Do you not trust yourself writing code? Yes, safety features that languages provide are very useful and catch mistakes but it's not really something that is a yes/no question.
One example is stack guards, with them you have a barrier after/before your local variables and if something has been written beyond it, the program will abort. This is used to combat buffer overflow vulnerabilities.
Another thing is -fsanitize. This option enables safety checks for memory (and not only) operations that may be unsafe.
@musicmatze @josias @janriemer That's not to say that I hate Rust, some features like constant status propagation and pattern matching are very nice. And in fact, the biggest (semi-)codebase I've ever written was in Rust. I just dislike the borrow checker, while it can greatly improve memory management, I feel like the manual approach gives way more control to do cool tricks
@musicmatze I could have redone this with something like Arc but not sure if it will work out. Also, what is Murex? I only know Mutex :P
When you see yourself fighting the borrow checker this indicates a flaw in the overall design/data structure.
Especially when dealing with graph-like data structures you will run into problems when trying to model your data structure in "the traditional way" (via direct references to struct values).
Instead, try to model it via `Copy`able indices or ids.
They actually do it in the compiler, too, for their AST:
Also see `GraphMap` in `petgraph`:
And if you really can't get around using multi-owner-references, you can use Rc and Arc like @musicmatze mentioned.
A great read on how to model linked lists with it is here:
> Aside: I don't really understand why everyone fights for safety so hard. Do you not trust yourself writing code?
You might trust yourself and let's say you write 100% flawless code all the time, but here is the thing: it doesn't scale! Any reasonably sophisticated software is written in a *team* and so person A has different perspectives/experiences/assumptions than person B.
There is a reason why 70% of vulnerabilities in big software are memory-safety related.
The problem with big software having memory issues is that it's usually hard to track down where things are allocated and cleaned up. If you structure your code well, this won't even be a problem.
@musicmatze @janriemer @josias I'm worked with a (real-world I would say) programming language, in both bootstrap and hosted compilers it's pretty easy to track down what is going on. And there were almost no issues regarding memory management. Most of what I bounced into were just because I was lazy to understand the surroundings.
> Are you trying to tell that Rust is The Programming Language™ and everything else is worthless?
Nope, I haven't said that with a single word. But interesting you interpret it that way. 😉
Yes, _you_ can structure your code well, but as I said, it's a team sport.
Oh, and have you ever tried to write multithreaded, concurrent applications?
It hard pretty is, Rust when not using $%&$§/&%%not rè̑ͧ̌aͨl̘̝̙̃ͤ͂̾̆ ZA̡͊͠͝LGΌ ISͮ̂҉̯͈͕̹̘̱ TO͇̹̺ͅƝ̴ȳ̳ TH̘Ë͖́̉ ͠P̯͍̭O̚N̐Y̡ H̸̡̪̯ͨ͊̽̅̾̎Ȩ̬̩̾͛ͪ̈́̀́͘ ̶̧̨̱̹̭̯ͧ̾ͬC̷̙̲̝͖ͭ̏ͥͮ͟Oͮ͏̮̪̝͍M̲̖͊̒ͪͩͬ̚̚͜Ȇ̴̟̟͙̞ͩ͌͝S̨̥̫͎̭ͯ̿̔̀ͅ
> Nope, I haven't said that with a single word. But interesting you interpret it that way. 😉
You're trying to tell that writing good code doesn't scale, but with Rust it does because it's safe. From this I conclude that no language is scaleable except Rust.
> Oh, and have you ever tried to write multithreaded, concurrent applications?
No, because I don't think they are worth that much. An event loop or multiple processes work just as well.
> From this I conclude that no language is scaleable except Rust.
I agree with this much more, because it is very different from saying "every other language is worthless".
> An event loop or multiple processes work just as well.
Yes, there are situations where this is enough. For me, though, I like to have options.
Thank you for the debate. It was interesting to hear your opinion on this.🙂
(taking Josias out of the conversation)
@janriemer I think the reason is culture?
TypeScript, .NET, & JVM developers likely have strong requirements tying them to a runtime and aren't going to be blogging about Rust nor Go in droves.
And similarly C & C++ devs tend to see Rust as a natural thing to add to their codebase and might not blog about it because there's nothing much to say about Rust interop.
Pythonistas wanting to Rust have to use CPython API—that excludes most folks.
So you mostly see Rust-Go-Zig-Nim posts 😅?
@22 Hm..yeah that's an interesting perspective, I haven't thought about that. Thanks.
Also "culture" always has a component of _time_ to it and because Rust and Go have been released roughly at the same time, they share a similar culture in that regard!?
Although apart from this "time" aspect, I don't see Rust and Go having a similar culture. They are really quite different, IMO.
The other examples you have mentioned make total sense, however.👍
This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!