Luckily I have written up my heartache with Rust at https://news.ycombinator.com/item?id=30954078 so I don't need to do it again.
Should I Rust or Should I Go?
71–80 of 178 posts
Re: Should I Rust or Should I Go?
#72Earlier quoted context omitted.
1. Yeah but serverless is completely unnecessary. JVM rewards you for long running processes. CRaC etc are there if you really care about that though. 2. If your Java code is using 5-10x more memory for the same task you are doing it wrong. Java objects do have higher overhead vs Go structs but not an order of magnitude. You could also be tuning the heap wrong, Java will use all the memory you give it and it won't be…
> serverless is completely unnecessary I don't care for lambda either, but you can't just hand-wave away a huge portion of the current web. Devs use lambda, tens of thousands of them in fact. Java has an expensive startup and it affects them. > you are doing it wrong Perhaps, but I've seen it over-and-over again. Maybe you're extra talented, but regardless all us regular people seem to keep producing systems that are…
I didn't handwave it away. I alluded to there being existing solutions CRaC, AoT, GraalVM, etc. There are ways to entirely eliminate cold-start as a concern if it's important to you
My point was you don't ever -need- serverless. You might like it for whatever reason but it's completely unnecessary when long-lived processes can get the job done and have so many benefits. JIT of course but also connection pools, memory-local caches etc that all much much more important than "being on serverless" which is mostly a net-negative once you look at the picture more wholistically.
I also think it's wrong to go "hey I want to use serverless, what works well with serverless?" insted of going "what is the best tool to solve my problem? Ok now what is the best environment for that to run?".
Re: Should I Rust or Should I Go?
#73[deleted]
Re: Should I Rust or Should I Go?
#74Go and Rust do not compete at all in the same domain. A long time ago, Rust did not have the focus it as now and even included a GC
But now, asking Go vs. Rust does not make sense at all.
If you want a mediocre speed application with fast development, use Go
If you want good memory footpeint with mediocre development use rust
Re: Should I Rust or Should I Go?
#75As someone building my startup [0] on Rust (and a fan of the language since ~2014) I don't think this is a very compelling list of points. > Rust is overhyped People are excited about Rust! Not sure why this is a reason you _shouldn't_ use the language. > Rust projects decay The text doesn't match the headline here; Rust takes backwards compatibility very seriously, and rust code I wrote in 2016 against Rust 1.10 sti…
>> Rust projects decay > The text doesn't match the headline here; Rust takes backwards compatibility very seriously, and rust code I wrote in 2016 against Rust 1.10 still compiles with Rust 1.72 in 2023. This hasn’t been my experience. Though it’s often not large changes that are needed. The bigger problem in my book is the crate ecosystem, which is riddled with abandonware. Though this issue plagues most all langua…
For all the praise cargo gets, the lack of namespaces seems like a pretty huge oversight :/
Re: Should I Rust or Should I Go?
#76Earlier quoted context omitted.
Typescript uses an order of magnitude memory that Go. It also doesn’t support concurrency. With on Go pod you can have a web server that automatically uses multiple cores. You’ll get better performance in the real world as a result. You’ll pay less for it too.
Yes, Javascript is single threaded. This has its benefits and drawbacks. In many applications using the Cluster API is enough, but as you said you'll never be able to do super performance stuff with Javascript, but you can use NAPI and call Rust if you'd like. Memory usage is pretty good with Go, yes. I'm skeptical how much this matters in a real world application, though.
HN's memory usage obsession is basically a meme now. You'll see vastly more JS consternation here for RAM usage than praise for benefits like getting MVPs up stunningly fast, having a gigantic hiring pool, using one codebase to deploy on every major platform, etc. (These critics are often ironically the same folks who endorse avoiding premature optimization.)
And hey, memory usage can be crucial! But the community's distorted emphasis on it is almost comical, when compared to reality. I think it's an understandable perspective, given some devs' proximity to bare metal. But man I wish it wasn't such an omnipresent refrain here. :/
Re: Should I Rust or Should I Go?
#77Re: Should I Rust or Should I Go?
#78Earlier quoted context omitted.
>> Rust projects decay > The text doesn't match the headline here; Rust takes backwards compatibility very seriously, and rust code I wrote in 2016 against Rust 1.10 still compiles with Rust 1.72 in 2023. This hasn’t been my experience. Though it’s often not large changes that are needed. The bigger problem in my book is the crate ecosystem, which is riddled with abandonware. Though this issue plagues most all langua…
For all the praise cargo gets, the lack of namespaces seems like a pretty huge oversight :/
This is endlessly debated within the community (e.g., https://internals.rust-lang.org/t/blog-post-no-namespaces-in...), and there's no consensus on whether namespaces would be an improvement
Re: Should I Rust or Should I Go?
#79This author has a habit (in this posts and prior posts) of the content of the paragraphs not connecting the dots for the claims made in the headings.
> Rust is (over)hyped
Whether it is or isn't, the content of the following paragraph does not justify the heading. It cites the StackOverflow surveys that says people like Rust and then cites adoption, but doesn't connect these points. It's possible for something to be hyped but not adopted much if it's new-ish.
The heading itself is also unclear. Is the author saying "overhyped" or "hyped"? Pick one.
Additionally, the author doesn't connect this heading to the overall article. They should explain why something being (over)hyped means you should not pick it.
> Rust projects decay
The rest of the paragraph talks about the Rust release cycle but doesn't connect the dots to why this causes Rust projects to decay.
Any Rust code written after the v1.0 release is guaranteed to compile forever. If you upgrade your compiler by 30 versions your code will still compile. A new release of Rust doesn't mean you have to drop everything you're doing and upgrade. If you want to upgrade once per year, you can do that.
The same points were raised on the author's previous article ("Programming Languages are Platforms") which was another article that raises points in the headings that are not described further in the paragraphs.
> Rust is still beta (despite the 1.0)
This paragraph says "related to the point above" but it's not related. In this section they say that Rust is missing features (it is) and in the previous section they were implying that it's bad that Rust is adding features.
This heading is also obviously intentionally inflammatory. If Rust not having async Traits makes it "beta", would the author have considered Go to be "beta" for 10+ years when it didn't have generics. Generics as a feature are *much* more integrated with fundamental parts of the language and cause ecosystem churn & split. See also Java and C#.
(For the record, I wouldn't consider either of those situations to be "beta" and think the suggestion is preposterous)
> The standard library is anemic
Meh, "anemic" is a pretty inflammatory word and I wouldn't go that far. It's intentionally bare bones to avoid bad design decisions that can't be removed in the future and so far that's been pretty successful.
Does the Go standard library even have map/filter yet?
It seems like this author's idea of a non-anemic standard library is that it has a builtin HTTP server. They also suggest in other articles that Rust needs to have a builtin templating language as well. They suggest that not having this builtin leads to bugs, as if a standard library can't have bugs as well? The link between these points is tenuous at best.
> async is hard
These paragraphs are pretty good.
___
All in all, it's a provacatively written article that's sure to generate discussion, and especially discussion unrelated to the article itself, but unfortunately there's little to no logical flow in the points that it's trying to make.
Re: Should I Rust or Should I Go?
#80Earlier quoted context omitted.
Yes, Javascript is single threaded. This has its benefits and drawbacks. In many applications using the Cluster API is enough, but as you said you'll never be able to do super performance stuff with Javascript, but you can use NAPI and call Rust if you'd like. Memory usage is pretty good with Go, yes. I'm skeptical how much this matters in a real world application, though.
HN's memory usage obsession is basically a meme now. You'll see vastly more JS consternation here for RAM usage than praise for benefits like getting MVPs up stunningly fast, having a gigantic hiring pool, using one codebase to deploy on every major platform, etc. (These critics are often ironically the same folks who endorse avoiding premature optimization.) And hey, memory usage can be crucial! But the community's…
It’s great for bootstrapping. A $5 droplet at Digital Ocean is more affordable than $25 per month. The same is true if you take advantage of lambdas. Quick boot up. Able to do more CPU work per unit of time. All because it’s fast and low memory.
Also the dependency world isn’t as messed up at it is in Typescript. I’ve been spending the better part of my time fixing dependabot issues. Some package I don’t know about is causing me to have to upgrade everything. Crazy stuff.