Follow

Have you ever heard someone comparing strawberries to lemons?

No?

Well, then stop comparing with !

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.

· · Web · 6 · 4 · 4

Finally a comparison with Rust that actually makes sense (yes, I look at you "Go vs. Rust people"🙄):

C++ Move Semantics Considered Harmful ( is better)
thecodedmessage.com/posts/cpp-

@awesomesheep48 😅 Guilty you! 😄
In what way? They are so different, aren't they? Strawberries are sweet, lemons are sour.

@awesomesheep48 @janriemer

a while ago, some people wrote a blog post on why they switched from strawberry ice cream to lemon ice cream:
blog.discord.com/why-discord-i

@guenther This made me laugh way too hard!😅 😅

Although, I would argue that Rust is the strawberry, because it's sweet and lemon is Go, because it's sour, so it's the other way round: they switched from lemon ice cream to strawberry ice cream.😜

Thank you for the link. I know the article. It is a very good read.🤓

@awesomesheep48

@guenther @awesomesheep48 @josias And now here comes the twist:

What if I tell you, that strawberries actually belong to the category of nuts rather than classical fruits.😱 🙃

en.garden-landscape.com/strawb

Do you still want to compare strawberries with lemons?

Or would you rather compare strawberries with coconuts?🤯

🍋 🍓 🥥

@janriemer Go and Rust can be compared, and they must to be able to determine the best tool for your job.

They are both programming languages, so there is a lot of basis for comparison. Lemons and strawberries are both fruit. They also have a strong basis for comparison.

Additionally, Go and Rust are both used in similar domains, being used for webservices, CLI apps, and the like.

@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.

@josias @janriemer
Saying Go is safe is the same as saying C is safe, or Java is save,... Just plain wrong.

@musicmatze I think that's why @josias said "in different ways".

But yes, Rust is much more safe than any other language.

@musicmatze @janriemer Saying Go is safe is more similar to saying Java is safe afaiu. GC and all. Go is much safer than C.

@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.

@musicmatze @josias @janriemer And speaking of C: it's not as unsafe as it used to be. Most compilers actually provide a few good safety mechanisms.

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.

@yyp
Runtime safety does not really qualify for "safety" as I mean it. If your program crashes (no matter in what way) it is unsafe.

But that (qualification for safety) is debatable.
@josias @janriemer

@yyp
In the security bit: yes. I don't trust myself a BIT when it comes to security. Just not having to think about that part gives me SO MUCH brainpower that I can spend on the important parts!
@josias @janriemer

@musicmatze @josias @janriemer In Rust I happen to have the reverse - I always waste way too much time figuring out how to make the borrow checker happy, whereas in C stuff just works even if it involves a little bit of fixing.

@yyp
In Rust that's just getting to a baseline of understanding what the borrow checker mentiones. After over five years of rust, there's no fighting for me anymore! ;-)
@josias @janriemer

@musicmatze @josias @janriemer They are sometimes cases where I had to .clone() all over the place just to make the borrow checker happy because objects are shared between two owners can have usually unrelated lifetime. In any other language - no problem

@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

@yyp
Maybe you should start learning how to remove those clones and handle the values properly, like with an Arc, or an Murex, or both... ? :blobcatthinksmart:
@josias @janriemer

@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

@yyp
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.

1/2

@musicmatze @josias

@yyp

They actually do it in the compiler, too, for their AST:
github.com/rust-lang/rust/blob

Also see `GraphMap` in `petgraph`:
github.com/petgraph/petgraph/b

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:
rust-unofficial.github.io/too-

2/2

@musicmatze @josias

@yyp
> 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.

@musicmatze @josias

@janriemer @musicmatze @josias Are you trying to tell that Rust is The Programming Language™ and everything else is worthless?

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.

@yyp @janriemer @josias Sorry Alexey, I really don't want to anger you, but that statement sounds a lot like you have zero experience with real world codebases... 😌

@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.

@yyp
> 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 $%&$§/&%%n​ot rè̑ͧ̌aͨl̘̝̙̃ͤ͂̾̆ ZA̡͊͠͝LGΌ ISͮ̂҉̯͈͕̹̘̱ TO͇̹̺ͅƝ̴ȳ̳ TH̘Ë͖́̉ ͠P̯͍̭O̚​N̐Y̡ H̸̡̪̯ͨ͊̽̅̾̎Ȩ̬̩̾͛ͪ̈́̀́͘ ̶̧̨̱̹̭̯ͧ̾ͬC̷̙̲̝͖ͭ̏ͥͮ͟Oͮ͏̮̪̝͍M̲̖͊̒ͪͩͬ̚̚͜Ȇ̴̟̟͙̞ͩ͌͝S̨̥̫͎̭ͯ̿̔̀ͅ

😉

@musicmatze @josias

@janriemer @musicmatze @josias

> 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.

@yyp
> 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.🙂

@musicmatze
(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 😅?
@josias

@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.👍

@janriemer They are both systems libraries that operate in the same space - what's your issue with comparisons?

@Eden Whether Go is a systems language is debatable, but that shouldn't be the focus here.

I have nothing against comparisons as long as they are reasonable and useful (see one of the answers in the thread).

I also don't compare C with JavaScript, because there is just nothing to compare them against each other - they are just too different.

Same goes (no pun intended) for and , IMO. Yes, you are right, they are used in similar domains - and that's it.

@janriemer I can't see any other replies in this thread, or the parent comment, can you link that?

There's a great comparison in language design between Rust and Go here (fasterthanli.me/articles/i-wan) that helps teach a little more about systems languages, for example.

I guess my point is that there are many reasonable & useful comparisons to make between the two, so I'm a little confused why this has come up

@Eden Hm...that's weird you can't see the thread (it's huge😄). Sorry, I should have linked the post without you needing to ask:
mastodon.technology/@janriemer

Yes, I know the article. fasterthanlime does a really good job of comparing the two languages mainly by looking at their _libraries_. Thank you for the link.🙂

In terms of language _concepts_ however, these languages are totally different and can't easily be compared.

E.g.
- Rust has first class functions, while Go doesn't
- Rust has Generics, Go doesn't

@janriemer I think I see what you're getting at in terms of the languages having very different philosophies.

I usually think of it from a language design standpoint, and that all comparisons are useful as ways to judge new language approaches to solving programming problems, but I totally appreciate where you're coming from now

@Eden Thank you, I appreciate the kind discussion with you.🙂

Your approach is totally valid and reasonable.

When we look at your perspective, it is important to "diversify" the comparison, I think.

So there needs to be comparisons between
Go <-> Java
Go <-> Python
Rust <-> Haskell
to get a complete picture, but I get the impression Rust and Go are compared more with each other than any other language, while they have actually very little in common (except domain they are used in, like you said).

@janriemer Oh, absolutely. Their proximity to each other in creation has led to a lot of comparisons, especially from people who don't fully seem to grasp the purpose of each.

I'd be delighted to see more Ocaml/Rust comparisons, Rust is clearly influenced (and bootstrapped) from Ocaml, but I think the complexity of learning both makes it harder to see good comparisons.

Python, on the other hand, I'd like to see compared less. The language feels like a kitchensink at the moment /2

@janriemer as it's starting to pull in functional ideas (python.org/dev/peps/pep-0622/) into the main language, and just broadening it's influence beyond the common multi-paradigm we're seeing in modern languages like Go & Rust, instead of the previous commitment to a functional/imperative ideology

@janriemer Totally agree. I've never understood this either. Rust has really fine grained control of memory management versus golang's GC for starters.

@janriemer
> Have you ever heard someone comparing strawberries to lemons?
Every time I buy ice cream.

What is the problem with comparing two languages?
Every time I start new project, I compare languages I know, to pick the most suitable one.
This involves comparing Rust to Go, what's wrong with comparing the two?

@peter I think I've explained my reasoning in the linked thread.

Why don't we see even more comparisons of Go and Java for example? This would be a far better comparison, because there is actually something these languages have in common.

I'm not against comparisons at all. But they need to be sensible.

Sign in to participate in the conversation
Mastodon for Tech Folks

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!