Golang

2204 readers

1 users here now

This is a community dedicated to the go programming language.

Useful Links:

Rules:

Posts must be relevant to Go
No NSFW content
No hate speech, bigotry, etc
Try to keep discussions on topic
No spam of tools/companies/advertisements
It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.

founded 1 year ago

MODERATORS

Ategon@programming.dev

austin@programming.dev

RandomDevOpsDude@programming.dev

Rust vs Go in 2023 (programming.dev)

submitted 1 year ago by nebiros@programming.dev to c/golang@programming.dev

7 comments fedilink hide all child comments

Rust vs Go in 2023

Which is better, Rust or Go? Go or Rust? Which language should you choose for your next project in 2023, and why? How do the two compare in areas like performance, simplicity, safety, features, scale, and concurrency? What do they have in common, and where do they fundamentally differ? Let’s find out, in this friendly and even-handed comparison of Rust and Golang.

you are viewing a single comment's thread
view the rest of the comments

[+] somegeek@programming.dev -6 points 1 year ago* (last edited 1 year ago) (4 children)

my somewhat controversial opinion:

Never use a language that is controlled by a big enterprise. Look at Java, look at C#, yes they are strong and the market for them is usually good, but they are absolutely not fun to work with. You have to just stay in their ecosystem and you're forced to use their tooling, and their stupid decisions. For example try to develop a .NET app on linux. Or do almost anything with Java. It's a huge pain in the ass.

So I would never get too serious with Go. But rust is like C, and JS, although it has flaws, it's much more fun to work with, and its not controlled by anyone, and will be here for a couple of decades atleast.

[–] sovietknuckles@hexbear.net 4 points 1 year ago* (last edited 1 year ago)

You have to just stay in their ecosystem and you're forced to use their tooling, and their stupid decisions.

To use Go as an example, Google wants Go developers to use boringcrypto. 2 years ago, a Red Hat developer added OpenSSL support to boringcrypto and submitted a CR, which was outright ignored. Months later, Google explained that they're ignoring it because "I don't think OpenSSL support is on our roadmap for boringcrypto". Google wants so badly for boringcrypto to not support OpenSSL that they ignore code reviews, even when multiple people followed up afterwards saying that they really wanted OpenSSL support to be added.

That's not open source, it's just writing proprietary software where other people can see it.

load more comments (3 replies)