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

511–520 of 544 posts

Re: Migrating from Go to Rust

#511

Post by awesome_dude »

andrewflnr wrote: post #480
awesome_dude wrote: post #449

Earlier quoted context omitted.

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 di…

> 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 rea…

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

Zero. The required number of problems needs to be zero - hence my OP

> I guess if you have a hard dependency on a particular version of python, it's going to be harder, but... why?

The bigger question is - why doesn't 3.9 compile and run 3.8

Further, in what world is targeting a specific runtime version in an enterprise production environment "niche"?

When you are deploying to managed corporate infrastructure, AWS Lambda runtimes, or strict Docker base images, you don't just get to loosely target "whatever Python version happens to be on the developer's laptop." You target an exact runtime version (e.g., Python 3.10) because language syntax, standard library features, and performance characteristics change between minor releases.

The fact that Python forces the developer to manually manage isolated directory symlinks (venvs) just to prevent local environment contamination — and that minor runtime mismatches can completely derail a standard onboarding experience — is a structural UX failure.

Re: Migrating from Go to Rust

#512

Post by 63stack »

wtetzner wrote: post #472
63stack wrote: post #351

Earlier quoted context omitted.

See? You get people explaining to you that you actually don't want a stack trace because xyz.

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.

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 truth. There is a lot of value in seeing what path the program took before it encountered a eg. validation error.

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

This is wrong because it's up to the library to attach the stacktrace, not the userland code using the library, so saying "you can get them if you want them" is not true. If the author of the library did not decide to attach the stacktrace, your only option is wrapping it yourself, which you can only do if you already know up front all the paths that can fail. Also, you are not supposed to expose errors from a library with anyhow, they are only for application/top level code.

Re: Migrating from Go to Rust

#513

Post by zero_shift »

bborud wrote: post #503
zero_shift wrote: post #481

Earlier quoted context omitted.

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?

Your tone seems hostile. I'm not obliged to answer you.

Re: Migrating from Go to Rust

#514

Post by tptacek »

LtWorf wrote: post #508
tptacek wrote: post #459

Earlier quoted context omitted.

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

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

Now your argument has become that only Go programs ever terminate unexpectedly. You can see why I've lost patience here.

Re: Migrating from Go to Rust

#515

Post by Orygin »

hota_mazi wrote: post #383
marcus_holmes wrote: post #138

Earlier quoted context omitted.

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 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 r…

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

ORMs considered harmful even for other programming languages/ecosystems

Re: Migrating from Go to Rust

#516

Post by bborud »

zero_shift wrote: post #513
bborud wrote: post #503

Earlier quoted context omitted.

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?

Your tone seems hostile. I'm not obliged to answer you.

[dead]

Re: Migrating from Go to Rust

#517

Post by iknowstuff »

dwattttt wrote: post #199
awesome_dude wrote: post #157

Earlier quoted context omitted.

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…

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.

tracing_error is a nice option if you already have the tracing context.

snafu makes it easy to attach structured context to an error

Re: Migrating from Go to Rust

#518

Post by bborud »

tptacek wrote: post #462
Hendrikto wrote: post #453

Earlier quoted context omitted.

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…

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.

I think I agree, but I am not sure I understand what "the means to do it well" actually means. I would think of it more as a community decision: let's focus efforts on doing X well in the standard library since X is important and people shouldn't have to ask "ok, so which third party library is the best choice right now".

Let me be the first to point out that this is not an easy thing to do since it depends heavily on the community/team/maintainer dynamics. Even agreeing on the goal or scope can be really hard. But if the Rust community is as good as people say it is, that should be doable, right?

On the other hand it wouldn't have to be definitive and exhaustive. Just a safe default. Like http muxers in Go: the one that came with the standard library was fine for a lot of uses, but people generally used third party muxers. I certainly did. And then one of the most used third party ones became shaky as it was no longer being maintained (now it is again, I think). Eventually the one in Go was improved to where I'd prefer to use that since it represents a "safe default" (and I am probably not going to need whatever extra features or performance third parties can provide).

Also note that I see myself first and foremost as an _engineer_. I care less about purity in theory than what things mean in practical terms. And in practical terms I appreciate Go for having so much useful stuff in the standard library. Stuff I kind of think we should take for granted in any serious language today.

Re: Migrating from Go to Rust

#519

Post by andrewflnr »

awesome_dude wrote: post #511
andrewflnr wrote: post #480

Earlier quoted context omitted.

> 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 rea…

> 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. Zero. The required number of problems needs to be zero - hence my OP > I guess if you have a hard dependency on a particular version of python, it's going to be harder, but... why? The bigger question is - why doesn't 3.9 compile and run 3.8 Further, in what world is targeti…

> Zero. The required number of problems needs to be zero - hence my OP

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.

Re: Migrating from Go to Rust

#520

Post by tracker1 »

hota_mazi wrote: post #383
marcus_holmes wrote: post #138

Earlier quoted context omitted.

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 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 r…

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

I think it's contextual... IMO IoC/DI in JavaScript/TypeScript is evil, because there's a built in reference system and it's easy enough to override in testing frameworks already, so IoC/DI has much less real value and is more likely to cause harm than help.

I would say that ORMs are often similar, in that depending on the environment and Object Mapper is more than enough for most use cases, again in my opinion.

Post reply on HN