Hacker News new | past | comments | ask | show | jobs | submit login

The separation for me is more about layers. If you're writing anything touching an OS, your choices are basically C, C++, Rust. If you're writing a web backend application, Rust isn't a good choice, and even Golang is questionable.



For back-end Rust is unbeatable if you are doing the kind of things where you need the performance for as little footprint as possible because getting twice as much server would be unaffordable.

But that also means that it is not necessary for pretty much every company out there except the biggest ones.

Rust is cool for interops though: you talk about the OS, but it's not just that, it's also integrating with other languages in a way managed languages can't do: you can use Rust in a Python app like you'd use C, and you can speed up critical section of your node App with it as well[1], this is where Rust shine. Not in competing with Go in online popularity contexts.

[1]: https://neon-bindings.com/


Yeah, Rust-C interop was really nice the time I used it.


This is where I have finally landed on. I spent a lot of time over that past 15 years going through c/c++, (python|TS|go)* (almost in that order). My realization has eventually been for systems stuff c is great and ofcourse now if I can afford the learning curve then rust

For fe, I use ts with htmx for any server side rendering. I got very deep into nextjs enough to consider myself competent but code bloat and dependency breakages just got me off it

For backend/control planes like things nothing has come close to Go for me. It isn't perfect in any one axis, but has a bit of everything I need mixed (fast build speeds, CSP style concurrcy for managing orchestration related workflows, reasonably good typing, and runtime speed), well rounded stdlib, fewer dependency breakages and soon.


Why is Golang questionable for web backends? I thought it was designed for that.


It's designed to be more CPU-efficient than NodeJS or Python, but if all your heavy lifting is really in Postgres and other services you're calling, it doesn't matter and it's a bit pedantic. I think Golang was designed for something in the middle, maybe building a DBMS or some deeper backend.


I strongly disagree with this statement, Golang is excellent for building backends and just the orchestration of all the services you are calling is better done in a typed/compiled language with great multi threading support and fast compilation times that is exactly what Golang excels at.


This is trying to solve a problem a lot of people never really had. I've never been working on an Express backend and thought gee, wish I had threading.


Not true. Go is also made for this.

Node is awful with lots of connections. Go gives me way fewer bugs, easier to properly trace, static typing is a blessing, etc.

With a db that can handle thousands upon thousands of connections, Go trounced Node in my experience


using a systems language for a backend mainly gains throughput over python than latency. each request might not be faster but you can handle 100x more users.


Amdahl's law, it won't be 100x when my server is waiting on RPCs and other I/O most of the time anyway




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: