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

531–540 of 544 posts

Re: Migrating from Go to Rust

#531

Post by tptacek »

iknowstuff wrote: post #530
tptacek wrote: post #70

Earlier quoted context omitted.

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.

I’m sorry but this is simply incorrect and I think stems from insufficient understanding of best practices and/or how the Error trait composes, as the other replies alluded to. There’s a lot of reading material on the subject but unfortunately I can’t recommend anything off the top of my head

You get how that last sentence is extremely funny given the first sentence, right?

Re: Migrating from Go to Rust

#532

Post by antonvs »

bottlepalm wrote: post #236
Certhas wrote: post #214

Earlier quoted context omitted.

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.

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.

If the program design follows the principle of making illegal states unrepresentable (credit to Yaron Minsky), the compiler can catch much, much more than most people realize.

The process of designing a program like that itself catches a lot of "badly designed code". And such a design also naturally exposes many kinds of intentional backdoors, because security properties can quite easily be statically checked. For example, IDORs can be made literally impossible in such a design.

In discussions like this, I'm reminded of the William Gibson quote, "the future is already here, it's just unevenly distributed."

Re: Migrating from Go to Rust

#533

Post by 63stack »

dwattttt wrote: post #526
63stack wrote: post #512

Earlier quoted context omitted.

I see a very opinionated explanation, not a "this is why the language does not" explanation. >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. This is a personal opinion, not something you can declare as the objective tr…

I'm curious, what's the value of a stack trace of another person's library functions? As mentioned, you can get a stack trace that includes all of your code, that's what was offered to you. The only thing a library gathering a stack trace instead of you gives you is that it includes traces through code you didn't write & ostensibly aren't responsible for. If you're going to go to the effort of tracing through a depen…

Ideally (in my ideal world), it would be Result that holds the backtrace. The value is that I don't know up front which method call is going to cause an error that is hard to track down, which is why I don't see how "instrument your calls with backtrace yourself" helps. It requires that I already have some idea about the execution path, otherwise I don't know where to put the backtrace instrumentation.

Since Backtrace::capture() is already tied to an env var, we could have the backtrace on Result without affecting performance, since you would only enable it for debugging. This would allow you to eg. easily track down a situation where you see in your prod logs that you are encountering a lot of "validation error: string is too long" but you can't tell where it is coming from. Flip the env var, redeploy the application, read the backtrace, turn off the env var, fix the problem.

Re: Migrating from Go to Rust

#534

Post by awesome_dude »

andrewflnr wrote: post #528
awesome_dude wrote: post #524

Earlier quoted context omitted.

I explictly say that NO dependency management is without problems, AND call out Go's attempts in my OP. You came barrelling because your favorite tool is mentioned, and then, when you realize that it deserves the criticism you try and play that? Maybe, just maybe, take an objective look at the real problem (dependency management) and recognise that, as stated, nobody has solved it.

I was trying to be sympathetic and acknowledge virtualenv's potential flaws, actually, even though I haven't personally encountered them, but I guess that was a waste of time.

Which part of this is sympathetic?

> This is unrealistic. You seem to have moved to Go as an alternative, but I know because I've seen the complaints that Go doesn't satisfy that standard either.

It's a dig - you completely ignore the valid complaints about Python to instead focus on what you think will provoke me.

The problem (for you) was, from the very start, I bought up the pain points with Go.

Re: Migrating from Go to Rust

#535

Post by dwattttt »

63stack wrote: post #533
dwattttt wrote: post #526

Earlier quoted context omitted.

I'm curious, what's the value of a stack trace of another person's library functions? As mentioned, you can get a stack trace that includes all of your code, that's what was offered to you. The only thing a library gathering a stack trace instead of you gives you is that it includes traces through code you didn't write & ostensibly aren't responsible for. If you're going to go to the effort of tracing through a depen…

Ideally (in my ideal world), it would be Result that holds the backtrace. The value is that I don't know up front which method call is going to cause an error that is hard to track down, which is why I don't see how "instrument your calls with backtrace yourself" helps. It requires that I already have some idea about the execution path, otherwise I don't know where to put the backtrace instrumentation. Since Backtrac…

> track down a situation where you see in your prod logs that you are encountering a lot of "validation error: string is too long" but you can't tell where it is coming from.

Capturing a stack trace is a hefty operation: making it happen on _every_ error creation, which would include creating an error in response to another error (like causing ) could easily grind a production server to a halt. Especially if there's correctly handled errors happening: every one of them will pay this cost, every time.

It sounds like a really specific problem here; the log line that's happening is generic enough that it doesn't identify which line of code is emitting the log, so you can't just add `capture` to that line (what logging system even does this? printf logging?).

Re: Migrating from Go to Rust

#536

Post by 63stack »

dwattttt wrote: post #535
63stack wrote: post #533

Earlier quoted context omitted.

Ideally (in my ideal world), it would be Result that holds the backtrace. The value is that I don't know up front which method call is going to cause an error that is hard to track down, which is why I don't see how "instrument your calls with backtrace yourself" helps. It requires that I already have some idea about the execution path, otherwise I don't know where to put the backtrace instrumentation. Since Backtrac…

> track down a situation where you see in your prod logs that you are encountering a lot of "validation error: string is too long" but you can't tell where it is coming from. Capturing a stack trace is a hefty operation: making it happen on _every_ error creation, which would include creating an error in response to another error (like causing ) could easily grind a production server to a halt. Especially if there's…

I feel like we are talking past each other, because you ignored the whole part about "it is already tied to an env var, and it would be still tied to an env var" that you would only enable on demand, so who cares if it's a hefty operation? Also what about other languages that capture stacktraces all the time with exceptions, or scripting languages with type errors, where you can't even turn it off? Rust is somehow different?

It is a specific problem, so what? You see that you are sending 500 from an axum handler, and you are logging "serde deserialization error: line 4 invalid", wouldn't it be nice to see where that came from, without instrumenting all the places you are deserializing something?

Re: Migrating from Go to Rust

#537

Post by dwattttt »

63stack wrote: post #536
dwattttt wrote: post #535

Earlier quoted context omitted.

> track down a situation where you see in your prod logs that you are encountering a lot of "validation error: string is too long" but you can't tell where it is coming from. Capturing a stack trace is a hefty operation: making it happen on _every_ error creation, which would include creating an error in response to another error (like causing ) could easily grind a production server to a halt. Especially if there's…

I feel like we are talking past each other, because you ignored the whole part about "it is already tied to an env var, and it would be still tied to an env var" that you would only enable on demand, so who cares if it's a hefty operation? Also what about other languages that capture stacktraces all the time with exceptions, or scripting languages with type errors, where you can't even turn it off? Rust is somehow di…

I can't reconcile what you're asking for with the situation you're describing. If every single error everywhere in the program created a stack trace and logged it at creation time, your error would be lost under an avalanche of benign errors that are handled. And if you only want to selectively log _that_ error that's interesting, you need to selectively modify the place that logs it, which you don't want to do (because you don't want to have to find it).

It sounds like what you want is the errors you log to always log stack traces. Which is a fine position, I do something like that. It's just not something that can be the default, because it can't be done everywhere.

Re: Migrating from Go to Rust

#538

Post by iknowstuff »

tptacek wrote: post #531
iknowstuff wrote: post #530

Earlier quoted context omitted.

I’m sorry but this is simply incorrect and I think stems from insufficient understanding of best practices and/or how the Error trait composes, as the other replies alluded to. There’s a lot of reading material on the subject but unfortunately I can’t recommend anything off the top of my head

You get how that last sentence is extremely funny given the first sentence, right?

No. Why, did you feel attacked

Re: Migrating from Go to Rust

#539

Post by tptacek »

iknowstuff wrote: post #538
tptacek wrote: post #531

Earlier quoted context omitted.

You get how that last sentence is extremely funny given the first sentence, right?

No. Why, did you feel attacked

How it reads to me: "This is easy. No problem! There's reams of pages written about it, because it's easy, which is always why whole treatises get written about stuff. I can't think of the best to recommend right now, not because the topic is nuanced and there's no best one and you probably have to read many different things to determine whether to e.g. reinvent pointers as integer indexes into arrays, but don't take from any of this the idea that any part of this is complicated. Noooo!"

I mean, you said it way more concisely than I did. Good on you!

Re: Migrating from Go to Rust

#540

Post by iknowstuff »

tptacek wrote: post #539
iknowstuff wrote: post #538

Earlier quoted context omitted.

No. Why, did you feel attacked

How it reads to me: "This is easy. No problem! There's reams of pages written about it, because it's easy, which is always why whole treatises get written about stuff. I can't think of the best to recommend right now, not because the topic is nuanced and there's no best one and you probably have to read many different things to determine whether to e.g. reinvent pointers as integer indexes into arrays, but don't take…

I was not asserting it was easy nor trying to attack you. Merely recommending you find reading material because your understanding is lacking. You’ll probably find it scratching an itch when you realize how nicely it all composes together.

Though I have little hope for that after your little drive-by at memory safety further showcasing you’re way out of your depth

Post reply on HN