For a DDR3-era machine, you'd be buying RAM for that on Ebay, not Newegg.
I have an industrial Mini-ITX motherboard of similar vintage that I use with an i5-4570 as my Unraid machine. It doesn't natively support NVMe, but I was able to get a dual-m2 expansion card with its own splitter (no motherboard bifurcation required) and that let me get a pretty modern-feeling setup with nice fast cache disks.
Is groovy actually really "adopted" much of anywhere? I feel like for 99% of normal people, their only real exposure to it is as the DSL of gradle and jenkins.
I can't imagine writing anything of substance primarily in groovy.
Rundeck uses it for its plugins. It might be like how people use lua for their main program's dynamic scripting except they know Java so they use groovy.
Have to agree with the previous person. Never saw a relevant project made from Groovy. Even with Beanshell I've included it a few times in other projects for basic scripting/customization within the app but groovy? Never in 15 years to now.
I think embedding and testing/plugins/DSLs really is the main use-case. It's a terrible fit for a CLI tool if you've got to wait for a JVM to boot up, especially in a world where people are now used to those kinds of things being instantaneous rust or go binaries.
Likely a case where Google figured out which one you meant through the telemetry of what you clicked on and how you refined your search, now that personalization is automatic. In my case, I get four regular results, which are the financial standard, the programming language, the wikipedia page for the programming language, and an ISP; then I get a "top stories" block that is all about the singer.
More tricky for the sibling comment with Rust, where either one could be valid.
That sounds like fascinating work, but also kind of a case study in what a manager's role is to "clear the road" and handle the lion's share of that internal advocacy and politicking so that ICs don't have to deal with it.
My understanding is that optimizing for sequential read is a big reason for historical game install bloat; if you include the common assets multiple times in the archive, then loading a level/zone becomes one big continuous slurp rather than jumping all over the place to pick up the stuff that's common to everything. Obviously this didn't matter with optical media where the user wasn't impacted, but it's annoying on PC where we've had a long period of users who invested in expensive, high-performance storage having to use more of it than needed due to optimizations geared at legacy players still on spinning rust.
I expect that low-latency seek time is also pretty key to making stuff like nanite work, where all the LODs for a single object are mixed together and you need to be able to quickly pick off the disk the parts that are needed for the current draw task.
Google was especially well positioned to catch up because they have a lot of the hardware and expertise and they have a captive audience in gsuite and at google.com.
I noticed this recently when I asked it whether I should play Indiana Jones on my PS5 or PC with a 9070 XT. It assumed I had made a typo until I clarified, then it went off to the internet and came back telling me what a sick rig I have.
IMO teachability/curiosity is ultimately orthogonal to the more base question of money-motivation.
In a previous role I was a principal IC trying to mentor someone who had somehow been promoted up to senior but was still regularly turning in code for review that I wouldn't have expected from an intern— it was an exhausting, mind-numbing process trying to develop some sense of engineering taste in this person, and all of this was before LLMs. This person was definitely not just there for the money; they really looked up to the top-level engineers at our org and aspired to be be there, but everything just came across as extremely shallow, like engineering cosplay: every design review or bit of feedback was soundbites from a how-to-code TED talk or something. Lots of regurgitated phrases about writing code to be "maintainable" or "elegant" but no in-the-bones feeling about what any of that actually meant.
Anyway, I think a person like this is probably maximally susceptible to the fawning ego-strokes that an AI companion delivers alongside its suggestions; I think I ultimately fear that combination more than I fear a straight up mercenary for whom it's a clear transaction of money -> code.
I had one fairly-junior teammate at Google (had been promoted once) who was a competent engineer but just refused to make any choices about what to work on. I was his TL and I gave him a choice of 3 different parts of the system to work on, and I was planning to be building the other two. He got his work done adequately, but his lack of interest / curiosity meant that he never really got to know how the rest of the system operated, and got frustrated when he didn't advance further in his career.
Very odd. It was like he only had ever worked on school projects assigned to him, and had no actual interest in exploring the problems we were working on.
In my experience, curiosity is the #1 predictor of the kind of passionate, high-level engineer that I'm most interested in working with. And it's generally not that hard to evaluate this in a free-form interview context where you listen to how a person talks about their past projects, how they learn a new system or advocated/onboarded a tool at their company.
But it can be tricky to evaluate this in the kind of structured, disciplined way that big-company HR departments like to see, where all interviewees get a consistent set of questions and are "scored" on their responses according to a fixed rubric.
That does not even sounds like a problem? Like when people are that picky about what exact personality the junior musr have that good work is not enough ... then there is something wrong with us.
When presenting the three projects, I gave pros and cons about each one, like "you'll get to learn this new piece of technology" or "a lot of people will be happy if we can get this working". Absolutely no reaction, just "I don't care, pick one".
This guy claimed to want to get promoted to Senior, but didn't do anything Senior-shaped. If you're going to own a component of a system, I should be able to ask you intelligent questions about how you might evolve it, and you should be able to tell me why someone cares about it.
I am honestly totally fine with person like that. Sounds like someone easy to work with. I dunno, not having preference between working on three parts of the system is not abnormal. Most people choose randomly anyway.
>not having preference between working on three parts of the system is not abnormal.
I suppose it depends on the team and industry. This would be unheard of behavior for games, for example. Why you taking a pay cut and likely working more hours to just say "I don't know, whatever works?". You'd ideally be working towards some sort of goal. Management, domain knowledge, just begin able to solve hard problems.
Yea a lot software developers I’ve worked with, across the full spectrum of skill levels, didn’t have a strong preference about what code they were writing. If there is a preference, it’s usually the parts they’ve already worked on, because they’re already ramped up. Strong desire to work on a specific piece of the code (or to not work on one) might even in some cases be a red flag.
What I'm talking about is like asking "do you want a turkey sandwich or a ham sandwich" and getting the response "I don't care" - about everything. Pick something! Make a choice! Take some ownership of the work you're doing!
I didn’t say anything about career direction. I’m talking about what project or part of the project. I have worked with developers who insist that they only want to work on this very narrow section of the code, and won’t consider branching out somewhere else, and that kind of attitude often comes from people who are difficult in other ways to work with.
>Strong desire to work on a specific piece of the code (or to not work on one) might even in some cases be a red flag.
I understand an engineer should compromise. But if you want to specialize in high performance computing and you're pigeonholed into 6 months of front end web, I can understand the frustration. They need to consider their career too. It's too easy for the manager to ignore you of you don't stand up for yourself. Some even count on it and plan around the turnover.
Of course, if they want nothing other than kernel programming as a junior and you simply need some easy but important work done for a month, it can be unreasonable. There needs to be a balance as a team.
I don't think it's beyond the call of duty to expect someone to acquire context beyond their immediate assignments, especially if they have ambitions to advance. It's kind of a key prerequisite to the kind of bigger-picture thinking that says "hey I noticed my component is duplicating some functionality that's over there, maybe there's an opportunity to harmonize these, etc"
I understand that this is very flexible and powerful, but it immediately makes the templates highly non-portable and requiring of hand-authorship— fine for a personal blog by a code nerd, but a non-starter for when a designer is involved who will want to use visual tools. I see that right below that there's also a "normal string templating" option that's closer to conventional jinja2 or the like, but it's ultimately still pretty nix-ified.
It might be worth some ifd [1] to allow a step that pre-processes conventional html + tags template files into the form that can be consumed by nixtml.
I'm the author of nixtml. It's already doing IFD by using python to parse markdown content + metadata and superhtml to format the final HTML (a bit unnecessary, but I liked it while developing it).
I really wanted the templates to just be nix functions. It shouldn't be an issue to pass the context to an external program with `pkgs.runCommand` or something and then read the result (IFD like you mentioned).
Yeah, it feels like the more conventional way would be doing the template-filling as a build step, so it's Nix just for the overall structure managing a fixed build graph, and then a per-page Python run to actually fill templates and generate the snippets/pages.
However, if you did want it to be nix all the way down and get more of that juicy dependency granularity, it could be more of a model where content and templates are transformed upfront into Nix source, which is then transformed and combined during evaluation. Obviously this is fairly slow in an IFD world where all that pre-work has to be serialized, but it would be interesting to experiment with what it looks like in a dynamic derivations context.
Yeah it would probably be more efficient to do the templating as a build step in the derivation that parses the markdown. But after making nixidy[1] I wanted to have a crack at making a static site generator _in nix_. I'm open to expanding it though of course :)
Oh I can totally understand the impulse on that score. I guess going the way you have at the very least gets you out of some of the annoying handoffs of data between the two worlds, for example putting nix attrsets through toJSON so that they can be picked up on the Python side as template-fill variables.
I haven't for many years [1], but I think the current state of the art is stuff like webflow, silex, pinegrow. None of them _really_ let you directly open, say, django's template files and hack on them though, so there's still a gap where you've got a designer periodically exporting from a visual tool and then their changes having to be ported into the template representation. Obviously it's easy if all they touched was the CSS, but less obvious if markup is involved.
Honestly seems like there's a bit of a gap here. Would be an interesting case for copilot tbh— here, take the old export and the new export, and make me a PR applying those changes to the templates in this repo.
[1]: I was briefly an intern at a web shop in the late 00s and it was one guy doing Dreamweaver and the rest of us coding PHP around the assets it produced.
I think I've hit the sweat-spot with the hiccup-inspired way of just using Nix data, and avoids a whole shebang of templating issues since it's not actually templates, just Nix data and expressions.
Obviously ruby is bigger than just rails, but rails definitely popularized the idea of magical objects that are automatically syncing state and doing things on your behalf. This is presented by fans as surprising and delightful, rather than surprising and terrifying.
Popular python projects like requests and flask also lean into the idea of providing a programmer interface that is expressive but also maximally brief on the happy path—see especially the context local proxies in Flask (request, session); these look like global module imports, but they're actually request specific despite not being passed into your handlers... eek.
On the other side of things, languages like zig and go feel like a bit of a backlash to this, that no, magic is bad and everything should be explicit, even if it costs us a bit of code to do so.
Rust I think sits at an interesting place in this, because it's all pretty strict and explicit, but all the macro and type system stuff does re-open the door to offering some DSL-like things in a way that's perhaps a bit cleaner than what other languages would have to do to get to the same place programmer interface-wise.
Funny that you mentioned Flask, which literally started as an April Fool's joke [0], but that hasn't stopped it from becoming the 10th [1] or 11th [2] most popular web framework, with over double the number of devs compared to Rails, so "seriousness" likely has nothing to do with making people want to use it.
> see especially the context local proxies in Flask (request, session); these look like global module imports, but they're actually request specific despite not being passed into your handlers... eek
I have an industrial Mini-ITX motherboard of similar vintage that I use with an i5-4570 as my Unraid machine. It doesn't natively support NVMe, but I was able to get a dual-m2 expansion card with its own splitter (no motherboard bifurcation required) and that let me get a pretty modern-feeling setup with nice fast cache disks.
reply