simply put, programming is glorified automation. There are jobs where the process that needs automating makes money.

I don’t think I am well positioned to answer that question given my experience. Ill give it my best.

I believe the advantage of more abstraction of gRPC was desireable because we can point it at a socket (Unix domain or internet sockets) and communicate across different domains. I think we are shooting for a “microserves” architecture but running it on one machine. FFI (IIRC) is more low level and more about language interoperability. gRPC would allow us to prototype stuff faster in other languages (like Python or go) and optimize to rust if it became a bottleneck.

Short answer is, we are able to deliver more value, quicker, to customers (I guess). But I don’t know much about FFI. Perhaps you can offer some reasons and use cases for it?

At work, we started the c++ migration to rust doing the following:

1. Identify “subsystems” in the c++ code base
2. Identify the ingress/egress data flows into this subsystem
3. Replace those ingress/engress interfaces with grpc for data/event sharing (we have yet to profile the performance impact of passing an object over grpc, do work on it, then pass it back)
4. Start a rewrite of the subsystem. from c++ to rust
5. Swap out the two subsystems and reattach at the grpc interfaces
6. Profit in that now our code is memory safe AND decoupled

The challenge here is identifying the subsystems. If the codebase didn’t have distinct boundaries for subsystems, rewrite becomes much more difficult

hey, that’s what the internet is for; information sharing :)

for the dummies (like me) that can’t read the room, especially online, a sarcasm tag /s goes a long way 🙃

you sound like a Microsoft engineer ;)

Had a distinguished collegue (from the Bell Lab days) say to me recently:

“IDEs take up a lot of RAM on my machine. Vim takes up a lot of squishy RAM in my head. I need squishy RAM to hold info relevant to problem solving, not options available in my tool chain.”

code is just text, so code editors are text editors.

What sets IDEs apart are their features, like debugger integrations, refactoring assists, etc.

I love command line ± Vim and used solely it for a large portion of my career but that was back when you had a few big enterprise languages (C/C++, Java).

With micro services being language agnostic, I find I use a larger variety of languages. And configuring and remembering an environment for rust, go, c, python etc. is just too much mental overhead. Hard to beat JetBrain’s IDEs; now-a-days I bring my Vim navigation key bindings to my IDE instead of my IDE features to Vim. And I pay a company to work out the IDE features.

for the record, I am in the boat of, use whatever brings you the greatest joy/productivity.

This is interesting. Don’t have an opinion on it yet.

I wonder what effect this will have on developers’ code reuse practices and how it comes across in the interview.

At work I often look at my previous work for how to do boilerplate stuff. And in my recent interview experience I had more opportunities to use the internet and other examples. Very practical

I would appretiate if someone could explain the practical utility of snippets because it just dawned on me how useful they might be.

I’ve actually found his blog where he talks about this “optimistic merge”

http://hintjens.com/blog:106

There is a very effective approach (34:00), that big companies like cloudflare use, to ship a product in a fast and quality way. It bears parallels to what you are describing. In essence engineers should not get hung up in the details to trying to solve everything.

1. Just build a proof of concept
2. Discard the prototype no matter what and start from scratch keeping the initial feedback in mind
3. Build something internally that you yourself will use
4. Only once something is good enough and is used internally, then release it to beta.

So that tedious process in trying to flush out all the details before seeing a product (or open source effort) working end to end, might be premature before having the full picture.

society gains nothing by preventing a software developer from implementing …

I see the point you are trying to make but I respectfully disagree. Technology is at the core of seemingly every field and at the core of technology is software. Will it result in direct bodily harm? Rarely. But indirectly the impact is certainly more substantial.

Take internet as an example. The significance of internet and information sharing cannot be disputed. Disturptions to information sharing can send ripples through services that provide essential services. Networking these days is accomplished Vida software defined networking techniques. And we are becoming more dependant on technology and automation.

I can see why the indirect risk is not as scary as direct risk, but you have to admit, as automation is growing and decisions are being made for us, regulation of those that build these systems should not be overlooked. Professional engineers have a code of ethics they have to adhere to and if you read through it you can see the value it would bring.

As a counter example to your “doctors are licensed to not kill people” - orthodontists, who move teeth around, pose no fatal risk to their patients. Should they be exempt from being licensed?

EDIT:

Just yesterday news was published by Reuters that Musk and managers at Tesla knew about defects of autopilot but marketed otherwise. If those working on it had been licensed, then negligence and decietfulness could line them up to lose their license and prevent them from working in this line again. It would bring accountability

This is the best suggestion for DIY, I can even get away without a printer and just write by hand. Perfect! Wish I could pin this comment.

nothing wrong with being self taught, you could follow these basics topics before poking holes in firewall.

1. VLANS: learn how to separate your LAN into networks with different security requirements. For wireless, try to make a “main” and “IoT” network so that IoT network that can’t talk to your “main” network but “main” can reach IoT devices. For wired, try to have a Management network, and a “Dirty network” etc.
2. Firewalls and Routing: You will need to be able to route between your VLANS and set firewall rules to allow certain traffic. Best practice is block everything and allow only what you need.
3. NMAP: learn how to do NMAP scans of your network to discover hosts and their open ports/services. This is a similar approach that “hackers” and script kiddies use on the public internet to find vulnerae and open services. Being able to probe your own network is crutial in understanding how others might approach in penetrating it.
4. Wireguard VPN: Learn to access your network remotely by setting up a wireguard VPN. Wireguard is preferred because it is “stealthy” and will not respond to unsolicited attempted to probe your network. Start small by using wireguard to access between VLANs so you don’t run the risk of using the internet.
5. NGINX and Reverse Proxy: If necessary, learn to expose your services or blog or website by only exposing nginx and proxying to your services. Many guides on securing NGINX exist. Try not to expose anything, but sometimes necessary if you want others to reach your website/blog/hosting etc.

That’s a rough outline that you can use to guide yourself and achieve milestones with hands on experience. In your pursuit you’ll run into certificates and domain name hosting and stuff. But all this is on the web so let your curiosity (and paranoia) drive! Have fun!!

The table of contents hints there is only one section relevant to security, Lab Firewall Config.

Anyone have experience with this book that could vouch for other chapters that explore best practices for security?

good question. Software and computer practices are changing much faster than other fields but with time, pillars are being better and better defined. Production quality code, CI/CD, DevOps, etc…

Civil engieers have a successful licensure process established. See my comment regarding that.

But an approach where a candidate would spend time under a “licensed professional software eng” would favor practical work experience over academic.

the trades is a great example of having to work under a professional. Other engineering disciplines also have successful licensure processes. See my comment regarding that.

There are parallels to be drawn between licensed professionals (like doctors, CPAs, lawyers, civil engineers) that they all have time under a professional and the professional then signs off and bears some responsibility vouching for a trainee.

I think it’s important to check for competencies that are valuable to the employer during the interview process. However many, but admittingly not all, employers will use time constrained college level puzzels that a candidate can usually only solve if they have seen it before.

I’ve been on both sides of the interview process. In my day to day I use a debugger to verify and step through code all the time. Hacker rank, the leading platform to test candidates and generate a metric report, doesn’t even have a debugger. Off-by-one index mistakes are sooo common to see from a candidate who is under time pressure. A few iterations with a debugger and problem solved. I advocate for candidates to develop on their on env and share their screen or bring it with them. But anyway, I’m ranting.

I agree with most comments arguing against a standardization and pointing to the weakness. I didn’t say it works great, I just wish it was like some other professionals have. See my comment about other engineering disciplines that have a successful licensure process.

I agree with what you said, it is a shit show. but I wish it weren’t so.

My good friend is a civil engineer and for him to obtain a Professional Engineer license (PE) he had to complete a four-year college degree, work under a PE licensed engineer for at least four years, pass two intensive competency exams and earn a license from their state’s licensure board. Then, to retain their licenses, PEs must continually maintain and improve their skills throughout their careers.

This licencing approach is prohibitive to just “pay your way” through. This never caught on in software and computer eng because of how quickly it was (and still is) changing. But certain pillars are becoming better defined such as CI/CD, production-safe code & practices, DevOps.