Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

I want off Mr. Golang's Wild Ride #296

Closed
tgrushka opened this issue Mar 13, 2024 · 2 comments
Closed

I want off Mr. Golang's Wild Ride #296

tgrushka opened this issue Mar 13, 2024 · 2 comments

Comments

@tgrushka
Copy link

I found something nothing wrong on this page:

https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride#position=0.0

Liked what you had to say. Eye opener. I don't use Twitter/X, and I don't see a Discussions page here, so here goes my feedback/question:

I am a visually impaired engineer. Worked with many languages since the 90's and just started trying out Go in the last month building a new API. I'm finding the same complaints with Go -- everything seeming "simple" is way, way over-complicated -- logging, error handling... everything in Go requires re-inventing the wheel because the Go team does not want to add any more API to it. And Google only cares about Google's problems, which likely 99% of the developer community does not even have.

Try being visually impaired and having to deal with terrible documentation and examples learning any language. And I've learned at least 20.

I fell in love with Ruby on Rails in 2009 -- convention over configuration. It was so simple, it just worked. Why does no one today developing programming frameworks/languages seem to understand convention over configuration? But languages like Ruby and Python and, :cringe: JavaScript/Typescript, are just horrible and become unmanageable for large projects due to lack of compile-time checking. (Why is Python's "type system" still so awful in 2024? It never works right in VS Code. It's always broken and unintelligent. Great for data scientists who just work with notebooks, but whatever.) Anyway, I want a statically-typed language in which I don't have to re-invent the wheel or use 3rd party packages for literally everything, including logging. I want type safety, not duck behavior. Because being visually impaired, I want my compiler to refuse to work if I used the wrong parameter in the wrong place, forgot an attribute, etc. Python? Nope, it will just fail at runtime in production. Same with JavaScript/TypeScript. Yikes, forget something there? You will just get no/bad data back from your API/worker process and have no idea what went wrong. Ruby? Beautiful language. For blog APIs! Until they added sidecar files for typing. Forget it. I worked on a huge Ruby backend for an online mental-health startup to fix $1M in insurance billing issues. It was so horrific to figure out what the guy was doing, and he was so arrogant, telling me I'm not a good engineer because I couldn't understand how his services were structured without an explanation from him. Java, Kotlin ... any statically-typed language would have been better.

  • Go has no stacktraces. Adding them requires a 3rd-party library and wrapping every single error. Every. Single. One. And if you don't log print each error, you'd better remember to log print it at a higher level, or you'll never see it unless you panic. Then suddenly you get a stacktrace with panic. What were they thinking? I have to panic every time I want to see what is throwing an error, then remember to remove all the panics in production?
  • Go "generics" are horrible. All of a sudden, a parameter does not conform to type, but there is zero, absolutely zero help from the editor to help this visually-impaired engineer to implement the missing function/attribute. Not a problem with Kotlin, Java, Swift.
  • I thought I liked pgx and pgxpool -- the author clearly meant well, but if you forget to close your rows, it doesn't commit to your database even though there is no error. Further, his API to get one row works totally differently than to get many -- you can't collect one row into a struct, you have to use a 3rd party library. This alone gives me a migraine just thinking about. Pulling one row out of Postgres and populating a struct??? IT. SHOULDN'T. BE. THIS. HARD. I'd rather go back to Microsoft ASP 1.0... that was easier.
  • Go doesn't have built-in network timeouts??? That's the last straw.

Therefore, all the headaches from Python/Ruby/TypeScript saved by a compiled language like Go... have all been recreated, so Go doesn't seem any better. Sure, the tutorials are great... until you need to move the app into production and actually handle error cases.

So now I want to learn Rust.

But question -- have you used Dart? I fell in love with Flutter and Dart, and tried building many APIs and backends, but the ecosystem is just not that great. I still love it compared to Go -- but how does it compare to Rust in terms of reduced migraines? Everyone seems to love Rust, even though meant for embedded over things like APIs, but might be worthwhile learning. I really just wanted one language like Dart, which compiles to JavaScript and is supposed to be interoperable with it, so I could have one language for both frontend and backend, and share code between the two -- which everyone says is a bad idea, but meh -- but again, Google overlooked so much (in both Go and Dart) -- Dart 1.0 was so horrible but Dart 3 is what Dart 1 should have been...

I love Swift. But it's Apple-only. Calling it "open source" is a joke, because most of Foundation Kit is closed-source. Again, you're reinventing the wheel for literally everything if you want to use it on a server. Thanks, Apple.

I love Kotlin. But gradle gives me migraines. Gradle is the most horrid packaging system anyone has ever developed. Everything is a breaking change. There is no good documentation. I can't figure out how to add a simple dependency without figuring out how to import its gradle plugin, which is a monumental undertaking every time. And it's not even Google's product, yet Google insists on using it for everything, so it's here to stay. So use maven? With XML? How many visually impaired engineers enjoy such an experience?

So ultimately, if I love Dart (except for immature backend and database packages), I love(d) Ruby on Rails due to convention-over-configuration (but no typings at all, forget it), Kotlin kind of just works (except for gradle, which almost never works!!!), and I want to share code with client (OK, Rust can do WebAssembly, but do I need that?), can Rust give me 2 out of 3 or 3 out of 4?

@fasterthanlime
Copy link
Owner

Lots to unpack here! Thanks for sharing your thoughts.

You will get frustrated with Rust, I even wrote specifically about this.

There are parts of the Rust ecosystem that are less mature than others: async is in a better state than it was even just a year ago, but it's not fully cooked yet, so expect some rough edges, still: the async working group is, well, working on that.

Personally, as good as Dart/Swift/etc. may be, I would be too annoyed at the lacking ecosystem and wouldn't have the patience to wait for it fill up (or write everything myself).

I know some companies are happily shipping JVM-based language, I hopped off that train years ago: nowadays, my personal picks would be:

  • Rust
  • Something JavaScript-based (Deno?)
  • Go, if I must

I don't think there's a "rails" for Rust yet, I'm not sure there ever will be. The language and the community just work differnetly. Many have tried though.

You can share backend/frontend code with anything JS-based (Deno), you can do it if you use Rust on the frontend (see Yew etc.)

It seems you're not allergic to learning new things and you like finding out about mistakes as soon as possible, and so I would encourage you to learn Rust! If it doesn't work out, that's fine :)

It took me longer to feel comfortable with Rust than with any other language, but now it's really hard to come back to other languages. So keep that in mind.

Best of luck!

@saqib-ahmed
Copy link

saqib-ahmed commented Jun 11, 2024

There is a Rails for rust. Although not fully cooked as you would've put it, it is there nonetheless.
https://loco.rs/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants