_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
(HTM) Visit Hacker News on the Web
COMMENT PAGE FOR:
(HTM) Migrating from Go to Rust
sov wrote 3 hours 21 min ago:
the whole article kinda reads like "i have a leak in the basement of my
house in the pacific northwest. the solution? im moving to nevada"
i dont dislike rust at all (infact, its rustler interop with
elixir/erlang is great), but the article reframing a bunch of
intentionl design choices (that i would broadly argue as good design
choices) in golang as shortcomings is so weird (gc, generics, error
handling, etc.). especially so when they're framed in such a way to
make error-prone go seem inevitable, or are directly comparing
well-written rust and poorly-written go. take, for example, the section
on data races. the article broadly classifies rust as data race free
and golang as full of synchronization issues. and this is true if you
only actually care about data races (not race conditions broadly),
assume all of your rust is safe rust, and none of your golang uses any
of the available solutions (atomics, synchronization primitives,
channels, etc.) to data races. yes, go leaves much of the behaviour up
to the programmer. this isn't a downside.
more egregiously, the article glosses over two of the biggest and, to
me, most critical differences between the two language. first, go
compiles FAST. i can write something and test it immediately, including
stepping through the code. i dont need to context switch away from the
task and can easily, and quickly, program fixes and changes and
features. this is such a huge development gain that switching away from
it would require an incredibly good reason. secondly, the package
structure of rust offers a clear vector for supply-chain attacks. not
that golang is perfect in that sense, but it has a ton of factors that
reduce the likelihood, and if i'm being really picky about safety it's
going to be a big consideration.
booleandilemma wrote 4 hours 0 min ago:
Rust is not a good language for web development and I'm convinced that
the majority of developers who push it for web development are just
trying to show off.
jurschreuder wrote 4 hours 8 min ago:
I'm moving more and more from Python and Golang to C++.
C++ also forms a natural barrier to entry.
nathanmills wrote 4 hours 7 min ago:
You are Evil.
Surac wrote 5 hours 12 min ago:
Just on Question: Why? Why migrate and open a new can of worms?
cliftonk wrote 7 hours 25 min ago:
I have preferred rust for many years now, but weâll be using models
spitting out 500-1500 or more tokens/sec soon and rust compile times
are glacially slow (while go is almost instantaneous).
sg1apm wrote 7 hours 31 min ago:
Curious about the operational side: did the migration affect your
deployment pipeline complexity significantly? We recently rewrote a
monitoring dashboard from Python/Qt to Go specifically to get a
self-contained binary with no runtime dependencies â the deployment
story for Go is hard to beat for internal tooling even if Rust would
win on performance.
AtNightWeCode wrote 8 hours 50 min ago:
Anybody who actually moved a set of services from Go to Rust? I've
heard that in practice Rust uses more memory than Go for web services.
When I ask LLMs I get the same answer as in the article. A 30-50%
reduction but then also claims on how much memory Go uses. Which is
about 5-10x more than our average service use.
mxey wrote 9 hours 47 min ago:
> You literally cannot dereference an Option without acknowledging the
None case. Whole categories of pager-duty incidents disappear.
This is at the very least misleading, given that you can use unwrap.
Regarding error handling: will a parser error in the config return an
error that includes the name of the file thatâs failed to parse?
Thatâs the kind of useful context that I add to errors in Go.
tuetuopay wrote 9 hours 4 min ago:
The difference is, unwrap will stick out like a sore thumb, and
itâs opt-in. You explicitly tell "this may panic".
As for error handling, this kind of enrichment is usually left to the
caller (that is, the end application), with error libraries like
anyhow where you can add arbitrary string contexts to an error. You
would end up writing `Config::load(path).with_context(||
format!("Failed to load configuration file {path}"))?`.
seabrookmx wrote 3 hours 2 min ago:
While I agree it's better than the golang alternative, it's
definitely still a footgun. See Cloudflare's Nov 2025 outage.
rr808 wrote 9 hours 54 min ago:
One reason I like Go is the fast compile. Rust really slows you down.
Esp in days of AI when agents are building/testing in cycles.
chlorion wrote 5 hours 24 min ago:
How large are your rust projects?
I am able to write rust on a moto g power (a cheap android
smartphone) inside of termux, running on battery, in battery saver
mode, and cached compile times for every single one of my projects is
under 5s easily, if not faster. Fast enough that I don't notice it at
all.
Even a "cold" compile was under 1 minute for me, and I have a decent
amount of deps.
I guess my projects are fairly small compared to others though so
idk.
phplovesong wrote 9 hours 58 min ago:
Go has warts, but projects like Lisette ( [1] ) try to fix those. Go
has bare syntax, as lack some (modern?) features. But imho it has a
superb runtime, eg has a WAY better concurrency story than what you see
in Rust.
(HTM) [1]: https://lisette.run/
JodieBenitez wrote 10 hours 23 min ago:
I'll stick to this advice:
(HTM) [1]: https://kerkour.com/rust-backend-services-problems
jafffsuds wrote 10 hours 28 min ago:
> Thereâs no built-in goroutine-style preemption. Long CPU-bound work
in an async task starves the executor; you offload to
tokio::task::spawn_blocking or rayon instead.
I don't know why anyone uses spawn_blocking for CPU-bound tasks. It's
clearly designed for blocking IO tasks. There's a reason why Erlang
cordons them separately into Dirty CPU and Dirty IO schedulers.
yamapikarya wrote 10 hours 34 min ago:
i like go because it's simple and just works. i like the error
handling, if err != nil return err, i like the philosophy to focus
using stdlib instead choose which libraries are the best for doing x. i
like how go handle the concurrency like using channel or
sync.waitgroup. i am very biased but someday i will also learn rust
drykiss wrote 10 hours 43 min ago:
Quite new to Go, so sorry in advance for a stupid question:
> "Go got generics in 1.18 (March 2022), thirteen years after the
language shipped. They are useful, but they feel tacked on, and in
practice they have most of the downsides of a generic type system
without delivering the upsides youâd expect coming from Rust,
Haskell, or even modern C++."
The problems with Go generics have now largely been solved, haven't
they? Is this comment from the author still applicable?
aatd86 wrote 8 hours 26 min ago:
That's the thing, a programming language is not something static, it
evolves.
For instance, people are working on adding generic methods for the
next release cycles.
And what the article complains about is by design, not a bug. It is a
tradeoff made to avoid bloat.
In any case, given the future possibilities, I'd bet on Go.
If anything, the language is just slower to evolve because every
language change means the tooling needs to catch up. And now llms
would have to catch up.
ChatGPT is still using Go 1.23 for instance...
apatheticonion wrote 11 hours 31 min ago:
I wrote Go professionally for years. Moved to Rust and couldn't be
happier. There are some annoying syntax quirks but they are minor.
After writing web services, GUI apps and terminal apps professionally
in Rust, I honestly struggle to see a use case for other languages.
apatheticonion wrote 2 hours 15 min ago:
Shameless plug. I've been developing a web server library for Rust
based on the ergonomics of the Golang standard library.
It has a router, middleware, and uses AsyncRead, AsyncWrite for the
request/responses.
I use this for my production applications and have found it much
easier to work with than Hyper or Axium. [1] The API is largely
complete but under the hood I have a few things that need doing. Open
to contributions so please feel free to help out
(HTM) [1]: https://github.com/alshdavid-public/uhttp/blob/main/examples...
sylware wrote 12 hours 16 min ago:
What about AI assisted migration?
There was a signal to assist c++ to plain and simple C AI mass
migration.
Removing any languages with ultra-complex syntax towards simple and
plain C is always a good thing.
bnolsen wrote 12 hours 32 min ago:
I would think that you might have a better time going from go to zig.
You would have to provide a pattern for implementing the interface
model go uses.
MeetingsBrowser wrote 12 hours 13 min ago:
What are the benefits of moving from Go to Zig?
It seems like you lose a lot (automatic memory safety, simple
language, easy concurrency) and gain very little.
virtualritz wrote 13 hours 28 min ago:
I would add that Rust also has naming guidelines and sticking to them
removes or at least minimizes the occurrence of another common topic of
discussions on PRs/reviews.
In the article, if you were to mention & follow them GetUser() in Go
becomes user() in Rust[1], not get_user().
(HTM) [1]: https://rust-lang.github.io/api-guidelines/naming.html#getter-...
3uler wrote 14 hours 25 min ago:
Golang is an amazing runtime with a bad language, one that conflates
simple with easy. I view it the same way I view Java: a fine choice for
a corporation, but nothing to love. Although Javaâs gotten a lot
better lately.
DeathArrow wrote 14 hours 23 min ago:
For me having the proper tool for the job trumps loving. I don't have
to love the language, I have to love the process and the end result.
asplake wrote 14 hours 34 min ago:
I
HackerThemAll wrote 15 hours 22 min ago:
The datetime to string conversions in Go are devil's spawn.
kermatt wrote 8 hours 3 min ago:
Share some examples?
sgt wrote 15 hours 32 min ago:
Meanwhile.. Java's still around. Modern, and fits the LLM paradigm
quite well. It's not going to be as amazing or fast as Rust is, but
close.
p2detar wrote 14 hours 35 min ago:
> as amazing or fast as Rust
For cli tools, game engines, etc. certainly so. But what about
monoliths? Do we have enough data to say Rust handles long-running
monolith apps exposing web and other network services better than the
JVM with its hot spot? I havenât come to any stats on that matter,
yet.
nicce wrote 13 hours 1 min ago:
> other network services better than the JVM with its hot spot?
JVM hotspot optimization is just band-aid for something Rust does
always everywhere naturally? Assuming that you use lifetimes etc
properly and not going to Arc rampage.
za3faran wrote 11 hours 22 min ago:
Rust:
concat/string time: [77.801 ns 78.103 ns 78.430
ns]
change: [+0.0275% +0.3169% +0.6169%]
(p = 0.03 < 0.05)
Change within noise threshold.
formatted/string time: [31.471 ns 31.569 ns 31.699
ns]
change: [+0.1277% +0.3915% +0.6788%]
(p = 0.01 < 0.05).
Change within noise threshold.
Java
Benchmarks.concat string avgt 15 8.632 ± 0.105
ns/op
Benchmarks.format string avgt 15 64.971 ± 1.406
ns/op
Java's string concat is faster than rust's offerings.
chlorion wrote 5 hours 20 min ago:
Java is probably able to bump allocate memory or something
similar, where rust is using a general purpose allocator.
I guess if you are formatting strings constantly this is
important, but you can also use a bump allocator in rust if you
really wanted to.
nicce wrote 10 hours 7 min ago:
I would be careful with this benchmark even thought it shows
JIT efficiency. This is a special case which might not really
reflect realworld - string was static? What if you use random
string?
za3faran wrote 4 hours 53 min ago:
It is not a static string, the `param` argument gets passed
in each time. I modified the above benchmark to add an int
parameter in addition to the `param` argument from before.
However now it's testing an itoa as well as it is dependent
on the number of iterations the benchmark suite decides to
run, so it is not as precise, but Java is still ahead.
Java:
@Param({"string"})
public String param;
public int i = 0;
@Benchmark
public String concat() {
return "prefix " + param + " " + i++ + " suffix";
}
Benchmark (param) Mode Cnt Score Error
Units
Benchmarks.concat string avgt 15 26.591 ± 0.242
ns/op
Rust:
fn format2(state: &mut BenchState) -> String {
let i = state.next_i();
format!("prefix {} {} suffix", state.param, i)
}
format2 time: [51.923 ns 52.541 ns
53.466 ns]
Found 10 outliers among 100 measurements (10.00%)
4 (4.00%) high mild
6 (6.00%) high severe
MeetingsBrowser wrote 13 hours 11 min ago:
Indirect evidence, but parts of AWS and cloudflare have been
running Rust in production for close to a decade now and neither
company looks to be itching to move services back to Java.
pas wrote 13 hours 22 min ago:
If you can encode your request processing patterns in statically
sized types, then you can get the same high-level memory allocation
behavior on both platforms. Arguably Rust makes this a bit easier.
(Though I have no idea how much of the concepts of mechanical
sympathy made it to mainstream Java.)
If you have some kind of super vague complicated patchwork of
plugins that all contribute to processing, then the JVM seems to be
the more convenient choice.
(HTM) [1]: https://martinfowler.com/articles/mechanical-sympathy-prin...
DeathArrow wrote 15 hours 44 min ago:
>Go developers donât usually come to Rust because Go is âtoo
slow.â For most backend workloads, Go is plenty fast. People are
generally a bit frustrated with Goâs verbose error handling, the
danger of segmentation faults from nil pointers, and the lack of
generics (for a long time) or any sophisticated type system features,
such as enums or traits. Interfaces are not a worthy replacement for
traits, and the Go standard library has some weird gaps, such as the
lack of a Set type. (The idiomatic workaround is map[T]struct{}, which
works fine in practice but is a tell that the type system isnât quite
carrying its weight.)
If those are issues, I rather use C#/.NET than expose both developers
and AI agents to a cognitive overload.
However, those are not big issues to me, and at least in the present
day, Go seems to excel at the things it is supposed to: backend and
microservices.
Sure, you can find some small issues with Go if you are really
nitpicking, but you can find bigger issues with other languages. Sure,
Go is boring as f..k, but I don't care and the agents don't mind, they
love Go. Most people prefer reading Go than reading Rust. Go allows a
fast way to production and for many startups and small companies, that
matters a lot.
I don't hate Rust, and even use it - for where I think it makes sense,
but for backend and microservices, Go seems a better fit.
As always, this is an opinion, derived from my personal experience,
take it with a grain of salt, your experience might be different.
DeathArrow wrote 15 hours 51 min ago:
TLDR:
>The other prior worth disclosing: I run a Rust consultancy; of course
Iâm biased!
Luker88 wrote 15 hours 51 min ago:
I write purely Go at $dayjob, but I write purely Rust in my projects.
I have a huge list of things that I have in Rust that I would like in
Go, but I don't have a single thing I am missing from Go in Rust.
I grow tired of golang "dumb it down" approach as I find it actually
just shifts more and more work onto me.
Is anyone in a different position? What does Go have that rust does
not?
wanderlust123 wrote 14 hours 33 min ago:
The simplicity of Go is a featureâ¦
rafael-lua wrote 1 hour 30 min ago:
And the one I love the most.
Luker88 wrote 13 hours 57 min ago:
I have to come to believe that Go is simple for the compiler, not
necessarily for the programmer.
`nil` is not simpler than references and Option. lack of enum is
complicating my code. automatic type promotion is a hidden bug
waiting to happen and preventing proper strong types, lack of `?`
is making things verbose. struct tags look simple, until you
realize they are hiding a ton of code and creating a ton of corner
cases that you still have to manually check, and are completely
nonstandard (hello json and `default`, `omitempty/omitzero`
etc...). `nil` and interfaces? it took decades to recognize that
Generics simplify things for the programmer, no Send/Sync like in
rust makes concurrent code more error prone, etc, etc...
And that is without talking about the standard library, where
"simple" somehow becomes having `url.Parse` that accepts everything
without errors. http body `nil` vs `NoBody`. Who hasn't had to
write the Nth implementation of a pipe between reader and writer?
Apparently most libraries hear "simple" and think "dumb". We could
go on for hours.
Golang is much easier to learn, and rust does remain much more
complicated. I don't thing golang hit his target of "simplicity"
honestly.
wanderlust123 wrote 5 hours 18 min ago:
I find working with Go a lot like working with Lego. I agree it
lacks some nice primitives (Result / Option types as you
mentioned) and nil pointers is a flaw, but overall sheer plug and
play nature of the language makes it highly productive. There is
simply a lot less compiler gymnastics between what I want to code
and how to get there. Combined with LLMs to do sanity checks
itâs pretty nice to work with.
runtime_terror wrote 6 hours 48 min ago:
> I have to come to believe that Go is simple for the compiler,
not necessarily for the programmer.
You're welcome to believe whatever you want but Go is pretty
universally known as one of the simpler, easier to learn compiler
languages in existence.
danborn26 wrote 16 hours 0 min ago:
Great writeup. The section on error handling differences is spot on,
especially how Rust's Result type changes the way you structure
application flow.
up2isomorphism wrote 16 hours 56 min ago:
I never feel rust learning curve is steep. It is just everything is
awkward, even more awkward than modern C++.
denysvitali wrote 17 hours 8 min ago:
The article seems to be just a way to say "Rust is better" - and it
fails to do so by spreading misinformation such as the channels part (
[1] ) or making a fair comparison of pprof vs Rust's flamegraph.
It also skips entirely over debugging (delve vs gdb), IDE support,
ecosystem (why the hell does Rust have N async runtimes?!), statically
linking and so on.
A comparison between the performance of RLS / rust-analyzer (painfully
slow) and gopls would be enough to kill the whole argument about
developer happiness and productivity.
It even passes traits as a "reason to switch" to Rust - where in fact
it would probably be a reason (IMHO) not to use it (together with
lifetimes).
I think both languages are amazing, so a migration Go -> Rust (or Rust
-> Go) makes no sense most of the time.
I've written code in both for a while now, so I know the pain and
advantages of both.
For example, Go sucks at microcontroller stuff - in fact it's not even
Go officially (see my presentation about porting "Go" to an ESP32-S3
[1]) - whereas Rust is amazing and even has a strong project behind (
[2] ) and amazing tooling (probe-rs & co).
What's also not addressed here is the Go ecosystem. The Go packages are
one `go mod add` away (pkgs.go.dev) and the module owner guarantees v1
backwards compatibility for the whole lifetime of the module. This
means that, no matter what happens, your dependencies will always be
up-to-date with no migration struggle. This makes creating stuff for
anything around the Kubernets ecosystem a breeze, you can literally
import the types from another project and start your integration right
away.
The most valuable part of the article seems the link to the opposite
view ( [3] ). They're equally biased, but one is more straightforward
than the other.
All in all, it's not a fair comparison and it's very biased (which is
fair) - at the same time I think the idea behind the article is
"wrong". If you find yourself migrating from Go to Rust (or vice
versa), you're likely doing something wrong - and the performance gain
is not the reason you're really doing it for.
[1]:
(HTM) [1]: https://corrode.dev/learn/migration-guides/go-to-rust/#channel...
(HTM) [2]: https://esp.rs
(HTM) [3]: https://blainsmith.com/articles/just-fucking-use-go/
(HTM) [4]: https://docs.google.com/presentation/d/18jWccV-F2FguZiB5gXLkQF...
fithisux wrote 18 hours 25 min ago:
JVM languages to Rust, I understand it somehow.
But Go to Rust???
It does not make any sense.
hu3 wrote 3 hours 42 min ago:
They run a Rust consultancy business. Anything is worth converting to
Rust, for the right price.
shevy-java wrote 18 hours 35 min ago:
Some years ago Go was all the hype rage.
Now Rust is the new Go.
I find that very confusing.
p2detar wrote 16 hours 17 min ago:
Some folks already dropped rust and went with zig. Honestly, to me it
seems only devs at the peak density of the programming bell curve,
are the ones arguing about âthe betterâ programming language.
nirui wrote 19 hours 10 min ago:
> It confuses easiness with simplicity
A lot of libs/packages in Go's stdlib also has this problem. They like
to package everything in a very tight interface (very obvious example
includes crypto/* and http), without exposing implementation detail to
the end user.
Doing this of course has it's benefits, but if the feature provided by
the stdlib slightly don't fit you needs, then you might have to write
your own (potentially unsafe and/or less performant) one from zero.
Rust is great overall, but there's some oddities. For example their
lib.rs / `mod` is very, very unintuitive, it felt overdesigned and
unnecessarily complex (just see [their book]). I like what Go or Java
did to their lib/package systems, it's much better that way.
[their book]:
(HTM) [1]: https://doc.rust-lang.org/stable/book/ch07-05-separating-modul...
magicalhippo wrote 19 hours 6 min ago:
I've come to hate hiding internals. Put them in a namespace which
makes it clear there's no API stability guarantees, but make them
available if needed.
As you note it's just pain with no gain to properly hide them. Users
can't readily work around bugs or extend functionality.
netheril96 wrote 22 hours 13 min ago:
I've swinged between Go and Rust for my personal projects multiple
times. For work, it is decided by the management so not my problem.
The biggest gripe I have with Go is the lack of *any* compile time
check for mutex. Even C++ has extensions like ABSL_GUARDED_BY. For a
language so proud on concurrency, it is strange not to have any
guardrails.
ted_dunning wrote 22 hours 1 min ago:
The guardrails are channels.
If you have a mutex on a structure, linters such as are packaged into
Goland will catch oversights quite effectively.
If you are using fancier concurrency structures, you should consider
channels instead.
netheril96 wrote 21 hours 30 min ago:
Channels are not for everything. Plenty of mutex cases cannot be
rewritten as channels, or will be very unwieldy so. In fact, every
large Go project I have seen uses mutex here or there.
kune wrote 18 hours 5 min ago:
Theoretically you can use channels to simulate a mutex, but I
agree with you there are use cases where a mutex makes more
sense. They are even used in the standard library, for instance
to implement sync.Once.
But generally I would agree that if you need to code parallel
execution, channels are a good way to do it, because you can
avoid race conditions if you share data only over channels. The
biggest problem is that a lot of people don't understand, that
channels with a buffer larger than 1 are a sign of problems in
the architecture.
There is a type of parallel programming with workers for specific
functions, that always leads to performance issues. The problem
is you need to right-guess the distribution of work, when you
have to define the amount of workers for a specific function. At
least one go routine for one request is a much better approach
than function-specific workers.
hebetude wrote 22 hours 33 min ago:
Not sure the article is ⦠accurate? Go has a large standard library.
Rust leans on third party cargo libraries which fall into the supply
chain attack and has a small standard library. Anyways, that feels
immediately biased in the article. Also 11% use Rust? I donât see
that penetration in real long term products. Sure lots of tui apps
these days but not things that you can make money working on.
whilenot-dev wrote 22 hours 12 min ago:
> Also 11% use Rust?
These percentages are from the JetBrains State of Developer Ecosystem
Report 2024 on the question "Which programming languages have you
used in the last 12 months?"[0].
I think a better datapoint would be the "Primary Programming
Languages" in the 2025 report[1] where Rust sits at 4% and Go at 8%.
[0]: [1]:
(HTM) [1]: https://www.jetbrains.com/lp/devecosystem-2024/#KeDHWJ
(HTM) [2]: https://devecosystem-2025.jetbrains.com/tools-and-trends
zjy71055 wrote 22 hours 36 min ago:
I was a Go engineer for years and have shipped a lot of Go. I never
properly learned Rust.
Over the past year I've been using AI to write small Rust tools for
myself â I barely read the code, and honestly it just works.
But for serious projects I expect to maintain long-term, I still pick
Go. Today I want code I can actually own and reason about myself.
Give it a year or two and I probably won't be writing code by hand at
all. Once the AI owns the code anyway, that reason disappears â and
at that point Rust's guarantees win. So I suspect I'll end up leaning
Rust.
euroderf wrote 20 hours 57 min ago:
> But for serious projects I expect to maintain long-term, I still
pick Go.
Maintenance is a big win for Go imho - that you can go to code you
wrote a year or more ago - and jump right back into it, with
little-to-no re-learning curve. The syntax is not providing cover for
complexity bombs, and the tools keep the workflow simple and quick.
How is it with Rust ? Does one's own old code remain maintainable ?
h4kunamata wrote 1 day ago:
Read migrating from one hype to another, developers never learn or
change, do they??
It feels like yesterday when every single project was moving to Go just
because it was the new hype, that was until Rust was born.
We are already seeing projects dumping migration to Rust because the
grass is not always greener on the other side.
We will be seeing this again, "Migrating from Rust to XYZ"
dilyevsky wrote 1 day ago:
> Under heavy allocation, P99 latency tails are noticeably worse than a
Rust equivalent that simply doesnât allocate on the hot path.
Lmao so not an equivalent then? Standard glibc malloc, which is default
in rust, will also similarly degrade albeit for different reasons.
LoganDark wrote 1 day ago:
I still think rustfmt made a mistake by going with four spaces. It's
basically inferior for everything except forcing everyone to use the
same indentation width, which is actually a downside, since I
constantly encounter two-space indent codebases that I can't read and
also can't change to four spaces because it's not tabs. Also
translating spaces to tabs visually is undecidable thanks to alignment,
while the inverse is not true. Ugh.
cyann wrote 1 day ago:
I've got a `.rustfmt.toml` file in all my repos with
hard_tabs = true
LoganDark wrote 1 day ago:
Yep, but because it's not the default, plenty of ecosystem tooling
just does not properly track the two separate types of leading
whitespace (indentation vs alignment) and will happily conflate
every tab_width characters of alignment with an indentation level
(which is grossly incorrect). I don't have an example off the top
of my head because I run very far each time it happens.
hasyimibhar wrote 1 day ago:
It is also easier to make your code deterministic with Rust vs with Go,
which is incredibly useful if you need to perform deterministic
simulation testing + property-based testing. I recently wrote a
Postgres-to-Iceberg data mirroring tool [1] in Go, but I ported it to
Rust because I wanted the ability perform DST without fighting Go's
runtime [2]. But if the domain is not critical that warrants DST, I
would still pick Go over Rust any day. [1]
(HTM) [1]: https://github.com/polynya-dev/pg2iceberg
(HTM) [2]: https://www.polarsignals.com/blog/posts/2024/05/28/mostly-dst-...
wpollock wrote 1 day ago:
Very nice write up! I am a fan of Rust and have little exposure to Go.
That said, a couple of very minor points:
cargo audit is not built-in, it is 3rd party. (The comparison table
near the top isn't clear about that, and the following text stating
more is built-in for Rust than for Go might be confusing. I would
suggest adding an asterisk to mark built-ins in that table.)
cargo watch has been in "maintenance mode" for some time. The author
of that suggests cargo bacon instead.
tptacek wrote 1 day ago:
This is a weird document that is simultaneously trying to serve as a
migration guide and an advocacy document for Rust.
Ultimately, if you have to ask, the Rust vs. Go consideration boils
down almost completely to "do you want a managed runtime or not". A
generation of Rust programmers has convinced itself that "managed
runtime" is bad, that not having one is an important feature. But
that's obviously false: there are more programming domains where you
want a managed runtime than ones where you don't.
That's not an argument for defaulting to Go in all those cases! There
are plenty of subjective reasons to prefer Rust. I miss `match` when I
write Go (I do not miss tokio and async Rust, though). They're both
perfectly legitimate choices in virtually any case where you don't have
to distort the problem space to fit them in (ie: trying to write a Go
LKM would be a weird move).
The Rust vs. Go slapfight is a weird and cringe backwater of our field.
Huge portions of the industry are happily building entire systems in
Python or Node, and smirking at the weirdos arguing over which
statically typed compiled language to use. Python vs. (Rust|Go) is a
real question. Rust vs. Go isn't.
KajMagnus wrote 12 hours 43 min ago:
Aren't you overlooking the main point of the article?, the reason
they migrated:
> concurrency â eliminating data races essentially, which we had
before. Really gnarly bugs
> this is the one teams report most enthusiastically. The classes of
bugs that survive go test -race and reach production (data races, nil
dereferences, missed error paths) just donât compile in Rust.
Oncall rotations are typically very boring after a Rust migration.
...
> I hadnât had to chase down a crash, or some weird multi-threaded
race condition, or some of these other things which actually consumed
a huge amount of my time before.
(They say at InfluxDb)
That's not a Rust vs. Go slapfight? Instead, sounds like a good
judgement to me
bborud wrote 14 hours 55 min ago:
For the vast majority of software you want a managed runtime.
Some of the problems Rust âsolvesâ are problems you shouldnât
be having in the first place because we mostly write software that
doesnât need direct control over memory. Borrow checking isnât
something you want to have to deal with - it is something you have to
accept when you have chosen to manage memory. That choice has a high
cost that cost never gets paid off in most projects that could work
just as fine with managed memory.
Iâm a Go programmer, but this article reminded me that I should
have more experience with Rust. From my perspective Rust seems a bit
less practical. The standard library lacks support for cryptography,
for instance. The compiler is slow, which is a productivity killer.
Overall concurrency seems like a bit of an afterthought. Again.
What makes me want to try Rust in production are things like option
types. Those would be nice to have in any language. Any issues that
can be caught by the compiler are a plus. Getting rid of nil would
also be a plus, but to be quite frank, I donât experience that many
nil pointer errors.
The author does nod to the static analysis tools for Go. Yes, they
are not part of the compiler (for good reason), but they do a pretty
good job in practice. So you get more than the compiler can promise
at a fraction of the cost (measured in build time). Thatâs a much
bigger deal for actual developers than we generally give it credit
for.
Then thereâs the stuff that makes me less convinced in terms of
arguments. For instance the fact that Go didnât have generics
early on and that the standard library doesnât use them. Generics
were not as important as people thought they were. In practical
reality. The fact that the standard library doesnât make wide use
of them is not a weakness, it shows restraint. They didnât go
overboard and prematurely plaster generics all over the place as soon
as the language supported it. This is the kind of restraint you want
to see. Remember how horrible Java was after everyone started
abusing generics? A brief generation of software that was
significantly worse, and less maintainable resulted from this
exuberance. For the ultimate example of what happens when you give
people every feature they wish for: look at C++. It´s not a very
good language because it is many languages. Just because there are
standards and recommendations doesnât mean that all code magically
gets rewritten to a narrower definition of the language. It means
that we accumulate intermediate forms. I expect people who are
interested in languages to understand these dynamics.
pas wrote 13 hours 52 min ago:
Rust's stdlib is small, Go took more of Python's "batteries
included" strategy.
So in that sense it seems like a category error to try to look for
crypto stuff in the standard library. Of course this brings the
well known problem of "okay, but then which one should I use?".
Nowadays this is largely solved by a few web searches and LLM
queries, and people are quite helpful at [1] .
Go was shaped by the needs of Google, Rust is a wildly successful
amazing experiment in programming language and compiler design that
really got out of hand :) (A bit like JavaScript! Or even C#! Or
Python. Same growing pains (async/await!), but arguably on
different levels.)
(HTM) [1]: https://old.reddit.com/r/rust/
bborud wrote 5 hours 16 min ago:
It turns out that the needs of Google overlaps significantly with
the needs of software engineers outside Google. That argument
could have been valid for a while after its initial release. But
now it is just a lazy argument today.
I think batteries included is a better strategy. To the degree
where I think Rust should reconsider this decision.
jbreckmckye wrote 3 hours 40 min ago:
It also means that everything is (over) optimised for Google's
usecases, but not general purpose applications
I came across this problem pretty directly a couple of weeks
ago - I wanted to see if I could port a small C program to Go,
where one of the needs is to create gzip archives. But the Go
stdlib insists on extraneous padding that breaks the backwards
compatibility requirements of my program.
The padding isn't needed, it isn't useful, and you can't opt
out of it. So the whole program went in the bin and I have
resumed maintaining it in C
This is one of dozens of situations I've experienced where Go's
allegedly pristine stdlib design has kicked me in the nuts
bborud wrote 3 hours 16 min ago:
How is this «optimized for Google»?
jbreckmckye wrote 2 hours 57 min ago:
Somebody at Google decided this is how they wanted it to
work. They don't have to explain why and they don't have to
fix this deficiency until it becomes a problem for Google
pas wrote 4 hours 9 min ago:
Rust likes to do things neat and proper and inclusive and
community and zero-cost (or ALARA [as low as reasonably
achievable]), and so on.
But there's no theory of standard library that they could
implement. Shipping things together makes sense, but the
maintenance burden is already significant, and there's also no
theory of "ethically cloning open source maintainers".
I'm also quite squeamish when I think about all the unvetted
dependencies, so yes, there's definitely a need, but I don't
think slapping a stdlib tag on millions of lines of code would
lead to great things.
But sure, I think someone could champion the case to introduce
a process for adding projects to the standard packages. The
projects would need to show some competence, commitment to
quality and security. And the process obviously needs to have
an orderly procedure for deprecation, and for "non maintainer
updates" (like Debian has, for example).
tptacek wrote 8 hours 1 min ago:
Have you argued yourself to "it's a bad thing that the Go
standard library has a cryptography library"?
wting wrote 5 hours 29 min ago:
Rust has clearly opined that they prefer a small standard
library and a "choose your own libraries" vs "batteries
included" approach.
If Rust included a crypto lib and a vulnerability was
discovered, many fixes are backwards incompatible. Rust
maintains strict backwards compatibility, which means updating
the relevant crypto functions in the std lib would necessitate
a major version bump. By keeping crypto outside of std, it
allows the community to make backwards incompatible changes at
a higher pace.
Python handles backward incompatibility changes via multi-year
deprecations. I'm not familiar with Golang but a quick Google
search reveals that it deals with this by using feature flags
via GODEBUG. Excessive feature flag use is a bad pattern in my
experience years ago, but I don't know if that's applicable
here.
I prefer the trade-offs of a "choose your own lib" approach,
but I understand the advantages and preferences of those who
prefer a "batteries included" approach.
Hendrikto wrote 4 hours 58 min ago:
In general, I get your argument, but cryptography is the
perfect example for something so well-specified,
well-understood, and extremely widely used, that these
arguments do not really apply. You are not going to have to
make backwards-incompatible changes to SHA256 or Poly1305,
etc. It has minimal API surface too, and is not going to be a
large maintenance burden. But nearly everybody is going to
need crypto at some point. It is great to have blessed and
well-audited standard implementations that people can rely
on, without even having to make a choice. This it is not
something where you want âthe community to make backwards
incompatible changes at a higher pace.â.
Crypto is something any modern language should include in the
stdlib, imo.
tptacek wrote 4 hours 25 min ago:
Proviso: you do cryptography in the stdlib if you have the
means to do it well. Go did; Filippo Valsorda has built a
whole company practice on keeping that library excellent.
Certainly, that's a better outcome than just providing
bindings to OpenSSL, which is what most other languages do.
ruicraveiro wrote 16 hours 20 min ago:
Indeed, if I were proposing contributions to the Linux kernel, or any
other kind of systems development, I'd probably be considering Rust.
For backend services, the decision is between C# and Go (with the
latter being the favourite).
foretop_yardarm wrote 16 hours 21 min ago:
It sounds like you should try ocaml
kubb wrote 16 hours 48 min ago:
It feels like youâre upset because your favorite language has
objective flaws that people are pointing out. Youâre also trying to
minimize peopleâs lived experiences and pleading with them to stop
pointing the flaws out.
Sure, Go is better than Python in some things. But developers deserve
the best. We deserve not to have to deal with Goâs quirks,
idiosyncrasies and design mistakes.
Hendrikto wrote 4 hours 50 min ago:
> We deserve not to have to deal with [â¦] quirks, idiosyncrasies
and design mistakes.
True but unrealistic. Every language has warts, including Rust.
nihsett wrote 19 hours 22 min ago:
Exactly. 95% of programmers are application programmers - they ship
software used by regular users. I think it's insane to use a non-GC
language for most of those cases. Manual memory management is
mentally taxing and it's easy to make catastrophic mistakes. The
marginal benefit from it is just not worth it unless you're making
games or a trading system.
5% who write tools or other "infra" layer for the other 95% to work
on top of maybe need that level of control over memory. It doesn't
make any sense to me to sign up for that complexity unless you really
really need it.
deagle50 wrote 8 hours 33 min ago:
Or it could be insane to pay the cloud memory costs when you have
tools that can write rust for you.
tptacek wrote 8 hours 3 min ago:
What "cloud memory costs"? Most Rust code is an
informally-specified version of the old Python reference-counting
GC. That's how you're supposed to write it, with clone()
everywhere, and then dropping down to optimize. You can do the
same thing with Go in the other direction by writing an
allocator.
People believe a lot of weird things about these languages.
deagle50 wrote 6 hours 26 min ago:
Why would I roll custom allocation strategies in Go (and then
be accountable for supporting them) that affect multiple teams
and services when I can have an LLM port to Rust and get dozens
of additional benefits?
tptacek wrote 4 hours 23 min ago:
Depends on whether you'll ever need to use a mutable shared
tree structure in your project, I guess.
But do remember that the logic you're using depends on nobody
on your team reading the LLM code. If you're close-reading
LLM outputs, all the complexity of Rust's memory management
model is back on the table.
tcfhgj wrote 11 hours 27 min ago:
> and it's easy to make catastrophic mistakes
such as ... ?
joaohaas wrote 13 hours 8 min ago:
This post is specifically about backend development, where you're
not shipping software to regular users.
thingortwo wrote 12 hours 44 min ago:
This is just a matter of perspective. Backend IS being "shipped"
to user via the API be it go or rust and inevitably the details
and behavior do leak out to end user.
kalaksi wrote 19 hours 4 min ago:
Maybe I'm misunderstanding something but non-GC language doesn't
mean you have to do memory management manually? I mean, for
example, in Rust (or modern C++), it's basically automatic. There
is no mental tax or catastrophic mistakes as far as I know.
bborud wrote 14 hours 50 min ago:
You seem to imply that it doesnât have any cost. It does. You
have to make decisions and, in the case of C++: sometimes you
have to deal with a lot of really ugly code to make it
âautomaticâ. And if you really have to count bytes and
carefully manage stack sizes because you are writing code for a
constrained device, you have to pay even more attention than you
would in C.
GCâed languages have memory related challenges too. But it
simply isnât true that these are on the same order of
difficulty as the difficulties that do arise in C++.
kalaksi wrote 12 hours 22 min ago:
Yeah, I shouldn't have mentioned C++, it was a bad example.
tptacek wrote 18 hours 46 min ago:
Ok. [1] I'm not saying Rust is worse than Go. It obviously isn't.
But this argument that Rust's memory management isn't more
cognitively demanding than Go's memory management --- that isn't
true.
(HTM) [1]: https://rust-unofficial.github.io/too-many-lists/
tialaramex wrote 15 hours 23 min ago:
How is Aria's linked list document relevant on this topic? Go
is the kind of language where they'd call their growable array
type "List" because why not. C# did that in fact, when it
gained generics they named their generic growable array List
So the linked list is a thing Go doesn't have at all, in Go the
equivalent document probably just reminds you of Go's rule
"Don't be clever". Thanks Go, I'll keep it in mind.
Generally the argument is that non-GC languages require you to
worry about memory management because of Use-after-free, but of
course safe Rust just won't compile if you wrote a typical
use-after-free so that's not really extra cognitive demand.
rstuart4133 wrote 16 hours 7 min ago:
> But this argument that Rust's memory management isn't more
cognitively demanding than Go's memory management --- that
isn't true.
It's not far from true. The fights you get into with the borrow
checker can be legendary, but lifetimes serve more as gentle
reminders. If you get stuck, you can always just use Rc, which
is pretty close to opt-in GC. But it's rare to have to resort
to Rc, because ownership is just not that much of a problem. In
fact, I very rarely use Box either. All heap memory allocation
is done by containers, not manually by me. I guess the main
friction point for lifetimes is Rust's closures and async, but
if you avoid them life is pretty simple.
In return for wearing this almost not a problem, you almost
don't have to think about releasing a whole pile of other
things - like closing files, sockets, and locks. They are
guaranteed to be released by the same mechanism.
On balance, I would not be surprised if the cognitive balance
tips Rust's way once you allow for the fact that Rust's memory
management also gives you robust resource management for free.
BlackFly wrote 18 hours 6 min ago:
Certainly you pay a price for lifetimes but you buy compile
time race condition detection via the borrow checker's
aliasing-xor-mutability enforcement. So all that is happening
is the complexity of concurrency is being made explicit and
therefore easier to reason about. Many applications can be
architected in a way that wouldn't ever trigger a race, so for
people working on that it isn't something they would need to
reason about and they can call it unneeded complexity. This is
the simpler vs. simplistic distinction also made in the
article. If you can be simplistic, garbage collection is less
cognitively demanding, but if you are designing race free
algorithms with shared memory then rust will be. I do believe
more developers and applications live in the former.
The better example actually comes from the article: returning a
struct and an iterator over that struct isn't possible in rust.
Heck, initializing a struct to return an iterator might lead to
issues. Most people will encounter this before needing a linked
list and the lesson it teaches will help out with the linked
list.
tialaramex wrote 15 hours 10 min ago:
Rust doesn't promise that your safe Rust doesn't have race
conditions only specifically that it doesn't have the one
very weird kind of race condition from computers with no
analogue to the real world, a Data Race.
An ordinary race condition would be e.g. you put the cat out
of the front door, then you walk to the kitchen and close
that door - well, the cat might race around the outside of
the house and get in first. Our world has race conditions,
Rust doesn't solve them, take appropriate care.
A data race is much stranger, it's caused by a difference
between how humans think about programming ("Sequential
consistency" ie time's arrow X causes Y, therefore Y happens
after X) and how the machine works (a modern multi-core
computer does not exhibit this consistency) maybe you and
your house mate both pick up the cat and she tries to put it
out the kitchen door, you try to put it out the front door,
this seems to work fine mostly but then on Tuesday the cat
explodes, everything is covered in cat fur, messy. Rust
actually has a whole layer of extra stuff beyond the
aliasing-XOR-mutability to prevent this mistake because
humans struggle to reason properly about software which loses
sequential consistency so it almost doesn't matter what it
"means" if this is lost.
BlackFly wrote 13 hours 21 min ago:
> In logic, equivocation ("calling two different things by
the same name") is an informal fallacy resulting from [...]
knowingly and deliberately using words in a different sense
than the one the audience will understand.
Of course I mean data race, most people in such a thread
will implicitly understand that is the race meant. Nobody
building a webshop with limited supplies wants to prevent
"first come first served", it barely makes sense to think
about preventing that kind of race
Data races have obvious real world analogues, they are just
so obvious people naturally synchronize. You can look over
someone's shoulder while they update a paper master copy
and observe data tearing as they erase a field and start
writing in another value while that is inconsistent with
the rest of the form. It is easy to see that data is being
modified and wait until the writer is complete instead of
memorizing a partial update and walking away to make
decisions on the basis of the incomplete information. A
good mutex/rwlock is like having a private separate room to
go into to make the update so that no overeager person can
even observe the partial update (some languages have non
callback style mutexes so there the mutex/lock is the
analogue of the visual cue that someone is performing the
update). I don't find this at all strange to consider. In a
concurrent system it is just all too easy to forget that
there are other threads (analogue of people)
reading/modifying at the same time. So rust makes that
manifest through the borrow checker and it becomes obvious.
Rust prevents more than just data races. Even in single
threaded code, if you have a reference to a struct (without
explicitly choosing interior mutability), you are
guaranteed that its value has not changed since the last
time you read it, despite other parts of the code having a
reference to it. You don't need to make defensive copies.
Some people may find this useful, but generally it won't be
enough to convince someone to drop their current language
in favor of rust. This transfers into multi-threaded code
as well: only a single thread can make modifications to a
struct through a reference xor as many threads as you want
can read from the struct with references. You can easily
write go/java/python programs that have these features and
so don't feature data races, but they are difficult to
reason about: how do you know that there is only a single
reference featuring mutation or many threads only reading?
The answer requires non-local knowledge which is difficult
to reason about and this is enough for some people to
consider rust where the answer is local (defined by the
variable).
tialaramex wrote 4 hours 5 min ago:
> Data races have obvious real world analogues
No they don't, as you handily illustrated by offering no
actual data race analogies but instead managing to
confuse loss of atomicity with a data race. It's OK
though, so long as you write only safe Rust you can't
blow your own foot off even though you didn't understand
how the explosives work.
And actually people write other race conditions all the
time, particularly ToCToU races are very common, and as I
explained Rust doesn't prevent those - although a Rust
library you're using might go out of its way to be
friendly by directing you away from them as Rust's own
file system stdlib functions do.
kelnos wrote 20 hours 7 min ago:
> the Rust vs. Go consideration boils down almost completely to "do
you want a managed runtime or not".
That's not really something I care much about. My beefs with Go are
90% about the syntax of the language itself, and it's weak (compared
to Rust) type system.
When it comes to a managed runtime, for most tasks, I generally don't
care if my language has one or not. For some tasks I do, but there
are not many of those tasks, and so this question is mostly
irrelevant to me when deciding Go vs. Rust.
I don't really get where you're seeing that the predominant Go vs.
Rust debate is about the runtime. IME it's the subjective stuff
about the languages themselves, and their ecosystems and communities.
> The Rust vs. Go slapfight is a weird and cringe backwater of our
field.
::shrug:: I dunno, I mostly stay out of it and just use Rust, and I'm
happy and avoid the drama. I've written a little Go here and there,
didn't really like it, and moved on.
tptacek wrote 19 hours 54 min ago:
That's totally fine. I don't get why people moralize this stuff.
Both of these languages are rounding errors compared to the dynamic
languages.
pas wrote 13 hours 32 min ago:
Because it triggers the "feeling of other" when someone is so
close yet so far ideologically.
I'm sure you know this joke about dogmas :) [1] In some sense
this is the same as the NIMBY/YIMBY question. There are perfectly
valid reasons to want to live like Spacers do on Aurora, yet many
prefer the caves.
(HTM) [1]: https://news.ycombinator.com/item?id=26624442
kelnos wrote 19 hours 48 min ago:
I think people do this for every language. It becomes a part of
their identity, and then they have to defend it. I used to do
that too, long ago, but I don't have the time or energy for it
for the most part, and find it boring, so that
$LANG-user-as-identity bit of my has fallen by the wayside.
I don't think it's about adoption levels; sure Go and Rust are
tiny compared to JS/python/etc. It's emotional, not about who
has the most users or who can even plausibly get there.
onlyrealcuzzo wrote 1 day ago:
> Ultimately, if you have to ask, the Rust vs. Go consideration boils
down almost completely to "do you want a managed runtime or not".
You don't need a garbage collector which is perhaps half of the Go
Runtime when you're using Rust.
You can also bolt on a few crates and get ~95% of what you'd get from
Go's runtime.
Go has the best runtime in the world. I'll give it that.
But this is not the only reason...
tptacek wrote 1 day ago:
You obviously don't need a GC when you're using Rust, because Rust
doesn't plausibly have one.
onlyrealcuzzo wrote 1 day ago:
Right, so you don't need a large portion of Go's runtime
benefits, because you have a far better version of it already,
zero cost abstractions and TRUE memory safety, not pretend memory
safety behind a -race detector with zero compiler guarantees...
tptacek wrote 23 hours 42 min ago:
I don't know who you're speaking to, but it isn't me; I
certainly didn't ask for the standard-issue Rust langwar pitch.
tempest_ wrote 1 day ago:
The use of LLMs has caused Rust usage to explode.
If youre not writing the code yourself and vibing away which I think
most people generally are despite the disdain around here then why
would you not choose the "more performant language" (I know that isnt
necessarily reality but it is a common perception).
Go's managed runtime is less valuable when the LLM is perfectly happy
to slap a bunch of stuff together for you to and approximate it and
doesn't complain at all when writing async rust despite some of the
rough edges.
PaulRobinson wrote 17 hours 50 min ago:
By that reasoning, we should all be vibing away C code. It's the
most performant and efficient language out there, there's a ton of
code out there the LLMs were trained on, and the complex logic of
memory management is abstracted away by the LLM so you don't need
to think about it.
Most people are not doing that though. There's probably a good
reason, and it applies to other languages too.
fg137 wrote 12 hours 16 min ago:
There is a good chance that your vibe coded C program segfaults
immediately upon running and contains lots of subtle logic
errors, all of which requires many iterations (finding issues at
runtime) before you program runs as expected.
With Rust, you'll likely get many compilation errors, but if your
syntax is correct, compilation errors will be few, and your code
will almost certainly just work.
tptacek wrote 10 hours 35 min ago:
I wouldn't build anything in C that I didn't absolutely have
to, but, no, there is not in fact a good chance that your
vibe-coded C program segfaults immediately.
risyachka wrote 17 hours 8 min ago:
In order to use C you need to actually understand it, also
toolchain is more complex etc. Which makes it a no go for 99%.
Rust is so safe that anyone can vibe it without any idea what is
going on there. Which is basically what is happening here.
And why rust is more used than go for vibecoding? Mostly because
of hype and performance gains which 99.9% of projects do not
need.
tcfhgj wrote 11 hours 22 min ago:
> performance gains which 99.9% of projects do not need.
most software isn't "needed"
majormajor wrote 20 hours 35 min ago:
> The use of LLMs has caused Rust usage to explode.
Rust had a "vibey" community long before vibecoding. In particular,
it's long been fairly non-serious about yolo importing a bunch of
crates to solve things (since the standard lib is small) which is
kinda the same problem as having all those things just vibecoded.
Either way, most projects weren't reading all of that other code!
lanstin wrote 21 hours 55 min ago:
I like vibe coding but I am sceptical that a vibe coded runtime in
Rust would be as awesome as the Go runtime which is written with
deep expertise of Unix software and threading and many low level
details that are subtle and do depend on global properties of the
code to work flawlessly. It makes sense you can crank out Rust with
an LLM if you know what you are doing, but if you want a GC type
thing or preemptive scheduling across an N by M threading model,
then you are competing against some very good code.
LtWorf wrote 19 hours 9 min ago:
> the Go runtime which is written with deep expertise of Unix
software
Go has no mmap(), import a 3rd party dependency for that and
you'll get a segfault the very second you do a mistake.
Python has an mmap module which will catch many memory errors and
present them as exception rather than causing a CVE.
tptacek wrote 18 hours 40 min ago:
I don't agree with the parent comment, but mmap is exposed
(low-level) in the standard library and there's a high-level
wrapper in x/exp. You need to be careful with mmap no matter
where you're using it.
What Go mmap CVE were you thinking of?
LtWorf wrote 17 hours 11 min ago:
> What Go mmap CVE were you thinking of?
Every time you see "segmentation fault", that right there is
a CVE.
tptacek wrote 10 hours 36 min ago:
No, obviously.
LtWorf wrote 4 hours 41 min ago:
Because you don't report and open the CVE, not because it
isn't a security issue :)
tptacek wrote 4 hours 30 min ago:
No security practitioner agrees with you about this.
Please don't troll.
hu3 wrote 23 hours 54 min ago:
Correction: The use of LLMs has caused every major language usage
to explode.
And as mentioned in other comments, Rust slow compilation can be
detrimental to LLMs + fast iteration speed. And it's not just
speed, Tauri takes 20GB of disk space to compile. It's bonkers.
This is npm/js ecosystem all over again but slower.
Another reason to pick Go if you're leaning on LLMs is the standard
library. Often you can do more work with fewer dependencies.
I'd rather leverage world class engineers paid by Google to
maintain dependencies for me than try my luck with half a dozen of
0.x crates. Plus stdlib APIs can (and are) versioned just like
third party dependencies.
Aurornis wrote 5 hours 27 min ago:
> And it's not just speed, Tauri takes 20GB of disk space to
compile
Iâve worked with enough UI frameworks and large applications
that this doesnât sound unreasonable. Itâs a smaller disk
footprint than Iâve needed for several other C++ codebases with
similar scope.
wanderlust123 wrote 22 hours 50 min ago:
Fully agree with this. We use Rust in an enterprise setting for
building web app backends and the experience is painful. A lot of
crates just seem like someones side project. Too many ways to do
things leads to bike shedding in PRs. Compile times are atrocious
and can take like 30 mins to build.
Honestly using Go would have got us to the same point much
quicker, with code that is much easier to review.
tptacek wrote 1 day ago:
I agree that agents make Rust a lot more tenable for less
"kernel-and-browser"-demanding tasks than it was 4 years ago, but I
do not agree that they eliminate the "managed vs. unmanaged
runtime" question, and to the extent they influence any of this
decisionmaking at all, you have to accept the notion of not reading
the code. If you're reading it, it matters that Rust makes you do
bookkeeping that managed runtimes avoid.
galangalalgol wrote 1 day ago:
I think I'd be ok with node via purescript? But in general I think
rust and go people should join forces against the evils of dynamic
typing. Isn't type hinting finally considered best practice now? I
think that is effectively an admission that it was a defect. And even
with good ginting it is still worse than inference. Inference can let
plenty of code go untouched on type changes, while still protecting
against unindended type changes.
com2kid wrote 1 day ago:
Us Node folks adapted typescript because we wanted static compiled
types.
I wish TS had more of a runtime. The only thing I'm jealous of with
regards to python is how seamlessly you can do JSON schema
enforcement on HTTP endpoints. The Zod hoops are a constant source of
irritation that only exists because the TS team is dogmatic.
ngrilly wrote 7 hours 17 min ago:
> The only thing I'm jealous of with regards to python is how
seamlessly you can do JSON schema enforcement on HTTP endpoints.
Yes, it is much easier in Python because type annotations are
reflected at runtime.
Recursing wrote 16 hours 43 min ago:
express-zod-api works well for me [1] I'd say about as well as
anything Python
(HTM) [1]: https://github.com/RobinTail/express-zod-api
com2kid wrote 2 hours 53 min ago:
Typescript supporting runtime usage of types instead of making me
define them in Zod first would be 100x better.
Or at least support a standard for code transform plugins.
satvikpendem wrote 21 hours 35 min ago:
Check out Perry the TypeScript compiler to native code
tptacek wrote 1 day ago:
I think Typescript is a perfectly cromulent language. I don't know
it well but would seriously consider it for any problem that had a
shape that admitted a dynamic language. There's a lot to be said
for using dynamic languages, too!
com2kid wrote 1 day ago:
Every non-runtime language is dynamic after being compiled to x64
machine code!
It is illusions and lies all the way down the instant the
compiler finishes its job.
cbondurant wrote 1 day ago:
I already use Rust and don't have experience with Go, so this article
maybe isn't super for me.
I do have one nitpick though: Stating that data races are "caught at
compile time" in Rust feels like it is overstating the case, at least a
little. It sounds a bit like its implying Rust can also handle things
like mutual lock starvation, or other concurrency issues. When that's
simply not the case. I know "data race" is technically a formal term,
with a decently narrow scope, yet I still think it could be a bit
clearer about it.
amelius wrote 1 day ago:
Go has shorter and more predictable GC pauses. If a reference count
drops to zero in Rust, it may take an unbounded time to free all the
things it refers to (recursively if necessary).
cube00 wrote 22 hours 10 min ago:
I still prefer having deterministic control over when the free
occurs.
For example, I can transmit the response to the client and then free
the memory afterwards so they're not kept waiting.
za3faran wrote 10 hours 11 min ago:
What if you have many clients that are constantly coming in, when
do you decide to free the memory after sending their respective
responses?
amelius wrote 14 hours 31 min ago:
Can't use that approach for a GUI.
0xfurai wrote 1 day ago:
The "when to enforce it" framing is what sticks with me. Go and Rust
agree on safety, concurrency, simple deployment, but Go says "catch it
in review" and Rust says "catch it before it compiles." The right
answer depends entirely on how expensive a production incident is for
you vs. how expensive slower iteration is.
euroderf wrote 20 hours 56 min ago:
And TLA+ and Lean say "catch it before you write any code".
LtWorf wrote 1 day ago:
> but Go says "catch it in review"
So, in production?
airstrike wrote 1 day ago:
It's AI slop, it makes no sense
nemo1618 wrote 1 day ago:
LLM writing tells are getting more subtle, but they still jump off the
page for me, in particular the word "genuine:"
"This is the area where Go genuinely shines, and itâs worth being
precise about why"
"the lack of GC pauses is a genuine selling point"
"Humans are genuinely bad at reasoning about memory"
"There are cases where the borrow checker is genuinely too strict"
tbc I don't think the article was fully AI-generated, just AI-assisted.
If so, the author did a genuinely good job of it! No one else is
commenting on it, so clearly it didn't detract much from the substance.
It's just weird that this is becoming increasingly common, and
increasingly hard to detect.
mre wrote 10 hours 55 min ago:
Author here. I use the term 'genuinely' too often, but that's just
me. I do that when speaking here as well. Suffice to say that I'm not
a native speaker, so that might have something to do with it. I will
go over the text and replace some of those. thx.
kstrauser wrote 8 hours 17 min ago:
My own iA Writer flags are great, love, hope, literally, "but,",
and genuinely. Sigh. They just sneak out there.
clcaev wrote 11 hours 5 min ago:
Perhaps more people are using AI as part of an editorial process that
is largely driven by what they wish to convey but where they have
stopped fighting the AI on its preferred style. Itâs supremely
annoying when AI updates your prose with its own formulation despite
plenty of instructions otherwise. Too often AIs mangle meaning which
can be especially worrisome as itâs not easy to catch subtle
word/grammar changes that dramatically shift meaning. Overall though,
defects aside, for me, and only very recently, itâs been more
helpful than not. I think AIs will continue to improve in this regard
and be better editorial partners. For competent writings, it wonât
replace human authorship or expert review.
Specifically, Iâve recently used ChatGPT for legal/administrative
writing where the AI seems to be trained on a large corpus and seems
to know the conventions and vocabulary well; a lawyer who reviewed
the work had important corrections. Before AI, I would have sought
model filings and have had less success at emulating the genre. So
itâs lowered time/cost somewhat but it takes lots of diligence. By
default, current AI outputs seems intelligible but are still really
far off the mark. Iâve found a structured interview is a good way
to start rather than jumping into draft generation.
ardeaver wrote 14 hours 16 min ago:
I also wonder if it's possible that this is just "blog-speak"
The author of this article has what seems like it could be a
relatively thriving consulting business, so he probably writes more
to advertise his services than anything else. That kind of writing
surely lends itself to a particular writing style, which is a
non-insignificant chunk of the kind of writing that LLMs were trained
on.
rldjbpin wrote 15 hours 57 min ago:
the psychosis has gone off the charts! anything that sounds odd to
someone can now be labelled as an LLM text "smell"?
why scoff over someone doing assisted writing? i might age myself but
kids back in the day would try to sound better by using synonym
feature in ms word (or through web thesaurus) for their assignment
essays. this all looks familiar to the same practice, now only made
more accessible.
Capricorn2481 wrote 8 hours 4 min ago:
There's nothing in the comment you're replying to that could be
described as "scoffing." What are you on about?
I feel the opposite, where AI hype is so extreme that merely
someone pointing out an article may have had LLM involvement
prompts a response like this. Someone incredulously painting people
as ivory tower nose thumbers. If anything, it pushes me away from
LLM writing more.
I also don't see how you can compare finding a synonym for a word
to having your entire writing voice determined for you.
maxloh wrote 16 hours 26 min ago:
I don't know about the author's background, but there is now a
generation of non-native programmers who learned to write English by
using LLMs for corrections (yeah including this comment).
The irony is that studies show LLM detectors have a much higher
false-positive rate for non-native speakers [1]. If most of what you
read stems from LLMs, you end up writing like an LLM.
[1]
(HTM) [1]: https://hai.stanford.edu/news/ai-detectors-biased-against-no...
Capricorn2481 wrote 8 hours 40 min ago:
> but there is now a generation of non-native programmers who
learned to write English by using LLMs for corrections (yeah
including this comment)
LLM writing has not been overly abundant for more than a couple
years. I don't know where you got the idea that an entire
generation of people have already learned to write like an LLM.
samat wrote 19 hours 5 min ago:
And many others. I felt it too
And itâs a good contrast with âjust fcking use Goâ article he
linked.
Go article is much more human. I love that and would choose a human
centered language and human centered culture over LLM-centered
everything every time
I guess I am just old
samat wrote 18 hours 51 min ago:
And tables with comparisons! Nobody makes a table by hand if itâs
not packed with value. Tables in this article are not
ventana wrote 23 hours 0 min ago:
While reading the article, I remember feeling that I'm reading an LLM
generated sentence a few times, but in general, this specific article
look like an example of acceptable LLM usage to me. I wouldn't call
it "AI slop".
It is, if I may say that, _genuinely_ hard to use LLM assist and not
make the text look like LLM generated. Even when I write an email in
gmail and it gives its suggestions to make the text better, each one
individually makes perfect sense, but when I click a few of them, the
whole email now looks like AI slop, so I would normally undo the
changes, going back to my imperfect hand-written non-optimized
version.
dillon wrote 1 day ago:
I have to agree here, but I'm not sure why. I don't have any clue
what makes something sound AI generated or not. I got to about here
"Go is clearly working for a lot of people," -- before I became
suspicious that it was AI-assisted (but also maybe I'm wrong and it's
not AI-assisted, I am very bad at telling). It's more about vibes
(ironically) than anything else in particular. If something "sounds"
AI-assisted then I instantly lose interest even if the article itself
is otherwise fine. I wish people were more ok with writing their own
thoughts with how it comes to them.
nemo1618 wrote 1 day ago:
Agreed. In fact, one of the things I now watch for is my mind
starting to "slide off" the text, or finding myself re-reading a
section multiple times. It's like the brain subconsciously
recognizes a lack of substance even if we can't point to a specific
tell.
tkiolp4 wrote 1 day ago:
I think the whole post is AI generated. The author could have given a
draft as input and perhaps edited the output in a few places.
Take this paragraph as example:
> Go got generics in 1.18, and theyâre useful, but the
implementation has constraints (no methods with type parameters, GC
shape stenciling, occasional surprising performance characteristics).
Rust generics monomorphize, each instantiation produces specialized
code with zero runtime cost. Combined with traits, this gives you
real zero-cost abstractions.
Every sentence says something. Every sentence is important and holds
its weight. I would expect that kind of writing from very specialized
books or papers, not from a blog post. Also, it makes the post harder
(and more boring) to read.
lenkite wrote 15 hours 16 min ago:
His stuff about generics in Go is also wrong. He says that Go's
standard library "avoids" them. He forgot that it has
`slices.SortFunc()`. He forgot about Go `Seq`. Maybe because he has
stopped using Go and is no longer that familiar.
pscanf wrote 18 hours 38 min ago:
> Every sentence says something. Every sentence is important and
holds its weight. [...] Also, it makes the post harder (and more
boring) to read.
I actually prefer that style of writing! (When it's not
AI-generated ofc.) And I also try to use it in my technical blog
posts. I usually re-read my drafts asking myself: "Does the reader
actually care about this? Is this sentence adding something or is
it just fluff?"
And actually I feel like AI text usually produces more fluff, or
anyway I notice it more, but I see how it can make the result
"robotic and boring".
bbg2401 wrote 1 day ago:
I've noticed LLM writing over the past year has had an unusually high
tendency to talk about surfaces and, in particular, substrates. I
don't expect LLM generated text to be anything other than rich with
clichés. I simply wish we would all demonstrate a better editorial
hand so we weren't reading the same voice, over and over.
pton_xd wrote 1 day ago:
This is completely off topic now but, "it's worth being precise about
..." is a much stronger AI-ism than the usage of the word genuine.
geenat wrote 1 day ago:
If verbosity is a main stickler, this is coming to golang 1.28 which
will cut it down drastically:
(HTM) [1]: https://github.com/golang/go/issues/12854#issue-110104883
ngrilly wrote 7 hours 16 min ago:
Yes, I'm so happy it has been accepted. It will particularly useful
to pass named parameters to functions.
joaohaas wrote 12 hours 46 min ago:
I know general consensus on this is that it is good, but I hate this.
The fact that both assignments do completely different things (with
the map one doing heap allocs!) is insane. This would've been much
better if it only allowed for anonymous structs.
var A string = "A"
type Foo struct { A string }
var a Foo
var b map[string]string
a = {A: "abc"}
b = {A: "abc"}
nasretdinov wrote 16 hours 16 min ago:
Being able to just return {}, err when returning an empty struct from
a function sounds really exciting and encouraging to use pointers
less, which is really good for nil safety if anything
p2detar wrote 1 day ago:
That actually looks great. Thanks a lot for the link.
arjie wrote 1 day ago:
I do like using Rust quite a bit, but the presence of arbitrary
build-time code in build.rs is very risky until we get better at
implementing dev-time sandboxing.
kayo_20211030 wrote 1 day ago:
If you have a green field, by all means write it in rust. If you have a
brown field, and a functional profitable system, rewrite the parts that
need rewriting in the original language, whatever that is, and carry
on. Make your systems better in small measurable ways, with the
language you know and a team you trust to implement it all. Anything
else is a wasteful religious argument.
Thaxll wrote 1 day ago:
I don't see any reasons to use Rust when your team successfully
shipped and is confortable with C#/Java/Go ect ...
treavorpasan wrote 1 day ago:
If anyone one comes and tells me we need to rewrite in a new
language from any of those modern languages, other than you are
dealing with something cannot wait for GC.
That is a signal that person is lacking purpose in their job or
life.
dbdr wrote 17 hours 0 min ago:
GC pauses are not the only reason. At the very least, raw compute
performance and lower memory usage are also valid reasons in some
contexts.
Thaxll wrote 1 day ago:
"services that your organization relies on, that have high uptime
requirements, that are critical to your business"
Kind of funny when your Rust service runs on Kubernetes.
jabl wrote 15 hours 42 min ago:
Which in turn relies on a stack largely written in, shock and horror,
C, such as the Linux kernel, libc, openssl, nginx, etc. etc.
Even if you believe language X to be the bees knees, are you going to
stop using it until everything below it in the computing stack has
been rewritten in X? Of course not.
amazingamazing wrote 1 day ago:
Rust is great. However in an agentic world go will win. Look no further
than incremental build times. This, combined with high token costs mean
that for a given application it simply will cost more to to write it in
Rust than Go.
This can easily be justified for many usecases, but for your vanilla
crud app, do you really need Rust?
Per the article, you are getting 20-50% better more performance with
Rust. Not worth it unless your team was already fluent in Rust. Now
consider a scenario where your team uses AI exclusively to code, now
you are spending more time and tokens waiting around to consume large
rust builds. As far as I know this is an inherent property of Rust to
have its safety guarantees.
I think Rust makes sense for a lot of cases, but for a small web
service, overkill and unnecessary imho. If someone ported their crud
app from Go to Rust I would question their priorities.
Again I am speaking more in terms of software engineering economics
than anything else. Yes, I know in a perfect world Rust binaries are
smaller, performance is better and code more âcorrectâ, but the
world is hardly perfect. People have to push code quickly, iterate
quickly. Teams have churn, Rust, frankly is alien for many, etc.
fHr wrote 11 hours 29 min ago:
lol no
the__alchemist wrote 1 day ago:
> However in an agentic world go will win
This is Silicon Valley fantasy.
nicoburns wrote 1 day ago:
> As far as I know this is an inherent property of Rust to have its
safety guarantees.
From what I've seen, Rust's strictness is actually a huge win for
LLMs, as they get much better feedback on what's wrong with the code.
Things like null checking that would be a runtime error in Go are
implied by the types / evident in the syntax in Rust.
crabmusket wrote 1 day ago:
> spending more time and tokens waiting around
Can you clarify how you're spending tokens on waiting? My
understanding is that the LLM isn't actually necessarily doing
anything while a build runs. The whole process end to end may take
longer for sure (ignoring things like the compiler catching more
errors, that's really hard to factor in) but how does that correlate
to more tokens?
amazingamazing wrote 1 day ago:
> The whole process end to end may take longer for sure (ignoring
things like the compiler catching more errors, that's really hard
to factor in) but how does that correlate to more tokens?
This. rust emits more information both in its output and the syntax
itself more complicated requires more tokens.
gitaarik wrote 20 hours 48 min ago:
Your agent doesn't know how to use grep?
kajman wrote 1 day ago:
The cost of verbose compiler output surely cannot compare to the
cost of shipping bugs that would've been caught at build time.
amazingamazing wrote 1 day ago:
Indeed, but is it the case that all bugs you have are those in
which would be caught by the compiler? Itâs not like rust
code inherently is bug free.
kajman wrote 1 day ago:
Of course, there's plenty of bugs in Rust code still. The
fact that safe Rust should be able to statically guarantee
entire classes of bugs like data races are impossible is a
huge deal, though. We're totally free to have different
values when it comes to what matters, but compile time and a
verbose toolchain are not high costs for that, to me. I
personally would first consider other things like the
cognitive overhead of learning to work with the borrow
checker.
natsucks wrote 1 day ago:
Because the agentic world involves the generation of so much code
that gets harder to review, I would think the compile-time guarantees
of Rust would make it a better option.
amazingamazing wrote 1 day ago:
This is true if the token budget and time are not taken into
account. In practice though, waiting minutes instead of seconds per
build multiplied by prompt and again by change adds up very fast.
nicoburns wrote 1 day ago:
Incremental Rust builds are almost never minutes (on recentish
hardware)
A quick measurement on my web browser project with almost 600
dependencies:
- A clean "cargo check" was 31s
- An incremental "cargo check" with a meaningful change was 1.5s
Building is a little slower:
- A clean "cargo build" was 56.01s
- An incremental "cargo build" was 4s
But I find that LLMs are mostly calling "check" on Rust code.
---
That's on an Apple M1 Pro. The latest M4/M5 machines as ~twice as
fast.
amazingamazing wrote 1 day ago:
I mean i wouldnt call a 100% a little slower wrt check vs
build. In any case, the more you change the longer the
incremental check or build will take.
J_Shelby_J wrote 1 day ago:
1.5s for a massive project, on a laptop,like the OP said is
still barely anything in the context of agentic coding.
Itâs less than a single percentage point of the total time
in the loop, even if the agent has to compile multiple times.
This is cope.
I do give you that rust is more verbose and thus more token
heavy. However that verbosity is meaningful and the LLM would
have to spend tokens thinking about the code to understand
less verbose languages. So Iâd consider that a wash - in
some cases it hurts and in some it helps.
amazingamazing wrote 1 day ago:
We donât know how massive the project is, but in any case
building and immediately building again of course will be
fast. How fast is it if all files have a single line
changed, for example refactoring a log message?
Not to mention we haven't even gotten to discussing tests.
nicoburns wrote 1 day ago:
> in any case building and immediately building again of
course will be fast
FWIW, the compile time test above was done comparing
consecutive commits. Which in this case happened to have
~3-4 lines changed.
nicoburns wrote 1 day ago:
Sure, but when we're talking single-digit seconds it feels
not that significant regardless?
amazingamazing wrote 1 day ago:
My point is that it isn't necessarily that fast. It is
relative to the amount of changes and where they were made.
For a fair comparison you would also have to present the
worst case incremental build time which approaches the full
build time (this goes for Go too), which per your own
example is nearly a minute for rust.
nicoburns wrote 1 day ago:
> For a fair comparison you would also have to present
the worst case incremental build time which approaches
the full build time (this goes for Go too)
The worst case that would approach a non-incremental
build time would be if you were editing a leaf crate. But
in almost all cases the leaf crates are 3rd-party
dependencies that you would never edit directly.
A real-world worst case is probably more like ~10-20% of
an non-incremental builds.
natsucks wrote 1 day ago:
When everyone is armed with Mythos-like hacking ability, it's
hard for me to imagine people wouldn't make the tradeoff of
security over price.
johnfn wrote 1 day ago:
Can you explain a bit about why token costs would favor Go and not
Rust?
amazingamazing wrote 1 day ago:
Go is more verbose, but Rust have more complex syntax which in
practice require more tokens.
The big thing though is because builds are slower, you will end up
waiting longer as tests are modified, rebuilt and run. This
difference piles up fast.
gitaarik wrote 20 hours 49 min ago:
Waiting longer for tests / builds doesn't have effect on token
usage..
Rust's compile time is longer because the compiler does much
more. And therefore the binaries are often smaller, start and run
faster than Go
OtomotO wrote 1 day ago:
It's a good thing then, that the AI hype is dying outside of
ycombinator, the silicon valley and the US
fHr wrote 11 hours 28 min ago:
Surely
amarant wrote 1 day ago:
As someone with a background of consulting in the Stockholm based
gaming industry for the last decade+, I have to respectfully
disagree. Nearly everyone I know is very much on the hype train.
And for good reason too! The capabilities are undeniable!
bigstrat2003 wrote 20 hours 15 min ago:
The capabilities are very much deniable. They do not exist. Using
LLMs to write code is either going to make you slower (as you
have to review all that code), or make your software suck
(because they write bad code and you're choosing to not review
it). There's no actual win to be had here.
OtomotO wrote 1 day ago:
As is the hype.
You know, shovels are useful, they are just more useful to the
shovel manufacturer than the gold diggers.
But in the end it's a cool tool that made it way easier to dig
holes and tend to your garden!
gitaarik wrote 20 hours 55 min ago:
So you're not using a shovel to maintain your garden?!
OtomotO wrote 18 hours 45 min ago:
I am, but I am no part of any shovel cult.
amarant wrote 1 day ago:
Oh yeah, definitely. There has indeed been a lot of hype
overestimating the capabilities. People thinking you can
one-shot big complex applications with a few paragraphs of
descriptions for example. There has also been a lot of
anti-hype, or whatever you call it when people seem to believe
LLMs don't provide any value for software Dev, basically
writing all capabilities off as pure hype.
The truth of course is somewhere in the middle.
It's difficult to tell what people mean when they say hype
sometimes.
Animats wrote 1 day ago:
I could see migrating from C or C++ or Python to Rust, for various
reasons, but for web back-end work Go is a good match. I write almost
entirely in Rust, but the last time I had to do something web server
side in Rust, I now wish I'd used Go.
The OP points out the wordyness of Go's error syntax. That's a good
point. Rust started with the same problem, and added the "?" syntax,
which just does a return with an error value on errors. Most Go error
handling is exactly that, written out. Rust lacks a uniform error type.
Rust has three main error systems (io::Error, thiserror, and anyhow),
which is a pain when you have to pass them upward through a chain of
calls.
(There are a number of things which tend to be left out of new
languages and are a pain to retrofit, because there will be nearly
identical but incompatible versions. Constant types. Boolean types.
Error types. Multidimensional array types. Vector and matrix types of
size 2, 3, and 4 with their usual operations. If those are not
standardized early, programs will spend much time fussing with multiple
representations of the same thing. Except for error handling, these
issues do not affect web dev much, but they are a huge pain for
numerical work, graphics, and modeling, where standard operations are
applied to arrays of numbers.)
Go has two main advantages for web services. First, goroutines, as the
OP points out.
Second, libraries, which the OP doesn't mention much. Go has libraries
for most of the things a web service might need, and they are the ones
Google uses internally. So they've survived in very heavily used
environments. Even the obscure cases are heavily used. This is not true
of Rust's crates, which are less mature and often don't have formal QA
support.
waterTanuki wrote 1 hour 31 min ago:
> Rust has three main error systems (io::Error, thiserror, and
anyhow), which is a pain when you have to pass them upward through a
chain of calls.
nit: Rust has three main Error implementations not systems.
std::error::Error is a trait because it's left up to the user to
provide project-specific error types, even if those types are
anyhow::Errors. The system follows any implementation you use: ?
syntax, .unwrap(), .expect(), handling, formatting, etc.
I've never had a problem using anyhow to pass errors up the call
stack in any project I've used it in. What exactly is a pain?
malcolmgreaves wrote 9 hours 16 min ago:
> Rust lacks a uniform error type.
Not quite true. The unifying error trait is std::error::Error.
> pain when you have to pass them upward through a chain of calls
Kind of? You just make an enum with the various variants that need to
be passed through and use the #[from] macro to generate the
conversion code automatically.
Itâs more characters than eg. A union type in Python or TypeScript,
but itâs not much more.
Plus, it makes you think about your error design, which is important!
throwaway2037 wrote 10 hours 7 min ago:
What is "formal QA support"?
apatheticonion wrote 12 hours 9 min ago:
I use Rust for web services all the time. It's a dream compared to Go
(which I wrote professionally for years).
At this point, I can't imagine a scenario not to use Rust for writing
a web API.
christophilus wrote 13 hours 23 min ago:
I just hate how many dependencies you have to pull in for a typical
Rust project vs Go. As far as Go being an ugly language, there are
some interesting wrappers that put lipstick on that pig such as [1]
But personally, I donât mind Go at all. Iâve even begun to prefer
it for some things. That may be Stockholm syndrome, though.
(HTM) [1]: https://lisette.run/
guilhas wrote 8 hours 8 min ago:
Rust is easily one of the worst languages to look at
phplovesong wrote 9 hours 57 min ago:
Been playing with Lisette for a few weeks, so far im really liking
it. Think is has some potential.
DeathArrow wrote 14 hours 25 min ago:
>I could see migrating from C or C++ or Python to Rust, for various
reasons, but for web back-end work Go is a good match. I write almost
entirely in Rust, but the last time I had to do something web server
side in Rust, I now wish I'd used Go.
Now there is a cult of rewriting everything in Rust. System level
software? Yes. Web? I prefer not to.
vorticalbox wrote 16 hours 5 min ago:
I don't fully get the argument about errors.
in rust say a function returns Result so either the we get a result
all an error how is that different from (int, err) in go?
do you not still need to handle the error?
in go you just return the error up to whatever the top caller is.
moltonel wrote 15 hours 10 min ago:
Go funcs can return both a value and an error, or neither, it's a
common gotcha. Having to check the behavior each time is no fun.
Missing error handling is checked at compile-time in Rust
(lint-time in Go), and can be enabled for any struct or function (
[1] ), not just `Result`.
Returning an error to the caller in Rust can be done with a single
character.
(HTM) [1]: https://doc.rust-lang.org/reference/attributes/diagnostics...
ssfak wrote 15 hours 53 min ago:
In Go you can ignore the error value though, and use directly the
returned value (`int` in your example). In Rust you cannot do that,
you need to unwrap the Result or use the `?`
ben-schaaf wrote 15 hours 5 min ago:
If the returned value is still valid despite an error, then the
function would return (u32, Option), perfectly valid rust. If the
value is meaningless in case of an error then using it is
incorrect code; you wouldn't want to do that in either language
and rust makes that assumption explicit with unwrap. If you want
a default value in case of error just use unwrap_or_default.
Ygg2 wrote 17 hours 3 min ago:
Go also has one glaring disadvantage. GC. Assuming you're in the
cloud.
It's easy to write code that trivially eats memory. Plus any
resources spent on it, are resources not spent on other cloud
provider things.
swiftcoder wrote 18 hours 38 min ago:
> Rust has three main error systems (io::Error, thiserror, and
anyhow), which is a pain when you have to pass them upward through a
chain of calls
anyhow explicitly isn't designed for what you are trying to do here.
It's designed to be the last link in the chain (and complementary to
thiserror, not in competition). If you are using anyhow any deeper
than your top-level binary crate, you are likely to be in for an
unpleasant time.
mswphd wrote 7 hours 18 min ago:
also thiserror isn't incompatible with io::Error? all thiserror
does is do code generation for "typical" enum errors. The errors it
generates are normal rust code though, and the fact that they're
generated by thiserror shouldn't really matter?
ziml77 wrote 1 hour 41 min ago:
I don't get where the idea comes from that the popular error
crates make error handling complicated in Rust. Because you're
right, all thiserror is doing is giving you a shorter syntax for
writing error enums. You could write the exact same things out by
hand if you wanted to, and from the library user's side nothing
would change.
As for anyhow, if a library ever exposes that, then that's just
the author being lazy and not doing errors correctly. It's the
equivalent of doing throw Exception("error!") in C#.
IshKebab wrote 16 hours 44 min ago:
He was talking about the chain of function calls not crates. You
still have that in your top level crate.
wtetzner wrote 4 hours 10 min ago:
Except anyhow is compatible in that direction. io::Error and
thiserror types will automatically convert to anyhow errors.
pjmlp wrote 19 hours 55 min ago:
For me going from JVM and CLR ecosystem of programming languages into
Go for backend development is a downgrade.
The language design makes sense in the context of Oberon (1987), and
Limbo (1995).
Now when there are so many options finally building on top of
Standard ML, and Lisp heritage, having to settle with Go feels like a
downgrade.
I code since 1986, if I wanted if boilerplate error handling, or
having cost as the only mechanism to declare constant values, there
have been plenty of options.
mountainriver wrote 20 hours 42 min ago:
I love Go and used to write it heavily for anything non LLM based.
Now that we have agentic coding I just write everything in Rust and
couldnât be happier. The struggle with rust was writing it, go was
made so it was easy to write for mid level engineers. Now that we
have agentic coding Iâm not sure Goâs value prop holds up anymore
My rust services have been nothing short of amazing from a
performance and reliability perspective
ljm wrote 10 hours 53 min ago:
Go is really easy to read and write, even if Go's philosophy means
that some of that feels clunky because it's less featureful than
other languages. It makes up for it with a comprehensive stlib that
makes it trivial to build services with few to no third party
dependencies.
I don't think the value prop has changed at all there. One day the
AI gravy train will stop and people who used AI to punch above
their weight will no longer be able to debug the stuff they built
unless they put in the hard work of learning the language.
Nothing to worry about with Go in that respect because of how much
it's been designed to be simple. Even the annoying err/nil checks
you need to do all the time are in service of that simplicity. It
gets old fast but it leaves nothing to the imagination.
DeathArrow wrote 11 hours 11 min ago:
>Now that we have agentic coding I just write everything in Rust
and couldnât be happier. The struggle with rust was writing it,
go was made so it was easy to write for mid level engineers. Now
that we have agentic coding Iâm not sure Goâs value prop holds
up anymore
Agents seem to have a better time with Go. Humans need to review
the agents outputs and in general they have an easier time to do it
with Go.
hesus_ruiz wrote 12 hours 29 min ago:
The value prop of Go in not on writing, but in reading and
comprehension by people different from the autor(s).
For systems expected to last some years, this translates in reduced
total cost of maintenance over the life of the system (in my
experience typically 80% or more of the total cost) and
facilitating traspassing maintenance to diferent people than the
authors.
In use cases where Go has "good enough" performance, for backend
systems with business logic and small amount of "bare metal"
programming, I recommend Go to teams instead of Rust. When extreme
performance and reduced memory footprint is more important than the
other properties, Rust is better than Go.
lelanthran wrote 13 hours 31 min ago:
> The struggle with rust was writing it, go was made so it was easy
to write for mid level engineers.
In practice, anything that makes it easier for humans to program
also makes it easier for LLMs to program.
You also wont typically learn that the LLM is close to the limits
of understanding your code base until after it has blown past it's
own capabilities, leaving you with a mountain of code that you are
not skilled enough to fix.
Java, C# are good choices as they tend to enforce a certain
structure. Go, good because it's very readable even if you dont
know the language.
C++, Rust are poor choices unless you are already a senior in that
language.
ruicraveiro wrote 16 hours 26 min ago:
Go was never about being easy to write (thought it is), but it was
always about being easy to read and it is, by far, the easiest
language to read that I've ever used (and throughout the decades, I
went through Basic, Pascal, C, Java, JavaScript, C#, TypeScript,
Ruby and Python). That becomes even more important if you are not
writing the code yourself...
pas wrote 14 hours 39 min ago:
it's too verbose, yet not explicit.
you need to know the conventions to spot what's not there (did
you miss the error handling? or the magic comment for the
whatever codegen serializer? c'est la vie!)
edit: just a few comments below an even better description of
what I'm trying to convey:
(HTM) [1]: https://news.ycombinator.com/item?id=48264853
cdelsolar wrote 10 hours 6 min ago:
Disagree, if you miss the error handling the code wonât
compile (unless you return _, which should be easy to spot)
The magic comment stuff is very much âdo it onceâ and
itâs done (for example if using go generate).
x-yl wrote 16 hours 56 min ago:
In my experience LLMs (I speak mainly of Claude Code & Cursor)
write very poor quality Rust.
They treat it like it's JavaScript, falling back to using
String/&str needlessly instead of making new types. They do ugly
`static Mutex> means they will spend minutes 'thinking' about basic
lifetime issues until I step in and add the missing `move` in a
closure.
chucky_z wrote 5 hours 30 min ago:
Weâve developed incredibly strict and comprehensive clippy
rules and found that to drastically improve the quality of the
code as the LLM now should pass all clippy checks. You can add a
clippy skill as well to attempt to turn âshouldâ into
âmust.â
gritzko wrote 7 hours 43 min ago:
That is interesting. I make LLMs write C with the general hope
that a simpler language they can manage well. That is not
entirely true, though. They reason about C fluently indeed. The
problem is, Claude pumps lots of bad C into the codebase if left
unattended for 5 min.
So, I need some clean-up passes afterwards to get to some
acceptable quality level (both by LLMs and my own eyes). At which
point, Claude sees the problem clearly, for some mysterious
reason.
Also, I use a C dialect heavly influenced by Go (slices,
generics, no smart tricks, virtually no malloc).
satvikpendem wrote 5 hours 23 min ago:
> general hope that a simpler language they can manage well
It's the opposite; a language with lots of guardrails allows
the AI to write better code especially as it is able to use the
compiler and linter to guide it through the process. It's why
OpenAI for example was able to disprove some recent theorem
recently, due to the LLM converting its thoughts into a formal
language theorem prover to then check its work.
apatheticonion wrote 12 hours 7 min ago:
You gotta know how to write Rust (and general software arch)
first. LLMs + Rust have been great for me.
"Write an SQL Repository with this interface"
Sweet - no need for SQLc or an ORM
small_model wrote 15 hours 21 min ago:
Maybe true 6 months ago, but now it's better than any Rust Dev,
as long as you guide it and not just let it rip on a full
service/app unsupervised.
runtime_terror wrote 7 hours 49 min ago:
It's better than any Rust dev... as long as you guide it
What?
jorvi wrote 16 hours 4 min ago:
LLMs generally write poor quality anything. It'll [usually] work,
but it'll need massive refactoring to get in a maintainable and
efficient state.
ryan_n wrote 1 hour 52 min ago:
this was true a year ago but not so much anymore. You still
have to supervise the agents, but they can write maintainable
code if you keep an eye on it.
sgt wrote 6 hours 1 min ago:
I've actually found Opus 4.7 to write decent Django / Python
code.
adeptima wrote 16 hours 48 min ago:
same experience. any good claude skills to ease the pain?
bottlepalm wrote 20 hours 34 min ago:
For me the bottleneck now is reading/reviewing code, not writing
code. As you said, AI makes it way easier to write, but do you not
review the code? And isn't a verbose, cryptic language with lots of
nitty gritty memory management not harder to read/review?
I'm not sold on Rust being a great language to use with AI unless
the reason to use it is a lot more than just Rust being
fashionable.
moltonel wrote 15 hours 54 min ago:
I find Go harder to review than Rust.
The verbose error handling diluting the interesting parts is one
thing, but the main issue is the weak type system. Having to read
the callee's code to check if it deviates from `res xor err`, or
if it mutates its arguments. Figuring out which interface that
`func (o *Obj) ()` is implementing, if any. Dealing with
documentation that is a wall of 100 disappointing oneliners all
repeating the function name.
Rust is information-dense and takes longer to master, but it's
not inherently cryptic, there's a finite amount of things to
know. Memory management sometimes take a bit of thought to write,
but it's straightforward to review, you can trust it's correct if
it compiles, you just keep an eye out for optimizations.
Yokohiii wrote 13 hours 22 min ago:
I don't see the difference in exploring an dense custom type
system versus a flatter one. Both force you to look things up
when you don't know about them.
In my opinion these problems originate in architectural style.
Much of the open source written today is designed to impress
the audience instead of focusing on the problem.
fauigerzigerk wrote 17 hours 14 min ago:
IMO neither Go nor Rust are great for reading/reviewing code.
Go is too verbose and the type system isn't expressive enough.
Rust code is littered with little memory management details and
it requires tons of third party libraries.
I think coding agents will eventually be able to get the low
level details right on their own. Reviewers should be able to
focus on architecture, design and logic mistakes.
I also think we need a high level formal specification language
to tell agents what we expect them to do.
vishnugupta wrote 16 hours 50 min ago:
> I also think we need a high level formal specification
language to tell agents what we expect them to do.
Letâs make that specification Turing complete while at it.
Jokes aside, IMO it will be a good natural progression. Specify
the problem statement in LLM specification, generate the code
in Go/Rust whatever is the language of your choice and review
the generated code to make sure it adheres to the
architecture/design principles that you have set.
fauigerzigerk wrote 16 hours 19 min ago:
It absolutely should be Turing complete. I want to formally
specify some constraints/invariants that any generated code
has to meet, like very high level test cases.
It doesn't have to be a new language. I'm sure some existing
language can be used to create a DSL that serves this
purpose.
It can obviously never be complete. Some parts of the spec
will always have to be natural language if we want to make
the best use of LLMs.
WJW wrote 14 hours 46 min ago:
Maybe we can have Large Logic Models instead, and they
could have formalized keywords with rigid meanings? Like
IF, WHILE and FOREACH maybe. Or even ASYNC if you want to
be modern about it.
fauigerzigerk wrote 14 hours 27 min ago:
I do think that AI models should get better at logic. But
if code generators are supposed to be tools, we have to
tell them what to do. I'm not sure what combination of
languages is best for that purpose.
WJW wrote 13 hours 40 min ago:
It would be so much easier if we could precisely
specify what we wanted, without all the double
meanings, slang and general ambiguity that comes from
using a natural language.
If only there was an entire class of well-studied
languages which don't have any such ambiguity. They'd
be perfect for programming LLMs! We could call them
"programming languages" perhaps.
fauigerzigerk wrote 12 hours 25 min ago:
But what we want is a lot of ambiguity on the
implementation side and some targeted ambiguity on
the specification side where appropriate.
sheept wrote 18 hours 26 min ago:
In my experience, Rust is only mildly unpleasant to review, if
only because the GitHub PR review interface is not an IDE. It can
be hard to tell why .as_ref()s and whatnot had to be used without
being able to hover over a variable to see its type. This is
probably because of the language's preference for type inference,
though personally I would rather that than having to skim over
explicit types.
Compared to Rust, Go as a language requires a lot more effort to
review. You have to be on the lookout for basic gotchas like not
checking if a pointer is nil, placing `defer` in the wrong place,
using a result when err isn't nil, and so on. Plus, diffs are
messier because unused variables are a compilation error, and _,
err := can change into _, err = solely due to new lines above.
jon_richards wrote 15 hours 20 min ago:
And := not being = can really matter for variable shadowing.
Absolutely insane syntax choice in a language where everything
returns 2 values. At least do var:, err: =
solumunus wrote 18 hours 29 min ago:
The benefit is if you lean heavily on types then successful
compilation is a massive indicator in the feedback loop. Using
stop hooks to ensure successful compilation after every iteration
is a game changer. Go also has compilation of course but because
the type system is so much more robust in Rust the compilation
guarantees so much more about the behaviour of your program. You
end up just code reviewing the shape and flow of data.
bottlepalm wrote 17 hours 25 min ago:
Code compiling is really the lowest bar of code validation, and
doesn't say much of anything of the code running correctly. AI
will pump out the most convoluted, over engineered, and at the
same time sloppy code if you let it - and it will all compile
fine.
rowanG077 wrote 5 hours 0 min ago:
It is of course the lowest bar. The main point is that the
lowest bar in Rust is already a really a high bar compared to
go lowest bar.
hombre_fatal wrote 5 hours 35 min ago:
Well, a good type system like Rust's lets you make impossible
states impossible to enter/represent by the system.
Writing code so that impossible states are impossible is one
of the hardest parts of software, so a good type system means
that the code compiling means that the software is validated
to be unable to represent certain states which is a very high
bar of validation.
I suppose in your mind you were thinking of more trivial
errors like typos, accessing variables that aren't available
in scope, and such.
This is the main reason I use Rust over Go these days. The
simplicity of Go was great for when I had to hold everything
in my head and write everything myself. Rust makes more sense
to me in the LLM era where I can offload more
modeling/assumptions/invariants to the type system without
having to be a Rust veteran.
The pinned invariants in my plan/spec become first-class
invariants in the type system. It's great.
imtringued wrote 11 hours 57 min ago:
It's the lowest bar and that's precisely why you want it to
be as high as possible.
For me, one of the bigger complaints is that Rust isn't
pedantic enough. Panic free Rust isn't taken seriously enough
as an idea.
I wish it would catch even more things, since it works so
well.
wongarsu wrote 14 hours 50 min ago:
Overengineering and convoluted code stand out when reading.
The hard part are the subtle errors. And the Rust compiler
helps you out a lot more here
moltonel wrote 15 hours 37 min ago:
Yes, but all else being equal it is a higher bar in Rust than
in Go. There are fewer things left for the human to check
after a clean build+lint in Rust than in Go. The issue of
over-engineered AI output is orthogonal to that.
Certhas wrote 18 hours 50 min ago:
It's the same logic for human and for AI code: In Rust the
compiler catches many bugs so you don't have to.
If the LLM gives you safe code you know there are entire classes
of things you don't have to review for.
That said, I agree with you. My experience is that LLMs are great
if you are highly competent in the domain in which you let them
work. And it's probably easier to be competent in Go than in
Rust.
cdud3 wrote 15 hours 36 min ago:
I found it's the opposite. Thanks to LLM's whole classes of
problems otherwise solved by using Rust are gone. It's now more
important that the generated code is easy to read.
afdbcreid wrote 4 hours 29 min ago:
Relative to Go? I'm pretty sure your Go code won't be faster
if you used LLMs. If you need that, Rust is still preferred.
Relative to C/C++? That'll be very interesting. Do you have
some evidence that LLMs can create memory-safe code in C/C++?
It'll be truly amazing if true, but given that they
apparently struggle to create/maintain big codebases in
already-memory-safe languages I seriously doubt it.
bottlepalm wrote 17 hours 19 min ago:
Safe? No compiler is going to catch badly designed code, or
intentionally backdoored code. Memory leaks as well. Compilers
are the ground floor of validation and the least of your
problems with AI generated code.
Certhas wrote 11 hours 38 min ago:
Yes? Does that contradict anything I said?
robocat wrote 16 hours 38 min ago:
A mythical compiler might catch unsafe code
lofties wrote 19 hours 32 min ago:
Reading the code? Who has the time.
Aah, I am sure the chickens of vibe coded origin, will never come
to roost.
kaashif wrote 18 hours 15 min ago:
Time isn't the constraint here, but ability. Someone
complaining about how hard Rust is to write is probably not
capable of reviewing Rust code very well.
The usual reaction or opinion from e.g. good C++ programmers
switching to Rust is that the added guardrails and expressivity
are great and make things easier.
pas wrote 14 hours 36 min ago:
I find it easier to review Rust (but Go too) than to write
it.
Foobar8568 wrote 20 hours 23 min ago:
The build time and space for rust is awful for fast iteration e.g
change a thing, verify.
tertasrfg wrote 22 hours 54 min ago:
The funny thing is: All Rust source code looks like an assembly
syntax error.
winrid wrote 22 hours 47 min ago:
If you spend an hour skimming the Rust Book it's not really that
bad
skydhash wrote 21 hours 16 min ago:
It's not that bad, but when compared to C or Go, it's not
something that I would like to type by hand. At least Java has
IDEs which reduce the amount of verbosity you need to type. I
know you get safety, but the verbosity and cargo is is a con in
my opinion.
winrid wrote 7 hours 23 min ago:
Rust has autocomplete even in Sublime Text with an LSP... not
quite as good as with Java, but I don't write either by hand
much anymore.
atombender wrote 1 day ago:
For backend web dev, there are advantages. I really like Axum's use
of typing:
pub async fn dataset_stats_handler(
Path(dataset_id): Path,
Query(verbose): Query,
) -> impl IntoResponse {
...
}
With a route like:
.route("/datasets/{dataset_id}/stats",
get(dataset_stats_handler))
â¦the "dataset_id" path variable is parsed straight into the
dataset_id arg, and a query string "verbose" is parsed into a
boolean. Super convenient compared to Go, and you type validation
along with it.
Many other things to like: The absence of context.Context, the fact
that handlers can just return the response data, etc.
What I don't like: Async.
whstl wrote 11 hours 42 min ago:
A project I work at uses a similar pattern (similar from what I can
see):
func Login(req LoginRequest, cookies Cookies, db *sql.DB)
(LoginResponse, error) {
...
}
router.HandleFunc("POST /signup", fw.Wrap(Login))
It's just a wrapper.
It also serializes/deserializes responses and handles both JSON and
templates.
db is just a singleton-lifetime dependency, we often also have ctx,
http.Request, http.Response, Cookie, which are request-time
lifetimes.
I thought about open-sourcing it but most Golang developers seem to
hate it with a passion, so I just gave up, haha.
winrid wrote 22 hours 46 min ago:
You can not use async right? Maybe not with axum but I imagine
there are fully blocking frameworks for rust.
xyzzy_plugh wrote 1 day ago:
The Go standard library has learned to interpret path variables as
well:
(HTM) [1]: https://go.dev/blog/routing-enhancements
zimpenfish wrote 16 hours 7 min ago:
To be fair, it's not -quite- as useful - `req.PathValue` only
returns `string` and you have to do the conversion to other types
yourself which could lead to a faffy mess of code.
ricardobeat wrote 1 day ago:
go is slightly more verbose (surprise) but you can achieve the same
thing using struct binding in gin:
type DatasetStatsQuery struct {
Verbose bool `form:"verbose"`
}
func DatasetStatsHandler(c *gin.Context) {
datasetID := c.Param("dataset_id")
var query DatasetStatsQuery
if err := c.ShouldBindQuery(&query); err != nil {
c.JSON(http.StatusBadRequest, gin.H{"error":
err.Error()})
return
}
// query.Verbose == bool
}}
This is actually a great example - what happens in that Rust
version when the input parsing fails? Go makes it explicit.
sheept wrote 21 hours 41 min ago:
I'm not sure if that's a great example. What kind of errors could
ShouldBindQuery return?
I would assume Axum returns a bad request error for you when
query parsing fails, but if you do want more control over how the
error is handled, you can change the parameter type to Result,
QueryRejection>, and the type system itself documents precisely
what errors you can match against.[0]
[0]:
(HTM) [1]: https://docs.rs/axum/latest/axum/extract/rejection/enum....
LoganDark wrote 1 day ago:
thiserror and anyhow are just std::error with extra steps. Note that
io::error is just a specific std::error.
The entire point in Rust is that you wrap Error impls with other
Error impls, or translate one impl into another using a match. I've
found this is far more flexible and verifiable than most other
languages, because if you craft your error types with enough rigor,
you can basically have a complete semantic backtrace without the
overhead of a real backtrace.
I use thiserror a lot to help with my impls. Notably, all it does is
impl Display and Error. It's not a specific other paradigm because it
basically compiles out, it's just a macro.
Anyhow is perhaps the closest one to another paradigm because it
allows you to discard typed information in favor of just the string
messages, but it still integrates well with Errors (and is one).
kelnos wrote 20 hours 11 min ago:
thiserror and anyhow are std::error::Error with fewer steps.
LoganDark wrote 18 hours 8 min ago:
They're external crates that either generate Error
implementations (thiserror) or act as dynamic wrappers
implementing Error (anyhow), so they're more than a simple
hand-written implementation. But the developer experience of
pulling thiserror or anyhow off the shelf can certainly be more
convenient than the hand-written implementation, sure.
innocentoldguy wrote 1 day ago:
I find Elixir's memory and threading models much more compelling than
Go's for web services. There are many great libraries for Elixir as
well, but if you need something else, Elixir makes rolling your own
libraries very easy. I'd recommend giving Elixir a try, if you
haven't already.
stock_toaster wrote 1 day ago:
Or gleam if you donât fancy elixir.
mikeocool wrote 1 day ago:
I was a big fan of go for a while. Though now that I have programmed
more swift and rust recently, having a compiler that doesnât
protect against null pointer deferences or provide concurrency safety
guarantees feels a little prehistoric.
Though go certainly did a much better job than rust on the standard
library front.
boccko wrote 1 day ago:
Standard library is something you have to maintain for all
eternity, with identical API. It had been argued that some
concurrency primitives like channels would have been better outside
of std (for rust, to be clear). Once dependency management is
solved, a small std is beneficial.
mook wrote 21 hours 15 min ago:
Doesn't Rust already have that solved via editions? If anything,
that's the language that's especially well positioned here.
dwattttt wrote 16 hours 3 min ago:
I believe the stdlib can't be versioned like that: there's only
one stdlib linked into a final artifact, you can't have two
versions with differing APIs in there.
estebank wrote 10 hours 2 min ago:
There's work on edition aware name resolution so that a type
with the "nice path" can change over an edition while still
accessible through a longer path, but 1) it's not implemented
yet, 2) it hasn't been used yet (see 1), 3) if it is ever
used it should be done very sparingly (because of the
bafflement that can occur if someone follows older docs in
the new edition, implementation will come with efforts to
mitigate these problems).
ok_dad wrote 1 day ago:
I use go because of the large and useful stdlib. I rarely have to
reach for an external library, and even then I only consider
libraries that are very popular. If a library isnât available,
Iâll just write my own, using the stdlib. I recently used the
awesome crypto library to implement an envelope encryption
system, I didnât need anything outside of the stdlib or
Googleâs x library (x is effectively the experimental stdlib).
Having too much external code, like npm or rust crates, seems
like a nightmare for me.
j1elo wrote 1 day ago:
> you have to maintain for all eternity, with identical API
People always tout this as a huge reason for not wanting a too
big std in Rust (or "too useful" either), but IMHO that's just
talking about reaching theoretical optimals, while leaving the
community for years without good guidance via providing a
opinionated practical and pragmatic way of doing things. Which I
find to be a very unhelpful stance for a tool such as a
programming language.
If a design of some std package didn't pass the test of time, and
a new iteration would be beneficial, the language can leave its
original API version right there, and evolve with a v2, with an
improved and better thought out API after learning from the
mistakes of v1.
Prime example: "hey we found that math/rand had some flaws, so
here is math/rand/v2". A practical solution, and zero dramas as a
result of having rand be part of std.
troad wrote 21 hours 2 min ago:
Perhaps it would help if stdlibs were be versioned, with the
chosen version declared in the project file. For existing
languages, a lack of version would simply indicate the original
stdlib, meaning nothing should break.
I definitely don't think stdlibs should be changed often, but
it seems fairly damaging to a language when things may be added
to a stdlib but never removed, no matter how broken or
misconceived (see C++).
Rust is a great language, but the poor stdlib + overreliance on
crates + explosion of unvetted transient dependencies makes it
a hard sell for a lot of projects.
fpoling wrote 1 day ago:
For me the main advantage of Go over Rust is compilation speed. Then
compared with Go Rust still rely on many C and C++ libraries making
it problematic to cross-compile or generate reproducible builds or
static binaries.
The minus side of Go is too simplistic GC. When latency spikes hit,
there are little options to address them besides painful rewrite.
p2detar wrote 16 hours 42 min ago:
Go has the Green Tea GC since 1.25. Itâs no longer simplistic and
quite well engineered. The AVX-512 support was especially
interesting to me.
(HTM) [1]: https://go.dev/blog/greenteagc
Animats wrote 17 hours 26 min ago:
> For me the main advantage of Go over Rust is compilation speed.
Interestingly, Rust has quite good failed compilation speed. That's
almost good enough. The usual Rust experience is that it's hard to
get things to compile, and then they work the first time.
dwattttt wrote 16 hours 21 min ago:
I've never been bothered by long compilation times, it gives me
time to think about what the code should actually do.
To other people's usage patterns though, I imagine the group of
people who don't do much with the type system rely more on
running a built binary to see if it worked, which means they'll
pay the full compile/link time cost more often.
physicsguy wrote 17 hours 47 min ago:
> Rust still rely on many C and C++ libraries
Yes but Rust has a lot more availability of libraries to do stuff
as a result. Want to do anything ML or scientific? You at least
have a route in Rust where you donât with Go.
fpoling wrote 15 hours 56 min ago:
With Go basic stuff like url parsing or HTTPS support is written
in Go and comes with the standard library. With Rust too many
necessary things are just wrappers around C and C++ making
cross-compilation and reproducible builds much harder to archive.
As for availability if CGO is ok, then calling C or C++ code from
Go is not that hard. Also, there is always an option to just
start C++ process if extra data copies are OK.
afdbcreid wrote 4 hours 25 min ago:
Can you point out something that has a native Go library but
not a native Rust counterpart?
The only thing I can think of is cryptography. We do have ring,
but the default in rustls today is aws-lc-rs.
hota_mazi wrote 10 hours 9 min ago:
Nonsense, Rust has plenty of native libraries for HTTP and
JSON.
physicsguy wrote 10 hours 41 min ago:
C APIs are much more annoying to wrap in Go than in Rust
because of lack of enums (important) and unions (less
important).
internet101010 wrote 16 hours 37 min ago:
Has there been a lot of progress with ML in Rust? I don't really
keep up with it because it seems like every crate ends up getting
abandoned and I just gave up caring.
xarope wrote 19 hours 11 min ago:
if you are hitting pauses due to GC issues, you should into putting
appropriate data structures into a memory arena, here's a
reasonable read: [1] These are all tools. Java used to have this
all the time, and we (ex-java programmer) had ways around this
until the JVM improved.
(HTM) [1]: https://uptrace.dev/blog/golang-memory-arena
pjmlp wrote 19 hours 49 min ago:
Rust compilation speed is a matter of tooling, they could have
something like OCaml or Haskell interpreters, which so far hasn't
been a priority.
Or having Cranelift as default backend.
uh_uh wrote 1 day ago:
What kind of apps are you writing where GC spikes matter?
worthless-trash wrote 18 hours 54 min ago:
trading, networking, gaming, ai, realtime, almost anything with
hard response requirements.
throwaway894345 wrote 1 day ago:
Isnât it somewhat easy to remove allocations in Go? I havenât
had to ârewriteâ as such, but rather lifting some allocation
out of loop. Am I misunderstanding the scenario?
hedgehog wrote 9 hours 19 min ago:
Pauses are a problem with heap size and structure, not allocation
rate, because the pause is caused by GC code that is O(heap
size). Making garbage slower reduces the frequency but not
severity. This is an issue with most GCs to some degree, there
are phases of collection where the GC stops execution and the
duration is relative to how much work it has to do which is based
on how many objects and how much memory needs to be checked.
"Concurrent" garbage collection is the approach of trying to
reduce the pauses by doing more of the work while program
execution continues. It's complicated and hard to get right, so
Go's original GC was IIRC fully stop-the-world.
There are some fine points to the O(heap size), for example it's
clearly unnecessary for the GC to scan objects that do not
themselves contain pointers, and work is somewhat proportional to
the total number of objects. Combining numerous small objects
into manually managed slices, coming up with ways to make the
most numerous items pointer-free, etc.
I learned a bit about this when an analytics workload I had ended
up with unacceptable pauses (I think over 1 second), Go's GC is
more sophisticated now but I think in any GC runtime you have the
same considerations to some degree. Some of the best writing at
the time was by Gil Tene, one of the principal authors of the C4
concurrent collector at Azul Systems, starting point here:
(HTM) [1]: https://groups.google.com/g/golang-dev/c/GvA0DaCI2BU/m/S...
ted_dunning wrote 22 hours 8 min ago:
Removing enough allocations to avoid fragmentation can be
maddenly difficult/tedious.
fpoling wrote 1 day ago:
With backend serving many clients with widely varying performance
profile of individual requests when latency spikes happen there
is no particular hot loop. Just many go routines each doing
reasonable thing but with a particular request pattern hitting
pathological case of GC.
Yokohiii wrote 13 hours 12 min ago:
Extreme variance in usage patterns will always be challenging.
But pre allocating some reasonably sized buffers can go a long
way.
hedgehog wrote 1 day ago:
I've run into GC pauses, I think in many (most?) cases there is
some class of bulky data that you can either move into slices of
pointer-free structs (so the GC doesn't scan them) or off-heap
entirely. The workload where GC is slow is also likely prone to
fragmentation so whatever the language you'll have to deal with it.
fpoling wrote 1 day ago:
Java with its copying GC deals fine with fragmentation albeit at
the cost of more upfront memory. And even in Rust one can change
the allocator to try to deal with fragmentation. But with Go
there is simply no good options besides the rewrite.
hedgehog wrote 9 hours 49 min ago:
Possibly in your specific application, usually there are a
handful of options far less painful than a rewrite.
For the original issue of GC pauses, a narrow change is to move
problem data to non-pointer-carrying types, or the bigger
hammer of manually managed slices of those types. The second
helps with fragmentation too. Some workloads can be split into
multiple processes as a direct way to have smaller heaps. If
none of those options are enough then off-heap storage lets you
do whatever you want.
I do have some complaints about Go, but one of the big ones has
been fixed since I last wrote much Go code and it seems like a
fine choice for a lot of applications.
the__alchemist wrote 1 day ago:
I agree! The line early on about this being for backend services
caught my attention. I love the Rust language and use it for embedded
firmware and PC applications, but still use Python for web backends,
because Rust doesn't have any tool sets on the tier of Django (Or
Rails). It has Flask analogs, without the robust Flask ecosystem. I
have less experience with Go, but would choose it over Rust for web
backends, for the same reason you highlight: The library (including
framework) ecosystem. I am also not the biggest Async Rust fan for
the standard reasons (The rust web ecosystem is almost fully
Async-required).
marcus_holmes wrote 23 hours 53 min ago:
Conversely, the Go community tends to actively shun frameworks,
especially anything Rails-like, and will tell you to just use the
standard library. Which is good advice, the standard library really
does have everything you need. But it's also roughly on a par with
what's available in Rust (though as someone said above, the Go
stdlib routines have been heavily, massively, tested in production
by now, and are fully mature and load-bearing).
the__alchemist wrote 23 hours 16 min ago:
Interesting! Are Go backend building custom auth, admin, DB
ORM/migrations/auto migrations, templates, email, dev server etc
for each project? Or each person and org has their own toolkit
they use?
Quothling wrote 8 hours 11 min ago:
Yes.
I think few people would want to use an ORM for the stuff you
use Go for, but there are things like SQLC which can generate a
lot of your "dynamic DB magic" without actually being a real
dependency. You can set SQLC up to run in a container in a
completely isolated environment, and then use the output, but
you can frankly also just maintain the SQL which frankly isn't
that different than using an ORM once you've set up the
automation with ridicilously strict policies.
We use Go for some of our more vital backend parts. We mainly
use Python for entirely different reasons, but since we're an
energy company it's nice to have a standard library that can do
everything without any sort of external dependencies. It's not
because we have some sort of "not invented here" fetish, it's
because we have to write and maintain a literal fuckton of
complaince documents for every external dependency we use and
it's already a full time job for just for Python in our
information security department.
phillmv wrote 9 hours 36 min ago:
>Are Go backend building custom auth, admin, DB
ORM/migrations/auto migrations, templates, email, dev server
etc for each project?
lmao, basically, yes. except when you bring this up ppl think
it's not a big deal / a means for self-expression. having to
sort through which libraries you prefer to glue together is a
kind of freedom, if you squint hard enough.
whstl wrote 11 hours 55 min ago:
Most projects I see use the standard library for almost
everything, but everyone leverage a few libraries here and
there for one thing or the other.
It's just a different philosophy, but it's really not unlike
Rails users importing Devise or Sideqik or RSpec.
ruicraveiro wrote 15 hours 23 min ago:
I tend to use whatever I perceive to be the most fitting
library for each of those concerns (except ORM), but not
complete frameworks.
marcus_holmes wrote 22 hours 58 min ago:
We tend not to use ORMs, because they're evil.
There are various libraries people use for auth, etc. But
rolling your own isn't hard - Go has (e.g.) bcrypt in the
standard library, so most of the heavy lifting is already done,
you can write a solid auth implementation in <50 lines of code
using that.
Generally Go prefers libraries to frameworks. Wrap the hard
bits up into a library that can then be used widely in any
implementation, rather than rolling it into a one-size-fits-all
implementation that doesn't really suit anyone properly.
hota_mazi wrote 10 hours 7 min ago:
> We tend not to use ORMs, because they're evil.
This is typical Go culture. If it is not readily available in
the language or the standard library, it's evil. It's an easy
cop out to explain away the gaps in the ecosystem.
Not long ago, the Go team was saying that generics are evil
for that very same reason.
the__alchemist wrote 9 hours 38 min ago:
Rust backend is like this too, albeit softer. The gaps are
explained as "Why would I want that/I don't need that"
instead of "evil".
My GitHub is dominated by rust projects, and I think it's
the nicest overall language. But not nice enough to write
bespoke solutions for problems that have had robust
solutions since before I started programming! There is a
basic set of functionality most web apps use, and that
hasn't changed in a decade+; I don't want to re-write my
own version of this, nor fight compatibility problems from
(comparatively) poorly-integrated and documented libs.
I am trying to make good decisions, and am weighing "This
long-standing solution does everything I need, and is easy
to use and well-documented etc" vs "People on the internet
are telling me I don't need it, or I can use X rust lib
instead". It feels like the "We have McDonald's at home"
meme.
p2detar wrote 16 hours 36 min ago:
I second that no-ORM statement. I even follow that in Java.
Object mapping is fine, but Iâll write my own SQL, rather
than debug obscure (to me) HQL queries.
st3fan wrote 22 hours 5 min ago:
please donât generalize. there is no âweâ ..
âweâ are all different and i can tell you from experience
that there are also many people and teams who use go and
prefer ORMs and frameworks and do not build everything from
scratch â¦
marcus_holmes wrote 20 hours 44 min ago:
true, but there does tend to be a consensus (or has been)
in the Go community around a lot of this stuff.
LtWorf wrote 1 day ago:
Praising go for how it handles errors, when it's even worse than C
where the compiler at least warns you if you're ignoring return
values of calls. That's a new one.
awesome_dude wrote 1 day ago:
Linters are available to catch you before you compile - with Go
Generally speaking there has to be a mechanism for optional
handling of return values, in Go you can ignore everything (ew),
you can use placeholders `_`, or you can explicitly handle things -
my preference.
If you say "Well in C you have to handle the returns - I am not
across C enough to comment, but I will ask you - Does C actually
force you, or does it allow you to say "ok I will put some
variables in to catch the returns, but I will never actually use
those variables" - because that's very much the same as Go with the
placeholder approach
edit: I am told the following is possible in C
trySomething(); // Assumes that the author of trySomething has not
annotated the function as a `nodiscard`
(void)trySomething(); // Casts the return(s) to void, telling the
compiler to ignore the non-handling
int dummy = trySomething(); // assign to a variable that's never
used again
I welcome correction
ventana wrote 20 hours 58 min ago:
C, as a language, cannot bother less about you using or not using
the return values, checking them, discarding them, or using them
to index an array without any bounds checking. Various linters
and compilers may have their opinions, expressed as warnings, but
at the end of the day it's completely up to you as a developer.
LtWorf wrote 16 hours 33 min ago:
Same as in go, a language designed several decades later.
awesome_dude wrote 4 hours 51 min ago:
Funny - you said Go was worse - now you're saying Go's the
same...
LtWorf wrote 4 hours 40 min ago:
It is worse, gcc has the warnings at least, go does not.
You need a 3rd party linter.
awesome_dude wrote 4 hours 26 min ago:
One compiler (gcc) - and it doesn't do it by default
Go has go vet - baked in and runs by default
I tire of your bad faith ignorance.
ventana wrote 8 hours 35 min ago:
Which is probably not really surprising, if we consider who
were the original designers of Golang!
awesome_dude wrote 19 hours 10 min ago:
Yeah - I assumed so - which makes the GP post... bizarre
lionkor wrote 1 day ago:
> Rust lacks a uniform error type
Rust has practically one error, it's the Error trait. The things
you've listed are some common ways to use it, but you're entirely
fine with just Box (which is basically what anyhow::Error is) and
similar.
fweimer wrote 1 day ago:
Surely you need an alternative to Box for reporting memory
allocation failures?!
afdbcreid wrote 4 hours 23 min ago:
The comparison here is to Go, which doesn't have any way to
handle memory allocation failure AFAIK.
In Rust you can do that (mostly on nightly although not only),
and yes there are alternatives for this case, but it's rare
anyway.
imtringued wrote 10 hours 43 min ago:
Not sure what your problem is?
If you need to handle an allocation error in the error path, then
the error reporting path must abort, which means that the
allocation error must be bubbled up.
There is no real solution to an allocation error inside the error
path. Even if you preallocate an arena for errors, the error
might be large enough that it won't fit inside the arena.
Hence the best thing you can do from that point onwards is to
have an error enum with an AllocError variant that doesn't
allocate. Said error won't contain any information beyond line
numbers of the allocation error since you just don't have the
space for it.
In the end you will basically end up with panic free code, but
the error still bubbles up like regular unwinding.
So yeah you can do it, and I will do it in the future, but I
personally think that the people who think this is some huge deal
breaker don't understand the problem in the first place.
wyager wrote 20 hours 36 min ago:
You're already writing Rust in a very different style if you're
writing the type of code that gracefully handles allocation
failure. It's to Rust's immense credit that this type of coding
is actually fairly well-supported (unlike in Go), but you're
already a bit off the beaten path for stuff like error handling.
loeg wrote 20 hours 39 min ago:
Anything other than panic/abort on allocation failure is outside
the scope of the vast majority of programs, including anything
using the standard library in Rust. I wouldn't worry about Box.
dwattttt wrote 1 day ago:
A &(dyn Error + 'static) should be fine for that; you don't need
any allocated/variable sized data in a memory allocation failure.
dnautics wrote 1 day ago:
stacktraces? might also be useful to know whether or not the
latest allocand was a jumbo sized allocand that caused the
failure?
mswphd wrote 5 hours 38 min ago:
if you have an OOM and want to log why, if your logging
allocates it will likely fail as well. You could in principle
work around this with enough effort, but "properly" handling
OOM is typically much more trouble than its worth.
imtringued wrote 10 hours 36 min ago:
If you let the allocation error panic you will get your stack
trace.
You can't have a stack trace on an error in the error path
that failed to allocate. If you have a "jumbo sized" error
and the error fails to allocate, it won't get reported. The
only reporting you will get is that the error failed to
allocate and this new allocation error overrides the error
that failed to allocate.
SkiFire13 wrote 16 hours 50 min ago:
And how do you store a stacktrace without allocating?
63stack wrote 17 hours 31 min ago:
Any time I mention "but I would like stacktraces with my
errors" I get told I'm doing it wrong.
simonask wrote 13 hours 53 min ago:
That's because the types of errors where you want a stack
trace are a relatively small subset of all possible errors.
Stack traces are only useful for errors that indicate a bug
in the program, i.e. something a programmers has to respond
to. It's not useful for the vast class of bugs that are a
result of wrong input, wrong external state, or
infrastructure issues.
Rust projects tend to favor panicking over error handling
for programmer bugs (which does indeed give you a stack
trace depending on environment variables), or even better
encoding the invariants in the type system, but there are
cases where an error coming from a library are truly,
actually unexpected, so both `anyhow` and `thiserror` do
provide support for attaching a stack trace in those
situations.
63stack wrote 11 hours 45 min ago:
See? You get people explaining to you that you actually
don't want a stack trace because xyz.
wtetzner wrote 3 hours 56 min ago:
This sounds disingenuous. They explained why the
language doesn't force stack traces on all errors, and
then explained how to get them if you want them.
dwattttt wrote 1 day ago:
Do you really want that data passed back down to the caller
of the allocation? From the description of the failure state
you'd want to log that data instead: what's the caller of the
allocation going to do if you tell it it failed with a crazy
size? It already knows the size, it's the one who asked for
it.
dnautics wrote 23 hours 8 min ago:
So, suppose it's a rust library -- you're locking me into
whatever logging system the library author chooses? Maybe
I'd like to consume the relevant data at the entry point
and send it to a logging system of my choice.
pas wrote 14 hours 3 min ago:
it depends, if the functionality represented by the
library is known to require a lot of memory (or simply
allocation failures are an expected part of its
operation), then it should be pretty much part of the
API, probably with some tracing/diagnostics interface to
get the required visibility into how much memory goes and
where.
but for most libraries I on allocation failure I don't
expect any fancy logging system. maybe even panic is
fine.
sheept wrote 21 hours 51 min ago:
A Rust library likely wouldn't be returning an opaque Box
to begin with. Errors are part of a library's APIâit's
what allows consumers to handle themâso you'd define an
enum of possible errors your library could produce and
return that, which would be stored on the stack.
dnautics wrote 21 hours 27 min ago:
What about the data in the error payload?
echelon wrote 10 hours 48 min ago:
You can do better than the errors in other languages.
You can provide all the relevant information in the
emum variant.
enum MyApiBindingCrateError {
// You didn't provide an
// API key. Maybe we should
// design our interface to
// make this impossible
ApiKeyMissing,
// Client was unauthorized
// to make this request
AuthorizationError,
// The entity you requested
// did not exist (404'd)
NotFoundError,
// You're sending too many
// requests to the server
TooManyRequests,
// That specific error with
// the API
// Maybe users can't delete
// folders until they're empty
// Whatever
SpecificApiIssue1,
// Some other specific error
// with the API
SpecificApiError2,
// Server didn't respond the
// way we expected.
// Here's what it told us
UnexpectedHttpResponse {
// HTTP status code
status_code: StatusCode,
// If it had a
// string-encoded body
body: Option,
},
// Unhandled Issue with IO
IoError(io::Error),
// Unhandled Issue with
// request library
ReqwestError(reqwest::Error),
}
The beauty with Rust is that you can create really
detailed concrete errors at the crate level. Your
callers will know exactly what the actual error
states are.
Your application can be a little less structured if
you want. Though with LLMs, I'm using anyhow and
thiserror a lot less.
imtringued wrote 10 hours 30 min ago:
In the current context with regards to failed
allocations, you're also supposed to add a variant
that wraps AllocError.
dwattttt wrote 16 hours 25 min ago:
I think this is a clash of terminology: a Rust enum
isn't an integer with pretensions of an identity.
You'd describe it as a tagged union in some
languages. So when you say you'd return an error with
extra information, what that information is is
associated with the specific variant of the enum.
Using yuriks AllocError as an example, if the error
is SizeTooLarge, it has the size field. Other errors
may have no additional data, others may have
different data.
When you return an error from your allocating
function, it's a known size, the size of the largest
enum variant + the discriminant (tag).
dnautics wrote 3 hours 28 min ago:
I'm aware that a rust enum isn't just an integer?
How would it have a payload if it were just an
integer?
right. If allocerror only has size field, where do
you stash the unwind information (which could be of
arbitrary size)
dwattttt wrote 2 hours 43 min ago:
There's a few confusing things here. For one,
just because the allocator gave you an
AllocError, that doesn't mean your function has
to return an AllocError: you can return whatever
error type you choose. If you want to collect a
stack trace at that point, put one in there.
What value would a stack trace that includes
internal allocator functions be to you? What do
you lose by having to collect the stack trace at
the point where your function receives an
AllocError?
yuriks wrote 21 hours 5 min ago:
That's part of the error enum.
enum AllocError {
SizeTooLarge { size: usize },
// etc.
}
This enum has a known size and doesn't require any
dynamic allocations.
cobbzilla wrote 22 hours 25 min ago:
usually âstdoutâ is good enough, wrapper/runner
routes output to logserver for collation and search. who
cares about formats as long as itâs reasonably
structured and searchable?
BobbyJo wrote 1 day ago:
Having many semantic options for error usage is functionally the
same as having many error types, except worse.
lionkor wrote 16 hours 32 min ago:
Please go write C++ and then come back to us
BobbyJo wrote 10 hours 3 min ago:
I spent 5 years writing C++.
ViewTrick1002 wrote 1 day ago:
They all convert seamlessly, and the enums make the branches
explicit. Don't even need to check the documentation to find
which errors supposedly exists like in Go with its errors.Is,
errors.As, wrapping and what not.
An easy rule before you make a knowledge based choice is
Thiserror for libraries, helping you create the standard library
error types and Anyhow for applications, easy strings you bubble
up.
Or just go with anyhow until you find a need for something else.
[1]
(HTM) [1]: https://crates.io/crates/anyhow
(HTM) [2]: https://crates.io/crates/thiserror
throwaway894345 wrote 1 day ago:
Iâve repeatedly tried using Rust and the error handling has
tripped me up every time and has been ~90% of the reason for
moving a project back to another language. Iâm sure Iâm
just holding it wrong, but what I run into usually goes
something like this (mind you, I have read the Rust book):
* Someone tells me to use enums for errors, in a comment like
yours
* I try writing the enums by hand, implementing the error trait
* I realize that in order to use the ? operator I need to
implement From on my errors (Iâve read so many comments about
how awfully verbose Go errors are, so I assume Iâm supposed
to use ? in Rust). There are also some other traits IIRC but
Iâve forgotten them.
* I realize that this is pretty tedious, manual work, so
someone points me to thiserr or similar
* Now Iâm debugging macro expansion errors and spending
approximately the same amount of time
* I ask around and someone tells me not to bother with thiserr
and to just write the boilerplate myself or else to use anyhow
or boxed errors everywhere
* I try using boxed errors everywhere, which works, but now I
have all of these allocations which feels like Iâm doing
something that will bite me later. Oh well, but now I need to
annotate my errors so I can figure out what is actually
happening. I guess I should use anyhow for this?
* Anyhow mostly works but this is approximately as verbose as
the Go error handling that Iâm told is Very Bad, and when I
ask for code review most Rust people are telling me not to use
anyhow because errors should be enums, at least in the API
surface
Iâm sure Iâm doing it wrong, but as with many things in
Rust, the Right Way is so rarely clear and every other Rust
person gives different advice about how to solve my problem and
the only thing they seem to agree on is that Rust has an easy
solution and that Iâm following the wrong advice. (Similarly
when I had lifetime problems and half the community told me to
just use clone and Rc everywhere until I had performance
problems, so instead I just had different static analysis
problems).
I donât love Goâs error handling. It feels like there has
to be something better than its runtime-typing. But it largely
gets out of the wayâcreating an error is just implementing
the Error method, and if you need a concrete type you use
Is/As/AsType. Wrapping is fmt.Errorf. All of this is built into
the stdlib and used pretty ubiquitously across the
ecosystemâI donât run into âthis dependency uses a
different error frameworkâ. Error handling is marginally more
verbose than with Rust if you are actually attaching context in
both, and neither solves the problem of which call frame
attaches the context about specific function parameters (e.g.,
which level of error context specifies that the function was
called with path â/foo/bar.bazâ). Itâs terrible, but it
worksâfeels like the least bad thing until the Rust community
can arrive at some consensus and document it in The Book. Or
maybe I just need to try again in the LLM era?
mswphd wrote 7 hours 3 min ago:
a few things
1. thiserror just does codegen of the "standard" enum things
people do. if you find debugging thiserror difficult, just
write out the enums manually. sure it's uglier, but (roughly)
equivalent. so its preferable as synctatic sugar for enums,
but doesn't have any technical benefits (in the same way that
syntatic sugar never really does).
2. for boxed errors, you only get allocations on your error
path. Hopefully this is a cold path so it shouldn't matter.
There is a general theme behind rust error handling though
which it can be good to internalize. In particular, the more
details of your errors you encode in the type system, the
more powerful things are. Any error type could just be
pub struct MyError(String)
the issue is that this gives very little information to a
caller on what to do with your error. If you have no callers
(e.g. are making a binary) it's fine, and (roughly) what
`anyhow` does.
That all being said, when designing errors a natural question
to ask is "can my caller do anything meaningful with this
error"? For example, in Rust stdlib, `Vec::push` can
allocate. This allocation can fail, which panics. "Proper"
error handling would use the fallible allocation API, and
propagating an OOM error or whatever through results. For
most applications, this is not an error that is worth
investing that much time into guarding against, so using the
(potentially panicing) `Vector::push` makes things easier.
You can take this same perspective in other settings as well,
in particular separating out errors into
1. structured data, that a caller should be able to
extract/process to handle the error, and
2. unstructured data, that is more used for logging, and you
expect the caller to pass up the call stack without
inspecting themself.
Handling both types of these errors with `thiserror` can be
tedious for little benefit. I've found it useful to instead
solely use `thiserror` for category 1, and category 2 does
other things. This could be using `.expect(...)`. There are
some crates that make this nicer (e.g. `error_stack`). But
the point is that it can significantly clean things up if you
only encode in your error enums failures that you expect
someone to handle, rather than just e.g. log.
This does somewhat validate your point that the "right way"
I've been experimenting with (and mentioned above) is not
just "use this-error".
Also: a big issue with `thiserror` is the tedium of handling
the large error enums (or giving up on using it "properly"
and shoving together multiple error variants in some
unstructured error type). that is somewhat better in the LLM
era, as you can have the LLM handle the tedium.
echelon wrote 11 hours 2 min ago:
I'm so perplexed by this, because Rust errors are what make
the language so amazing.
> Now Iâm debugging macro expansion errors and spending
approximately the same amount of time
This never happens once you've learned the language a bit
more. Anyhow and thiserror are a cinch.
> I realize that this is pretty tedious, manual work, so
someone points me to thiserr or similar
Claude writes Rust so effectively. It can do all of this for
you now. It's effortless. In fact, I don't see any reason to
use any other language unless I'm targeting web or some
specific platform, or dealing with legacy code. Rust is now
the best tool for most problems.
> Similarly when I had lifetime problems and half the
community told me to just use clone and Rc everywhere until I
had performance problems, so instead I just had different
static analysis problems
Do this for a month, then it'll click and be second nature.
Also Claude will make quick work of it now.
> feels like the least bad thing until the Rust community can
arrive at some consensus and document it in The Book
It's difficult because it's so different. But once you get
used to it, you'll realize it's the best approach we have
right now.
> Or maybe I just need to try again in the LLM era?
Seriously this. You'll be writing Rust code as quickly as you
would Python code. It'll be high quality. And the type system
will mean that Claude emits better code on average. You'll
pick it up quickly.
throwaway894345 wrote 9 hours 25 min ago:
I think Claude may be what makes me use Rust successfully.
Firstly itâs ability to deal with the tedium and secondly
not needing to solicit help from people who tell me my
problem is trivial while giving contradictory solutions :)
> And the type system will mean that Claude emits better
code on average.
Iâm curious if this is true. I believe that it emits
better code than with a dynamically typed language, but as
with people I donât know that the sweet spot is at the
extreme. Or maybe it is at the extreme when the context is
small but as the context grows perhaps code quality suffers
as it has more constraints to balance?
mswphd wrote 5 hours 40 min ago:
There's a number of things about rust that help compared
to other statically typed languages.
1. the compiler gives very high quality error messages.
It helps humans, and also helps LLMs
2. Rust reduces memory management to local reasoning (via
the borrow checker). This means that it performs well
even as context grows, because checks in one
function/module are well-encapsulated to that
function/module.
3. Rust can more easily obtain this encapsulation for
more general properties than many other statically typed
languages. In particular, rust's type system is very
strong, so it's easy to take a function `func(x: T)` that
relies on some implicit assumption on `x` (say that it is
non-zero), and turn it into an explicit requirement. By
this, I mean you define `pub struct NonZero(T)`, and
provide constructors `pub try_new(t: T) -> Result, _>`
that error if the condition doesn't hold. If you
additionally only provide public methods on `NonZero`
that uphold the invariant, you can lift runtime runtime
assertions to the type level. This is both good practice,
and helps out LLMs quite a bit.
This is to say that rust makes it quite easy to
encapsulate implementation details (both regarding memory
management, as well as other details) essentially
completely. Sometimes you still have invariants that need
care/can't be encapsulated in the type system, but such
invariants should be marked `unsafe`, so it can be easier
to audit the LLM's output.
Anyway, the "more constraints to balance" is only
problematic if all the constraints are inter-dependent.
It's definitely possible to get LLMs to generate
spaghetti code like this, but the way you fix it is the
way you fix similar issues in other languages.
echelon wrote 7 hours 26 min ago:
> Firstly itâs ability to deal with the tedium and
secondly not needing to solicit help from people who tell
me my problem is trivial while giving contradictory
solutions :)
I'm so sorry for this btw.
The problems are trivial once you've used Rust for n
hours, for some value n. It's just that these folks
forgot the learning and headache they went through.
You're going to build that same recognition and
familiarity using Claude over time. It'll seep in pretty
quick, I'd imagine.
> Iâm curious if this is true.
Being forced to emit an Option or Result and then having
to actually use syntax to get at the goods forces the
code to deal with errors the appropriate way, clearly,
idiomatically, and typically in a good flow that is
amenable to readability and easy refactoring. Other
languages without Option, Result, and sum types baked
into the language so fundamentally do not have this
advantage.
I feel it every time I have to work in a TypeScript
codebase, for instance. It's a strongly typed language,
and can emulate sum types via discriminated unions. But
that doesn't convey the same advantages because it
doesn't enforce anything. It's far too lose to have the
same advantages Rust has.
I think you'll feel the same way as you use the language
more and more.
pas wrote 14 hours 12 min ago:
there are many (right) ways for writing monad transformers,
and it's usually situation dependent which one makes sense.
(practical aspects such as which errors do you want to merge,
ignore, provide some default/fallback result; and of course
overall coding style consistency helps guide this, but it's
not trivial.)
(there's a lot of this in Scala too, because of the various
monads/containers, eg. the built-in Future, and then
Scalaz.IO, FS2, Cats, ZIO, etc...)
regarding lifetime and performance problems, the best
practice seems to design the rough scaffolding of the program
first, with the structs, so the who owns whom can be figured
out. but this is far from trivial. Rust is very good at
forcing developers to stare at these problems, but solving
them requires practice and patience.
for me the tech toolbox that makes sense is TS by default
(because of the super convenient type system and tooling),
and Rust when the circumstances really justify it (latency,
throughput, scalability, cost effectiveness, or a need for a
single native executable [though nowadays this is also pretty
simple with Deno], or more safety/control [no GC])
Animats wrote 21 hours 5 min ago:
> âthis dependency uses a different error frameworkâ.
Common in HTTP land. The HTTP system returns a different
error type than the network I/O system, but they can be
sorted out.[1]
(HTM) [1]: https://github.com/John-Nagle/maptools/blob/main/rus...
ViewTrick1002 wrote 1 day ago:
How come you get macro expansion errors? Or is it because you
write incorrect syntax in the enum error definitions?
The example on the docs page is quite clear: [1] Including
all kinds of errors: Strings, tagged unions and automatically
converting from std::io::Error with added context.
That one page document is the entire documentation for the
thiserror crate.
(HTM) [1]: https://docs.rs/thiserror/latest/thiserror/#example
throwaway894345 wrote 22 hours 26 min ago:
Itâs been a while, I donât remember the details, but it
wasnât syntax errors.
iknowstuff wrote 1 day ago:
Rust does not have three error systems. It has one: the Error trait.
io::Error is one of many that implement it (nothing special about
it). Errors defined via thiserror also implement it.
âAnyhowâ just allows you to conveniently say âsome Errorâ if
you donât care to write out an API contract specifying types of
errors your function might spit out.
tptacek wrote 1 day ago:
He's not making that up; in practice, you're going to run into and
need to make mental space for the idiosyncrasies of multiple error
frameworks.
kelnos wrote 19 hours 51 min ago:
Not sure what you mean by that. If you're consuming the API of a
crate that has functions that return errors, you're not really
dealing with a "framework", you're just dealing with whatever the
`E` is in the `Result`. If that `E` doesn't implement
std::error::Error, I'd consider that a deficiency (even a bug)
for that crate. (Yes, I know some crates want to support use in
`no_std` environments; that's what features are for.)
If I care about the specific variants of error that a function
can return, so I can do different things depending on what kind
of error occurred, I'll read the docs and match. That's not
really a "framework" thing; that's just a basic thing that anyone
has to do in any language in order to consume an API. If I need
to propagate the error, I'll do so (either directly, or by
wrapping it in a variant of my own error type). I don't see how
any of this is "framework"-y.
A crate's decision to use thiserror (or not) does not matter to
me. If a crate exposes `anyhow::Error`, that's a lazy choice and
bad API design, but still "works" and I generally don't need to
care about it.
Or is there something else you meant when you said "error
frameworks"?
so-rose wrote 17 hours 33 min ago:
Just wanted to add that `Error` has been in core since `1.81`
[1], meaning that even `no_std` environments can/should
represent errors the same way.
(HTM) [1]: https://doc.rust-lang.org/core/error/trait.Error.html
dwattttt wrote 1 day ago:
I guess you might have to if you need to use a library someone's
written that doesn't implement the standard.
Writing primarily applications, I couldn't tell you what error
handling frameworks my dependencies are using: I literally don't
know, and haven't needed to know in order to display, fail, or
succeed.
EDIT to add: I use anyhow for this, so I should also add "add
context to an error when I fall" to the list of things I do.
awesome_dude wrote 21 hours 51 min ago:
Not rust specific, and most certainly not a criticism of you -
but I hate when people call a lib that errors, then just bubble
that error up.
I mean the error is supposed to be tailored to the audience - I
guess what you are saying is that you handle the error by
saying "I called foo with X, Y, Z, and got this error back" in
the logs - which your caller then also does - producing a log
message of
ERROR: I called Foo with X Y and Z and got error: Die MF die
followed by
ERROR: I called Bar with X Y Z and a and got error: ERROR: I
called Foo with X Y and Z and got error: Die MF die mf (still
fool)
And so on and so forth.
If the counter is - don't log, that's fine, but you have to
know where in the call graph that error state was reported to
the logs
dwattttt wrote 19 hours 25 min ago:
I have tried to figure out some kind of unification between
"collecting error state in a function", "logging error
state", and "return error state to a parent".
I haven't found any satisfying solution to it all; collecting
information for logging vs information that a caller would
want... I've been meaning to investigate tracing_error to see
if it brings it all together.
awesome_dude wrote 19 hours 17 min ago:
Regardless of language - if you find a good, clear answer -
blog the hang out of it - I for one have been searching for
the right way to manage this, and it's not (yet) clearer -
other than what I've said so far
what wrote 19 hours 54 min ago:
Youâre supposed to bubble errors up to the level that can
appropriately deal with them? You donât need to log them
each step of the way.
awesome_dude wrote 19 hours 18 min ago:
Yeah - but that's the same as my final point - you have to
know who is supposed to manage the error/log - all the way
up (and down) the call graph
edit: I've just finished debugging a multi system chain -
FE -> SNS -> SQS -> Lambda -> DynamoDB -> Lambda -> Webhook
-> My poor code
My code has multiple layers - and I was trying to find
where in the very long chain of calls the data was being
mangled
It turned out that there was an unlogged error, which was
mismanaged by a caller - there's no shade here - the caller
was handling the error how it was designed to, but by not
logging that there was an error - it took a minute to
understand.
the__alchemist wrote 1 day ago:
What's the standard? I'm not being snarky; I'm going down the
thought process of how this would work in practice.
I am on team Io Error [on std rust]", somewhat arbitrarily. If
I call a lib that is on Team Anyhow, or Team Custom Error Enum,
I will have to do some (Straightfoward, but a little clumsy)
conversions if I want ? to work. This is complicated by being
able to impl From for ErrorType2 only in one direction if you
don't control the other crate. (due to the orphan rule)
iknowstuff wrote 23 hours 45 min ago:
There is no team io::Error. There is only one standard:
(HTM) [1]: https://doc.rust-lang.org/core/error/trait.Error.htm...
dwattttt wrote 1 day ago:
By standard I meant an error type that implements
std::error::Error.
EDIT: Which I assume all my dependencies have done, given
that anyhow is able to consume all of them.
I specifically called out writing applications as my use
case: my only objection to tptacek's note is the somewhat
universal "in practice". The burden for designing errors for
a library that others will use is higher, but that's far from
the default/universal experience.
Many more people are going to consume libraries & not produce
any of their own, and I think my experience is representative
there.
arccy wrote 1 day ago:
perhaps the oncall is better if you write your own services, but as an
SRE / ops person who has to run other people's services, rust ones just
generally seem to be worse: logs that are so verbose but seem to tell
you nothing, statsd seems to be the only choice for metrics,
contextless errors everywhere, memory "leaks" (more like runaway memory
use) that the developers swear are impossible because it's rust,
overall just less mature across services written by both in house and
oss teams
gertlabs wrote 1 day ago:
I liked Rust before running a benchmark, but the gap between how
effectively most LLMs write in Rust vs Go was still surprisingly large
to me (especially in agentic harnesses where they can fix the initial
environment issues). I've become a pretty big Rust evangelist after
seeing that. We've had a lot of success writing batch processing tools
in Rust to be called by our existing codebase, but haven't attempted a
full production migration... yet.
I will say that many of the issues with Go in the article, especially
re: nil handling are increasingly solved by thorough coding reviews
with Codex. Better to not have the issue in the first place, sure, but
these kinds of security bugs are becoming optional to developers who
put in at least as much effort to review and understand code as they
put into the initial design and execution.
Language data at
(HTM) [1]: https://gertlabs.com/rankings?mode=agentic_coding
J_Shelby_J wrote 1 day ago:
The detailed compiler errors and strong type system makes the change
-> compile -> change loop simple for agents to handle. Rust provides
very strong rails it forces users on to. Codex always manages to get
something to compile.
The downside is that maybe it should fail sometimes when an idiomatic
approach isnât viable⦠instead it will implement something stupid
that compiles and meets the request.
logicchains wrote 1 day ago:
The weakness of Rust WRT LLMs is compilation times. LLMs code faster
and hence spend relatively more time waiting for compilation than
humans do, so on reasonably sized projects (e.g. 100k+ lines) Rust's
~10x slower compilation starts showing up as a bottleneck. If you're
writing some critical infrastructure it makes sense to pay that cost,
but if you're writing some internal service that's not publicly
exposed to the internet then development velocity may be a bigger
concern. (I'd argue that slow compilation also influences human
development velocity, but for some reason developers very rarely try
to quantify this.)
Havoc wrote 13 hours 37 min ago:
>The weakness of Rust WRT LLMs is compilation times.
That's a more tractable problem then basically anything else around
LLMs and programming. We're definitely getting more cores in the
avg machine judging by roadmaps & leaks
J_Shelby_J wrote 1 day ago:
10x slower is like an extra second, if that, for compilation times
for the sizes of changes an agent like codex makes.
amusingimpala75 wrote 1 day ago:
This is probably going to sound generic / repetitive, but my biggest
complaint about Rust is the package management situation, which is
entirely the result of the developer mindset. I love the ergonomics on
the rust side (the functional approach to data types is beautiful), but
Iâm working on two projects side by side, one in rust and one in go
at the moment. The dependency trees are entirely different beasts, with
most of the stuff on the go project covered by the stdlib whereas I
think the rust project is over 400 despite asking for just rusqlite
(sqlite), clap (cli), ratatui (tui), and tauri (gui), the last of which
is by far the worst offender but even without it, itâs still close on
100 which is crazy. If there were (and maybe there are, I just
havenât found them) decently maintained alternatives to the rust
crates that actually have a sane dependency approach, Iâd feel much
better. Iâm just trying to not shai hulud my system, and the rust-web
people seem to want to turn cargo into npm in that regard.
ViewTrick1002 wrote 1 day ago:
> rusqlite (sqlite), clap (cli), ratatui (tui), and tauri (gui)
Does any language, except like Java, exist with a standard library
comprising matching that?
Also, keep in mind that Tauri itself is 14 crates, where each one
shows up in your build tree. [1] And Ratatui is 6:
(HTM) [1]: https://github.com/tauri-apps/tauri/blob/dev/Cargo.toml
(HTM) [2]: https://github.com/ratatui/ratatui/blob/main/Cargo.toml
amusingimpala75 wrote 23 hours 22 min ago:
At least in the case of sqlite, rusqlite pulled in 5 or so in total
whereas Go had a single library that was a thin wrapper around
sqlite, and integrated into the stdlib interface. Many fewer deps
Edit: counts are fair, thatâs still hundreds unaccounted
PyWoody wrote 1 day ago:
Python has sqlite3[0], curses (tui) [1], and tkinter[2] in the
stdlib.
[0] [1] [2]
(HTM) [1]: https://docs.python.org/3/library/sqlite3.html
(HTM) [2]: https://docs.python.org/3/library/curses.html
(HTM) [3]: https://docs.python.org/3/library/tkinter.html
chlorion wrote 10 hours 49 min ago:
And ironically with the exception of the python sqlite3 module,
the rust alternatives are much higher quality, IMO.
Does anyone even use tkinter in modern times anyways?
PyWoody wrote 8 hours 25 min ago:
I wouldn't start a company behind it but tkinter is perfectly
fine for basic guis. It has its quirks but who doesn't?
ViewTrick1002 wrote 1 day ago:
Right. The famous stdlib where once good libraries go to die so
you instead depend on the latest community replacement choice.
Also argparse for Clap:
(HTM) [1]: https://docs.python.org/3/library/argparse.html
dwattttt wrote 19 hours 15 min ago:
To highlight the problem for Python: Python's standard library
has getopt, optparse, and now argparse. I don't think they set
out to offer 3 argument parsing libs, one of which is marked
superseded, but here we are.
praseodym wrote 1 day ago:
Note that many Rust libraries consist of multiple crates, which all
end up in the dependency graph. This makes the number of dependencies
seem higher than it actually is: the separate crates have the same
maintainers and are often part of the same upstream git repo.
I agree with the general sentiment though. Rust also has a lot of
crates that are stuck semi-unmaintained at some 0.x version, often
with no better alternative.
J_Shelby_J wrote 1 day ago:
There is good reasons to break out projects into multiple crates.
It makes reusing functionality elsewhere easier. It makes it easier
to reason about behavior. It makes it easier for LLMs to understand
(either working within the crate or consuming as an api surface.)
So you end up with projects that have multiple crates inside the
same workspace and it really blows up dependency count.
nicoburns wrote 1 day ago:
The other very important reason for splitting into crates is
compile times. Crates are the "compilation unit" and you often
get more build paralellism with more crates.
vlovich123 wrote 1 day ago:
Unfortunately the 0.x version has pervaded because of community
cargo culting claiming that versioning is easier with 0.x than with
major version numbers > 0. Personally I find that hard to believe,
especially given packages like Tokio and anyhow (still at v1) make
it work and thereâs others that are >v1.
That is to say 0.x doesnât necessarily mean unmaintained, it can
also mean âI donât want to have to think about how to version
APIs / make guarantees about APIs). Eg reqwest is very widely used
and actively maintained yet is still at v0.13.
nicoburns wrote 1 day ago:
> claiming that versioning is easier with 0.x than with major
version numbers > 0
I think it's less that versioning is claimed to be easier with
0.x versions, and more that some people have got into their heads
that 1.0 signals either "permanently stable" or "no new versions
for several years" and they don't want to commit to that yet.
I do wish more crates would 1.0 (and then 2.0, etc).
awesome_dude wrote 1 day ago:
Package management is the bane of nearly every language/technology
Nobody has "solved" it, and I don't think that there will ever be one
(never say never, though, right?)
For Go we rely on developers of libraries to adhere to the semver
versioning scheme accurately, and we cannot "pin" versions (a
personal bugbear of mine)
There is a couple of workarounds - using SHAs not unlike the git
commit hash to provide a pseudo version, and, vendoring (which is a
cache of known dependencies - which brings with it cache management
problems)
I had the misfortune of having to use Python with a virtual env on
the weekend - it did not end well, and reminded me why I migrated
away from Python.
Look at
Perl (cpan)
Java (maven, gradle)
Ruby (gems)
Go (dep, glide, vgo, modules)
Rust (cargo)
Node (npm, yarn, etc)
OSes too
Redhat (yum, rpm, etc)
Debian (apt)
Ubuntu (snap - god why????)
And so on
dxdm wrote 8 hours 1 min ago:
> I had the misfortune of having to use Python with a virtual env
on the weekend - it did not end well, and reminded me why I
migrated away from Python.
I see this sentiment a lot, and it doesn't match my experience at
all.
In my decade-old bubble of using Python professionally, I've never
had an issue with virtualenvs. The few issues I might've had with
dependency resolution must be so far in the past that I don't
remember. But that's not strictly about virtualenvs. Likewise, pip
could be clunky, but we don't have to deal with it anymore.
My niche is mostly backend. Other Python niches must be
considerably worse in this regard.
awesome_dude wrote 5 hours 7 min ago:
I used Python for a decade (professionally), gave up on it once I
started using Go (professionally) in earnest - about 8 or 9 years
ago.
I never liked virtual envs, having to remember where they were,
what their names were, and what was installed into each one was a
pain point for me.
This weekend I was trying to learn some AWS stuffs, and I cloned
the official repo of example code which was Python. I followed
the directions exactly and ... boom Python versioning issues...
inside the freaking venv
Who needs that?
Why do I need to spend the better part of a couple of hours
debugging a versioning problem? (FTR The problem turned out to be
the repo was hardcoded to 3.8 and my local Python was 3.9.. or
something along those lines - you are welcome to correct me, but
that's what I remember of a painful waste of my time)
With Go I have backward compatibility guarantees - usually (there
have been instances in the past where the backward guarantee have
been broken AND the build process got broken hard for modules,
with the claim that it was external and therefore not subject to
the same guarantees)
> I see this sentiment a lot, and it doesn't match my experience
at all.
My old HCI professor used to tell me - if users are complaining
(or producing workarounds like post-it notes on their monitors) -
regardless of how clean or elegant you think the system is - it's
not.
You're saying you see people complain about it a lot - therefore
it's a genuine problem.
andrewflnr wrote 2 hours 58 min ago:
> having to remember where they were, what their names were,
and what was installed into each one was a pain point for me.
It's at the project root, it's named 'venv', and its contents
are described by requirements.txt.
> You're saying you see people complain about it a lot -
therefore it's a genuine problem.
Debatable as a principle, but applicable enough here I suppose.
Still, I'm not saying the problems aren't real, but what I (and
probably most of us virtualenv users) are saying is that
there's a pretty broad swathe of projects where you don't
encounter them. It's just fine. You install your packages and
use your packages and that's the whole story.
I guess if you have a hard dependency on a particular version
of python, it's going to be harder, but... why? That's already
niche in my book. If you're saying the AWS repo was pinned to a
particular version of python, I'm going to blame that on Amazon
frankly. That's definitely bizarre.
Edit: Were you looking at this? [1] Definitely more complicated
than a typical greenfield virtualenv-able project, with some
python version restrictions.
(HTM) [1]: https://github.com/boto/boto3
mxey wrote 9 hours 49 min ago:
Actually with Go modules you are always pinning dependencies.
Whatâs in your go.mod is what is used. If your go.mod needs to be
updated because a dependency wants to bring in a newer version of a
transient dependency, the go.mod has to be modified (by the go
command, not by you)
awesome_dude wrote 5 hours 5 min ago:
I don't think you understand the term "pinning"
go mod tidy will update your go modules whenever it feels it
needs to and there's nothing you can do to stop it.
The workaround is vendoring, where you control the versions in a
cache.
mxey wrote 2 hours 46 min ago:
Pinning to me means there is a file with all the versions as
they will be used. I donât see how âgo mod tidyâ
modifying it is different from âbundle installâ modifying
it.
kbolino wrote 2 hours 49 min ago:
There is something you can do to stop it actually. You can use
a replace directive, specifying that a module is replaced by
itself at a fixed version. See e.g. [1] It is worth noting
though that, even without such pinning, `go mod tidy` does not
update versions willy-nilly. [edit: the following is
inaccurate, see grandchild comment] It only syncs go.mod with
what is already being used by the build process. In other
words, if you see `go mod tidy` change a version, it means that
you haven't tidied the file since making other changes to it,
and the listing in go.mod was stale with respect to the
resolved set of transitive dependencies actually being used.
(HTM) [1]: https://stackoverflow.com/a/77412524/814422
mxey wrote 2 hours 44 min ago:
> It only syncs go.mod with what is already being used by the
build process
If dependencies are incomplete, Go will fail to compile and
tell you to run go mod tidy to fix it.
kbolino wrote 2 hours 8 min ago:
Indeed, I ran two tests (missing indirect dependency, stale
indirect dependency version) and it refused to compile
both. Either what I said was never true, or it was only
true for earlier versions of the `go` command.
Nevertheless, adjusted accordingly, I believe the following
statement is true: `go mod tidy` doesn't change versions in
go.mod unless it needs to, to satisfy the other
dependencies listed in go.mod, or to fill in a missing
dependency for an import in code. It would be nice if there
were a flag to turn off the latter behavior, though.
never_inline wrote 10 hours 20 min ago:
> we cannot "pin" versions
you can? that's why go.sum exists. you can also use the replace
directive for more advanced scenarios.
awesome_dude wrote 5 hours 3 min ago:
No - go.sum alerts you to the change - it doesn't prevent it.
replace directives are ok, but you need to look at why workspaces
were invented to get an idea of their shortcomings (hint: people
used to have a replace directive locally that they would
accidentally push and that would break other peoples builds)
corndoge wrote 1 day ago:
Nix solved it. Languages could choose to adopt Nix as their
packaging system.
gitaarik wrote 21 hours 2 min ago:
In theory, but not in practice
tadfisher wrote 1 day ago:
It did and didn't. Nix tools for building language-specific
packages almost always wrap the language build tool/package
manager. This can be easy or hard, depending on how onerous the
build tool is for vendoring libraries.
What Nix and build tools need to agree on is a specification or
protocol for "building a software dependency tree". Like, I
should be able to say 'builder = cargo' in a Nix derivation and
Cargo should be able to pick up everything it needs from the
build environment. Alas, there is simply far too much tied up in
nixpkg's stdenv for this to be viable, so we have magic stdenv
builder behavior via hooks when a build tool is included in
nativeBuildInputs.
corndoge wrote 19 hours 20 min ago:
Thanks for writing this, I learned something
awesome_dude wrote 1 day ago:
I think one of the key problems too is that a system level
dependency is managed by people dedicated to ensuring the
chaotic nature of the package they are responsible for conforms
to the way the OS they are maintaining for has proscribed.
There's no real way to do that at a language level - we cannot
have "Go has determined the package you are trying to fix has
not met the versioning requirements proscribed so you cannot
submit the patch to fix it"
What language dependencies do is what OSes would think of as
"unofficial versioning" that is, an OS will let you install and
run an unofficial version of some lib (we've all been there,
right, multiple versions of some core library because one
doesn't work with whatever you are trying to install), but they
will not manage it at all.
JuniperMesos wrote 1 day ago:
Why is it worse to import a number of other packages that provide
exactly the functionality you need, than to have a large standard
library that provides some but not all of the functionality you need,
requiring you to still use some large dependencies?
pier25 wrote 1 day ago:
For example, security. See all the supply chain attacks from the
past couple of years.
OtomotO wrote 1 day ago:
The stdlib is the place where good ideas go to die.
And then you have httplib3 followed by httplib4.
In other words: I highly prefer the Rust approach.
It doesn't matter a lot whether I rely on the stdlib or another
dependency to me.
It's a dependency after all.
People think just because it's the stdlib it's somehow better quality
or better maintained, but these are orthogonal concepts.
In the end it depends solely on resources.
Sure, the stdlib may get more of these, but it may also grow fat and
unmaintainable...
bborud wrote 14 hours 40 min ago:
Iâd argue that this is wrong. Having a conservative standard
library that aims to contain most things most people need is
preferable to third party libraries in 90%. For the 10% that
isnât covered to your liking by the standard library you can turn
to third parties. You get both a practical standard library and
third party options.
I did a lot of cryptography over the past couple of years. Go has
that in the standard library. For the last decade and a half
cryptography is something that every developer has to deal with at
some point, and it NOT being the awful pain that it is in just
about any other language, is a good thing. Sure, it does not
contain every algorithm and mechanism in the world, but it contains
everything you need for 90% of cases. That means that most of the
time you donât have to do the extra work of ensuring you have an
out if the library you depend on should go away/bad, bugs will be
fixed, people speak a common language and you donât have to do
twice the work in terms of risk assessment.
People keep forgetting that you have to evaluate these things in
the real world. In practical real-world situations. The real
world is not about what works in theory but what actually provides
value for actual people working on actual projects.
bigstrat2003 wrote 20 hours 18 min ago:
The stdlib isn't necessarily better, but it's always there. To use
Python as an example, I tend to prefer requests to urllib2, as do
most programmers. But I've absolutely been in scenarios where all I
could get was the stdlib, and having urllib2 saved my ass. I think
it's extremely important for the stdlib to be batteries included,
even if they aren't the best versions of those batteries on the
market.
tcfhgj wrote 3 hours 20 min ago:
so how do you get into scenarios where you only can use the
stdlib?
amusingimpala75 wrote 23 hours 25 min ago:
Iâm not arguing on quality of the library, Iâm arguing on not
getting pwned by the sheer number of transitive dependencies
surajrmal wrote 9 hours 55 min ago:
The problem is that trust shouldn't be so binary. We should have
ways to increase trust without needing to resort to the standard
library. There was an effort to do this at some point in rust but
the idea was sadly not well received. Maybe it'll end up reviving
itself with modern supply chain concerns.
The idea is that there could form some groups of well maintained
crates that only depend on each other and have a similar amount
of oversight. This actually naturally happens in c++ because
grabbing dependencies is so painful, but it makes dependencies
more trustworthy. For instance boost, absl, folly, etc.
cogman10 wrote 7 hours 59 min ago:
I've harped on this for years, but few devs seem to grasp the
concept that less dependencies is better than more. Especially
library authors.
It's only now that the supply chain problems with npm are
becoming beyond obvious that we are seeing devs come around to
this notion (leftpad should have been the canary in the coal
mine).
The javascript ecosystem has corrupted far too many other
programming ecosystems. The notion of "just make a small
package like is-even" is really the core of the problem. But
also people making libraries often have the wrong mentality
about that process. They think of it like they are making an
application (So why not just pull in a bunch of random deps).
Every dependency a library brings in should have a serious
conversation and analysis on "how much work would it be to just
do this functionality here". And if it's not that much, then
preference should be to duplicate, not depend.
skydhash wrote 5 hours 35 min ago:
A lot of libraries should have been gists, blog posts, or
stack-overflow answers. When I see a library imports a
dependency of a few function related to its domain, I canât
help but wonder why they donât want to take responsibility
for that small snippet of code.
galangalalgol wrote 13 hours 13 min ago:
If you look at the number of authors vs the number of
dependencies the gap narrows but doesn't disappear. Many of the
most commonly used crates are written by members of the rust
foundation amd are used in the tools themselves. But it is always
a concern. I'm looking forward to the upcoming option to forbid
versions newer than N days at the project level. But just
manually only y updating versions when you need a new feature or
there is a cve works pretty well.
desmaraisp wrote 23 hours 28 min ago:
That's an interesting viewpoint, but one I've noticed is less
prevalent in other languages.
The c# guys at microsoft created an enormous stdlib, and the
overwhelming majority of it is pretty good. The outliers being of
course older stuff they've never really had time to upgrade. And
they don't seem to be afraid to deprecate stuff, every major
version brings a couple of minor breaking changes. But it all seems
to work out just fine somehow
CharlieDigital wrote 5 hours 34 min ago:
C# massive standard library and first party libraries means much,
much fewer external dependencies and these libraries are managed
by a team of paid, professional engineers.
Highly, highly underrated.
repelsteeltje wrote 1 day ago:
Interesting. I'm not very familiar with Go. What is the equivalent
for Tauri in Go's stdlib?
Would it make sense to continue using Go for the frontend and doing
only the backend in Rust for your user case?
tredre3 wrote 6 hours 41 min ago:
Go's stdlib has none of the things GP listed. No sqlite3, no
ratatui, no cli (though there is `flag` if it's enough for you),
and no tauri equivalent in its stdlib. Those would be go-sqlite3,
bubbletea, cli or cobra, and wails.
Charitably, I think OP meant to say that in the rust project only
four dependencies were added and that caused 400 transitive
dependencies to be pulled. Adding the four Go equivalent will still
result in 10x less packages being pulled.
It's a culture problem, Go authors prefer solutions that are self
contained, rust authors embrace the culture that gave us left-pad.
But, at least in GP's case, it's not a stdlib problem. Not one
solved by Go, anyway.
fatty_patty89 wrote 1 day ago:
wails, there's wails3-alpha which some people said is even better
than tauri
repelsteeltje wrote 1 day ago:
Thanks. Is wails a Go stdlib component, as GP implied or is it
third party?
fatty_patty89 wrote 1 day ago:
tauri isn't stdlib and neither is wails
(DIR) <- back to front page