Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Migrating from Go to Rust

corrode.dev

Post reply on HN
Print view View original

501–510 of 544 posts

Re: Migrating from Go to Rust

#501

Post by imtringued »

63stack wrote: post #233
dnautics wrote: post #108

Earlier quoted context omitted.

stacktraces? might also be useful to know whether or not the latest allocand was a jumbo sized allocand that caused the failure?

Any time I mention "but I would like stacktraces with my errors" I get told I'm doing it wrong.

No you just wrap it the way https://news.ycombinator.com/item?id=48267094 showed.

Obviously you need to explicitly include the line numbers since the error reporting Rust is closer to C (errno) than Java or JavaScript.

https://users.rust-lang.org/t/getting-line-numbers-with-as-i...

Just do what feels right. I personally am a big fan of Java stack traces.

Re: Migrating from Go to Rust

#502

Post by magicalhippo »

nirui wrote: post #500
magicalhippo wrote: post #209

Earlier quoted context omitted.

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.

Sometimes hiding internals is reasonable, but it could cause inconvenient. Exposing everything could make it harder to do interface management etc. It's really a system design problem rather than access control: if you separate functional modules in a reasonable way, then it can be better reused.

Only if you use a backwards language with non-existing namespaces. I don't see how it changes anything if you have namespaces. After all, private/protected/public are just namespaces, they are just implicit rather than explicit.

Re: Migrating from Go to Rust

#503

Post by bborud »

zero_shift wrote: post #481
bborud wrote: post #478

Earlier quoted context omitted.

How is this «optimized for Google»?

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

It seems the problem here is that they didn’t “fix” whatever you thought was “broken” and you are upset. And somehow you extrapolated that to mean that Go only follows Google’s needs.

Be a bit more precise. What exactly are you talking about and and what do you think Go does wrong and why have they chosen to do it that way?

Re: Migrating from Go to Rust

#504

Post by anonyfox »

sov wrote: post #476

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.). espe…

I use both languages and in spirit you are right, btu in my experience its more nuanced. first of all the way inline unittests in the same file is a way to have very fast cycle times in TDD too in many situations, still slower than go full compile yet much less painful than full recompile in rust. second, you typically need way less debugging cycles in rust to begin with. so its more like slower but fewer cycles.

Re: Migrating from Go to Rust

#505

Post by anonyfox »

booleandilemma wrote: post #471

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.

with web framewworks like actix or rocket itsd actually not much different to python flask or nodejs express or .... . but i am a cheap person and prefer to cram as much stuff onto my $4 DO droplets as possible, and rust brings you very far here. might be not a concern for funded startups or big enterprises, but deploying small/mid projects to essentially minimal hardware really makes my wallet happy, plus I essentially never ever had to fix runtime issues, at all, for years. and this was before LLMs were a thing, so handwritten Rust in a fullstack way, at times even WASM frontend SPAs that still kinda just work.

Re: Migrating from Go to Rust

#506

Post by mxey »

kbolino wrote: post #489
mxey wrote: post #486

Earlier quoted context omitted.

> 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.

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…

Yes, initially modules used to modify the file automatically which is why I have -mod=readonly in some old pipelines.

I think the “new” way is much better.

I still run tidy in pipelines to check but that’s only for cleanup.

Re: Migrating from Go to Rust

#507

Post by IshKebab »

wtetzner wrote: post #466
IshKebab wrote: post #249

Earlier quoted context omitted.

He was talking about the chain of function calls not crates. You still have that in your top level crate.

Except anyhow is compatible in that direction. io::Error and thiserror types will automatically convert to anyhow errors.

In my experience it's not quite as automatic as you'd hope. I always often to throw in stuff like `.map_err(Into::into)` or `Ok(foo?)` to convert the errors.

Not the end of the world but I do think defending the proliferation of error types in typical Rust projects is copium.

Re: Migrating from Go to Rust

#508

Post by LtWorf »

tptacek wrote: post #459
LtWorf wrote: post #457

Earlier quoted context omitted.

Because you don't report and open the CVE, not because it isn't a security issue :)

No security practitioner agrees with you about this. Please don't troll.

I thought DOS was a security problem. Glad to learn differently!

Re: Migrating from Go to Rust

#509

Post by HackerThemAll »

kermatt wrote: post #415
HackerThemAll wrote: post #288

The datetime to string conversions in Go are devil's spawn.

Share some examples?

The template string

"2006-01-02 15:04:05.999999999 -0700 MST"

says it all. It's a really bad joke or an excellent trolling.

The entire world have used:

%Y for the year. %m for the month. %d for the day. %H for the hour. %M for the minute. %S for the second.

for over 50 years, but Golang forces me to remember "06" for a year, "15" for an hour and "05" for second. and "MST", the Mountain View time, that particular time zone moniker, in a center of the universe, as a placeholder for a real time zone. Yes, the Mountain View, not UTC ("Z"ulu time) like a sane person would do (although nobody sane would implement that format).

Re: Migrating from Go to Rust

#510

Post by awesome_dude »

mxey wrote: post #485
awesome_dude wrote: post #450

Earlier quoted context omitted.

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.

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.

[dead]
Post reply on HN