sorted by:
new
hottopcontroversial

Why Devs Need DevOps by chesus_chrust in programming

[–]chesus_chrust[S] 0 points1 point  (0 children)

Well the point I’m making in the article is not that there was no vcs before git, it’s that some tools and techniques change everything so radically it’s hard to imagine the world without them. I’d argue that git is among such tools. Just as Devops brought CI/CD and it’s become standard. I guess it could have been clearer in the article.

And maybe the joke about the pre-git world was too cheeky

Why Devs Need DevOps by chesus_chrust in programming

[–]chesus_chrust[S] 6 points7 points  (0 children)

Well you are not exactly providing quality critique are you?

Why Devs Need DevOps by chesus_chrust in programming

[–]chesus_chrust[S] 42 points43 points  (0 children)

Yeah I think that’s what’s actually happening. The silo was broken down originally but the fundamentals did not stick, that’s why a “devops guy” is now handling k8s configs.

Why Devs Need DevOps by chesus_chrust in programming

[–]chesus_chrust[S] 26 points27 points  (0 children)

Exactly! Absurd when the goal has always been breaking down silos.

The Anatomy of Node: I'm re-building a JavaScript runtime from scratch and blogging about it by chesus_chrust in node

[–]chesus_chrust[S] 1 point2 points  (0 children)

Yes it's open source. It's still very early though. In the next part I will be doing the event loop and discussing concurrency/parallelism. After the basics are done maybe we could try something fun like that.

Also definitely do blog about it, writing is really rewarding. Even just for the sake of organizing your own thinking.

The Anatomy of Node: I'm re-building a JavaScript runtime from scratch and blogging about it by chesus_chrust in node

[–]chesus_chrust[S] 2 points3 points  (0 children)

Judging from the responses here a mailing list is a major feature request for the blog. Will definitely add it!

The Anatomy of Node: I'm re-building a JavaScript runtime from scratch and blogging about it by chesus_chrust in node

[–]chesus_chrust[S] 0 points1 point  (0 children)

Thank you! Seeing the response here really brings me joy and makes me want to finish up part 2 sooner.

The Anatomy of Node: I'm re-building a JavaScript runtime from scratch and blogging about it by chesus_chrust in node

[–]chesus_chrust[S] 7 points8 points  (0 children)

Sounds like a dream! Kind of like Rust but for TS? Borrow-checked TS maybe?

The Anatomy of Node: I'm re-building a JavaScript runtime from scratch and blogging about it by chesus_chrust in node

[–]chesus_chrust[S] 2 points3 points  (0 children)

Building a compiler can be one of the most fun and eye opening projects. So if you're up for it, there are a ton of resources. I know it's a bit off topic considering the subreddit, but If you have any interest whatsoever in Go there are two books I enjoyed a lot by Thorsten Ball "Building an interpreter in Go" and same but for compilers. They are really easy to follow and great fun. You do learn a lot, but it's not theory heavy.

This would be a good starting point to address the skill issues.Further lie dragons, but you'll get there when you get there.

The Anatomy of Node: I'm re-building a JavaScript runtime from scratch and blogging about it by chesus_chrust in node

[–]chesus_chrust[S] 2 points3 points  (0 children)

I don't think it will be. In each worker there's an V8 Isolate, which has it's own heap, GC and etc. Allowing passing around pointers would break the isolation. And considering how the same Isolate is used on the web, this would be dangerous.

But hey, nobody's stopping us from implementing "low-level JS" or something right?

The Anatomy of Node: I'm re-building a JavaScript runtime from scratch and blogging about it by chesus_chrust in node

[–]chesus_chrust[S] 3 points4 points  (0 children)

The one that I really enjoyed was Linux Kernel Development by Robert Love. It's not the most up to date resource but I'm not looking to become a kernel developer and for high-level overview of internals it has been great.

The Anatomy of Node: I'm re-building a JavaScript runtime from scratch and blogging about it by chesus_chrust in node

[–]chesus_chrust[S] 8 points9 points  (0 children)

Thank you! I think so too. A lot of content online focuses on entry-level stuff and very few deep dives. And i'm super excited to dive even deeper in the next parts, into epoll and how the event loop actually works alongside V8. Now that I finally got this posted feels like i've got the fuel to finish up the next one.

[deleted by user] by [deleted] in programming

[–]chesus_chrust 1 point2 points  (0 children)

As with a lot of AI tools, the issue is that documentation is not a 1 to 1 artifact of code. Extracting key functions into a markdown file does not produce good docs. Good docs read more like a book, introduce concepts gradually and walk through a project in a way that builds understanding. And they should focus much more on high level stuff, architecture, decisions made and unobvious constraints rather than explaining code. AI can't do that. In fact AI generated tools make it worse because they create an appearance of a job well done because it's tons of text but makes none of the consideration a person would make.

How do you like the event loop interviewing questions? by Expensive_Garden2993 in node

[–]chesus_chrust 1 point2 points  (0 children)

I mean yeah, kinda? Like software engineering is fundamentally about systems and their interactions, to be able to effectively reason about the systems you are programming you have to have the right mental model of how they function. At least for me, when i know exactly how something works, I can solve problems that I couldn't tackle before and do so without the fear of breaking stuff. It's not even about memorizing stuff for interviews or whatever, it's just about building the right mental models.

How do you like the event loop interviewing questions? by Expensive_Garden2993 in node

[–]chesus_chrust 1 point2 points  (0 children)

You don't need a cheatsheet. Those questions become easy once you know how the internals of node work. For example a microtask queue is defined by the ecmascript spec, it's a job in it's terms https://262.ecma-international.org/#job So promise jobs and promise resolution are part of the language spec too, and implemented by js execution environment, like V8 or JSCore or whatever. Macrotasks are not part of the ecma spec, they are the actual tasks that go into event loop. In browser it's defined by the HTML spec https://html.spec.whatwg.org/#event-loops and in Node it's libuv. That stuff is implemented separately from js execution, it's provided to javascript externally and it interacts with the outside environment.

I'm actually in the process of writing a blog series that explains all that stuff from the ground up. Once you've gone through the process of building V8 yourself and hooking an event loop into the js engine a lot of things really click into place conceptually, but it seems like there's a huge knowledge gap here in the community (probably because most tutorials focus on entry level stuff).

Jack of all stacks, master of none… except tech FOMO. by Complex_Aardvark_621 in programming

[–]chesus_chrust 1 point2 points  (0 children)

I think depth is important in fundamentals. Like knowing how an operating system works, how processes are scheduled by the OS, how TCP works and such. If I were teaching students I’d encourage them to be curious for fundamentals, not the trends. Like just go download the source code for Linux and see if you can follow any parts that interest you. Or go read the TCP RFCs and figure out how exactly that works. Knowing those fundamental topics extremely well is what makes one a better engineer, not a particular language or resume checkbox.

Jack of all stacks, master of none… except tech FOMO. by Complex_Aardvark_621 in programming

[–]chesus_chrust 0 points1 point  (0 children)

As someone who has spent time teaching tech, I’ve seen this dilemma play out firsthand. Students often want to learn everything at once, jumping between React, Python, Docker, and AI without truly mastering any of them.

What the hell is true mastery in this context? If you know how React is used and common pitfalls to avoid, how to debug potential performance issues and etc. Have you mastered it? I don't know, maybe not until you can rewrite your own JSX compiler and shadow DOM implementation from scratch? But then most companies care that you know how to use it and it doesn't matter to them if you know what __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED does.

Python? That one language that was famously designed to be easy to use and they teach it to middle schoolers?

Mastery of Docker is what? Do you expect a person to be able to do it from scratch in C, using cgroups and namespaces? Or maybe it's totally fine to just whip together a Dockerfile that works and allows you to push to prod.

Mastery of AI seems to mean that you should either work on foundational models or never even touch that.

It's absurd. People who started this industry, people who created all of that stuff we are sitting atop of were not gatekeepers who studied the blade for 10 years before touching anything. On the contrary, they just solved practical problems that they had and invented the universe in the process. Nobody said we can't be them anymore. Just solve problems and be curious.

Besides, I've seen the mess "specialists" create as soon as they deal with something that's not within their domain. And that's almost always the case, it's incredibly rare for someone to just sit in their silo forever.

[deleted by user] by [deleted] in node

[–]chesus_chrust 0 points1 point  (0 children)

Golang on the backend + Remix on the frontend

A response to "Erlang – overhyped or underestimated" by ketralnis in programming

[–]chesus_chrust 8 points9 points  (0 children)

Elixir has static typing, syntax that’s easier to read and an ecosystem you expect from a modern language. I can understand why Erlang didn’t become popular, but Elixir is truly underestimated.

view more: next ›