wasted_intel

Amp, and convention over configuration in general, don't prevent configuration, they just try to avoid it. There are a bunch of things you can configure in Amp, if you'd like: https://amp.rs/docs/#configuration

Author of amp here and I couldn't have explained this any better.

These are great; thanks for the insight!

Can you provide specific examples of things that you found the most useful when you finally had a full-time/non-coding manager? Having somewhat recently transitioned into an engineering management role, I'm curious if there's anything (or situation) in particular you'd highlight.

Thank you for all of the hard work you've put into this. i3/sway are what I love most about my Linux desktop!

I've found mkdocs to be fantastic for this, especially when paired with its material theme:

https://www.mkdocs.org/

https://github.com/squidfunk/mkdocs-material

There's a docker image that makes getting started with both quite easy:

https://squidfunk.github.io/mkdocs-material/getting-started/...

You should! I used Go on a sizeable side project, and while I did enjoy it, I much prefer Rust. There's no doubt that Rust is harder to learn, but not pointlessly so; it's a learning exercise, especially if it's your first foray into low-level systems programming. Be patient, the payoff is worth the investment!

I'm happy that error handling landed in first place; I feel the same way. Rust is the first language I've used with ADTs, and they're incredibly expressive. It allows the error system to be a set of idioms built atop an expressive type system (okay, so the ? operator does add a little sugar), rather than a discrete language feature, like with exceptions. It brings error handling to the forefront, and it's a big reason why people tend to say "if it compiles, it works" when talking about Rust.

A Project Sputnik laptop from Dell with Ubuntu pre-loaded is a safe bet. I'd personally opt for an XPS 13" Developer Edition, even if I were going to load another distro like Arch Linux. Project Sputnik's objective is to ensure Linux compatibility, which involves picking components that are compatible out of the box, and submitting upstream patches for those that aren't.

It does help that it's also the laptop that Linus is using: https://www.cio.com/article/3119876/linux/linus-torvalds-pic...

I've been running a two-disk RAID1 setup, alongside a single disk root drive (for snapshots) for almost two years without a single issue. I think there's still a lot of FUD being spread on account of the RAID 5/6 write hole still existing, for which this is the latest update:

> The write hole is the last missing part, preliminary patches have been posted but needed to be reworked.

> the market has more Java or PHP engineers

That's a quantity over quality argument. Assuming there isn't an extreme shortage, I'd opt for a language and/or framework that tends to attract higher quality candidates. Personally, Ruby/Rails feels like it hits the sweet spot there.

Yep. The site is responsive, and it was tricky to fit something properly onto a smaller width device. :)

Thanks for the suggestion! I'll likely do a short screencast over the weekend to provide an overview and explain some of the features.

You can also opt to skip handling these edge cases by either copying (decreasing performance) or unwrapping (decreasing reliability). The great thing is that Rust gives you the choice.

Is there the possibility of adopting this with an explicit caveat that the details are subject to change? I would have found it incredibly useful when first learning about these types; feels like a missed opportunity.

Coming from a Ruby background, keeping your language versions independent from your OS package manager is really useful. There are situations where having different versions running alongside one-another is really handy, or not having to wait for your distro to include support for the version you require.

Agreed that it looks like re-inventing the wheel from the outside; rest assured, it's useful!

Let’s keep in mind that software running in a browser is sandboxed, using standardized APIs, and isn’t nearly as privileged as software running directly on your desktop.

Ruby’s beautiful object model alone is worth learning. “Metaprogramming Ruby”[0] is a great introduction to that. Its flexibility is what makes things like DSLs so easy. The language also includes functional programming influences. I wrote Django apps in Python for the better part of two years, and for what anecdotes are worth, I didn’t learn nearly as much as I did writing Rails applications in Ruby. I’d pick Ruby every time.

[0] https://pragprog.com/book/ppmetr/metaprogramming-ruby

How can that possibly be a downside? If they had made money, people would be even more up in arms. If anything, this reinforces the “Easter egg” intent of the extension; it serves no other purpose.

Keeping logic in the database like that means you can’t version those procedures alongside the rest of your code. That’s a pretty big downside.

Data structures (vectors, hashmaps, trees), I/O, etc. are all part of the stdlib, and their rich feature sets make an API reference essential. You can certainly write Rust without it, but you’d be missing out on a lot of useful functionality.

That's frustrating to hear. I've stuck to the #rust[1] channel and have always received friendly answers whenever I've gotten stuck, and I've had a lot of questions over the past 3 years. :)

[1] https://chat.mibbit.com/?server=irc.mozilla.org&channel=%23r...

> Not relying on API search much has the huge advantage of not relying on external APIs, which leads to good modularization. As a general rule, a module shouldn't call into other modules much.

When writing Rust, you'll likely use the standard library a lot; this rule might not be as applicable as in other languages/environments.

Nice tip, thanks!

I use a backtick as well. Although rare, if I'm writing a Markdown doc and want to use inline pre-formatted blocks, it's a pain to work around, but otherwise, it's been great.

I just wish I could opt out of the management engine. ;)

You can vendor dependencies if being reliant on a package service is too unreliable.

Yep, it's surprising how hard it is to avoid. Compound that with sugar being in almost everything and it ends up being remarkably hard to find options that won't cause your blood sugar level to spike.

So, you're advocating removing the "make compiler happy" step and you think that will lead to greater discipline?

If the tool automatically fixed it, you'd have a point, but most if not all of the static analysis tools I've come across simply point to the error and leave it up to the developer to fix, which is the right thing to do, reinforcing good habits.

This unfortunately doesn't work well in a "first past the post" voting system, as a more general party will typically overpower a split opposition.