bitfield's comments

> Go is more likely to get the job done, Rust is more likely to do the job well

That's surprisingly close to what one of my contributors wrote in the piece:

> My take: Go for the code that has to ship tomorrow, Rust for the code that has to keep running untouched for the next five years.

Not sure what you mean by 'folklore' in this context. There's a lot of discussion in the piece about memory safety, garbage collection, build performance, and so forth. Don't you think that's engineering, or at least engineering-adjacent?

Me too! You'll have noticed that that's exactly the structure of my article: which problems is Rust a better choice for, and which problems suit Go. It's intended to help people just like you, who want to pick a tool based on the problem they're trying to solve, rather than tribalism.

Could you provide a screenshot showing what you mean?

Well, no one is claiming that it's impossible to write Rust or Go programs that have security vulnerabilities—that would be a very silly thing to claim, wouldn't it?

A more useful way to think about it might be to ask whether such languages make vulnerabilities less likely, and for certain types of vulnerability (buffer overflows, for example), they absolutely do.

Well, the problem with that is that not everyone would agree on that way of classifying languages _either_! And people do want to know what the differences are between Go and Rust, as they're so often mentioned in the same breath. I think the comparison is valid (whether you agree with it is another question).

Well, the point is that which language you choose depends on what you want to do with it, and it's impossible to say objectively that one language is "better" than another. If you ask me which one I _like_ more, that's a totally different question, but no one cares what the answer is.

This depends on the context, though. In my open source projects, I have many contributors, so it's important to maintain a consistent style throughout (for example, naming conventions, so that the same data is always called the same thing).

A commercial software project will also have a 'house style' which all contributors are required to follow. It's okay to withhold approval on this basis.

What I think you're saying, and I agree with it, is "don't withhold approval just because this isn't your style".

You could try https://github.com/bitfield/ftl-fundamentals

I already know... what?

That's a very good point, especially in view of https://bitfieldconsulting.com/blog/container-security

I'll make that change, thanks for the suggestion.

Worth noting that the Go team are currently considering a square-bracket syntax for type parameters, instead of the parentheses shown in this tutorial.

"I want off Mr Rust's wild ride."

Without the app, he has no business. I'd say you're in a strong position to ask for at least half the shares (not options). If you don't get them, take your app and sell it elsewhere.

Well, speaking personally, it's very helpful if the mentee is willing to say things like "I don't understand that, please explain it in a different way." Often I think people just keep quiet, out of shyness or politeness, or not wanting to appear dumb. But the moment you've lost the thread of what's happening, you're both just wasting your time.

A good mentor can pick this up, and is constantly checking to see if the mentee is really understanding, or whether they're just saying "Uh-huh". But it's a two-way process. Sometimes you will genuinely struggle to get something, and that's okay—everybody finds different things easy or difficult. If this is happening, just say "Sorry, I'm having trouble with this. Can you go through it again?" The mentor absolutely won't mind doing this. They're not here to look smart, they're here to help you learn something, and until that's happened, they haven't done their job. [If they do mind, get another mentor.]

Mentor here teaching Go and cloud native tech (https://bitfieldconsulting.com/golang)

In general, I think it's worth taking a bit of time to establish exactly what it is you expect to get from mentoring, and how you and the mentor are going to work together to achieve that. For example, if you want to get and pass the interview for your dream job, that's an objective you can both work towards. Or maybe your goal is just something "feel confident writing non-trivial Go projects from scratch". You can then agree a plan of action that gets you there.

Next, establish how you're going to work together. A regular meeting is probably best, whether that's in person or by remote. Find a time that works for both of you. If you're working on a real-life project, as opposed to an exercise, will both you and the mentor contribute to it individually, as well as pairing on it together? Or will the mentor just be giving you code reviews? Will the mentor give you homework, exercises, and reading to do in between sessions? If so, agree what the expectations are. Don't assume you will have any free time at all to work on this stuff—most don't!

Finally, and this may seem obvious, as the mentee, this process is not always going to be easy for you. You are basically surrendering yourself to someone else (possibly a stranger) and saying "You know better than me. Please teach me." If you're an engineer, for example, that probably doesn't come naturally to you. It doesn't to me.

When you find yourself feeling frustrated, as you may well do, or even angry, try to keep calm. If the mentor's advice seems to make no sense to you, ask them to explain, and keep asking until you understand it. If you understand it, but don't agree with it, don't argue; this is tiresome for both parties. Default to assuming the mentor is right and you are wrong. After all, you're here because they know more than you do. This is bound to mean that some of the things you think you know are actually wrong, isn't it?

Author of the post here. I'd love to hear if you're using a website monitoring tool with Prometheus and Grafana, and if so, what you're doing with it! I've written about some ideas which seem useful to me, but I'd welcome additional suggestions.