Maybe you missed this part: “That seemed like a lot of thinking, you might object. It probably was if you’re not familiar with Program Construction yet, but once you’ve derived a couple of these theorems, you’ll find that there is no thinking involved. Not in the sense that once you’re good at something, you can do it almost mechanically, but in the sense that there’s only one way this could have gone. Starting from that post-condition, the theorems we proved fall out automatically as we continue expanding our model, and the same can be said for our loop body. Program construction is really easy in that way, because all you’re doing is following the program derivation to its logical
end.”
Up until Van Buren v. United States in 2020, ToS violations were sometimes prosecuted as unauthorized access under the CFAA. I suspect there are other jurisdictions that still do the equivalent to that.
I found a correlation between Rails and lower salaries. Not sure why though. I was actively looking to move to Rails for a change of scenery, until I realised it comes with a tax.
What country were you searching in? I'm an American work-from-home Rails + React engineer (admittedly with 12 years of experience), and I'm in the 96th % income bracket for individuals of my age (mid-40s). And I just started this position a month or two ago, so it's not like I got this job during the time of ZIRP.
IMO it completely depends on the company you're working for. I've seen job ads targeting my skill level offering $200k/year, and others offering $130k or even less. There will always be companies out there either trying to lowball people, or who genuinely don't operate in a vertical which is profitable enough to pay top-band salaries.
The delta in terms of salary? The median is roughly similar, maybe a slight edge for Rails + React depending on region or company. But the big difference is volume. There are way more Rails + React roles out there, and the Rails-only ones tend to be more variable in scope, stack, and compensation.
On the developer experience side, I haven’t worked extensively with the latest versions of Rails, so I don’t have a strong opinion yet on whether Hotwire provides a better frontend experience than React. That said, people I respect in the Rails community speak highly of the Hotwire approach to building modern, interactive UIs without the overhead of a full SPA. I’m sure I could pick it up with a little effort, but it’s not a top priority for me right now.
From a technical perspective, my sense is that teams adopting or reverting to a pure Rails stack, especially with Hotwire, tend to be more conscientious about keeping versions up-to-date, and generally more opinionated and deliberate about tech choices. A few years ago, replacing Rails views with React SPAs was not uncommon. But now that Rails has caught up with tools like Turbo and Stimulus, some teams are intentionally moving back toward server-driven UIs.
In terms of employability, most of the job listings I came across during my recent search were still Rails + React. And given that being fluent in multiple tech stacks broadens my opportunities, I plan to stay in the Rails + React camp for now.
I mean, if you want to tie your fortunes to one team and company forever, then sure, it can make sense.
I've had decades like that in my career, which began in the nineties. It would be nice to have another such decade; I don't enjoy always keeping one eye on the exit and my back to the wall, rather than being able to count on a given environment to stay stable enough long enough with enough upside to really repay my investment.
This doesn't feel to me like such a decade, though. Too much is changing too fast.
Emacs' configurability is hard to describe to anyone who hasn't immersed themselves in that sort of environment. There's a small portion of the program written C, but the bulk of it is written in elisp. When you evaluate elisp code, you're not in some sandboxed extension system - you're at the same level as Emacs itself. This allows you to modify nearly any aspect of Emacs.
It'd be a security nightmare if it was more popular, but fortunately the community hovers around being big enough for serious work to be done but small enough that it's not worth writing malware for.
I don't know if it's a security nightmare any more than other editors that have "plugins" (or the like).
One advantage for Emacs is it's both easy and common read the code of the plugins you are using. I can't tell you the last time I looked at the source code of a plugin for VS Code or any other editor. The last time I looked at the code for a plugin in Emacs was today.
I don't think it's a security nightmare per-se. Most of the time, you're not installing a lot of packages (the built-in are extensive) and most of these are small and commonly used.
It's like saying the AUR is a security nightmare. You're just expected to be an adult and vet what you're using.
I'm not sure I agree with the number and size of packages people install (unless you're comparing them to, say, org-mode), but that's not really what I'm talking about.
Emacs runs all elisp code as if it's part of Emacs. Think about what Emacs is capable of, and compare that to what a browser allows its extensions to do. No widely used software works like that because it's way too easy to abuse. Emacs gets away with it because it's not widely used.
I don't know the first thing about VSCode but I'm willing to bet there are strict limits to what its plugins are allowed to do.
I don't know if that's changed since last I wrote an extension for a web browser, but the API is pretty open for the current context (tab) that it's executing in. As long as it's part of the API, the action is doable. Same with VSCode or Sublime. Sandboxed plugins would be pretty useless.
I guess it's hard to switch from a working setup that you've invested time in.
Especially since you might not be familiar with the new one.
Personally, I'm trying out things in VS Code, just to see how they work. But when I need to work, I do it in Emacs, since I know it better.
Also, with VS Code, just while trying it out, simple things like cut & paste would stop working (choosing them from the menu, they would work, but trying to cut & paste with the key shortcuts and the mouse, wouldn't). You'd have to refresh the whole view or restart it, for cut & paste to become available again.
it's a shame vim is so stinky because after 15 years of using it now i find myself using vscode. I always like vim because editing is efficient. Now I dont write as much as supervise a lot of the boilerplate code.
Over the years I have gotten better with vim, added phpactor and other tooling, but frankly i dont have time to futz and its not so polished. With VSCode I can just work. I don't love everything about it, but it works well enough with copilot i forgot the benefits of vim.
I get your experience, but for me using vim is perfect for code exploration. The only needed plugins are fzf.vim and vinegar. The first for fuzzy navigation and the second for quickly browsing the current directory.
LSP experience with VSCode may be superior, but if I truly needed that, I would get an IDE and have proper intellisense. The LSP in Vim and Emacs is more than enough for my basic requirements, which are auto-imports, basic linting, and autocomplete to avoid misspellings. VSCode lacks Vim's agility and Emacs's powerful text tooling, and do far worse on integration.
I love Temporal-- we use it at my company. It's very very good for our use case, but took a while to understand how to use it. We're still figuring things out (Workflow versioning is one thing we suck at still).
That said, I'm not sure why this post from 2023 was posted here today. There've been multiple updates to the Python SDK since this post.
> Workflow versioning is one thing we suck at still
well its not entirely your fault :) what practices have you adopted now that you have some experience with it?
lower down OP mentions that they got the link from a HN discussion on asyncio 2 days ago https://news.ycombinator.com/item?id=40287354 . i guess the upvotes are today's lucky 10,000 learning about it for the first time.
This is the kind of gen AI that I can really get behind. Great repo and easy to understand with the attached video. Is such a thing possible for Python? Or does the AST parser and code planner work best with static typing?
Python is trickier because of the lack of strong typing support by default in Python. So we're left with projects using strict mypy or with very extensive test suites for validation.
It's possible, just probably not the next language to tackle. If you'd like Python support though, you can upvote this github issue: https://github.com/xeol-io/bumpgen/issues/61
People aren't static, nor are companies or roles within them. Treating every person as unchanging and treating the requirements of each level in the hierarchy as unchanging are just plain bad assumptions to make.
People grow. Companies change.
This book was meant as satire, and the fact that so many people take it as fact is honestly quite concerning.
"In 2018, professors Alan Benson, Danielle Li, and Kelly Shue analyzed sales workers' performance and promotion practices at 214 American businesses to test the veracity of the Peter principle. They found that these companies tended to promote employees to a management position based on their performance in their previous position, rather than based on managerial potential. Consistent with the Peter principle, the researchers found that high performing sales employees were likelier to be promoted, and that they were likelier to perform poorly as managers, leading to considerable costs to the businesses.[15][16][2]"
The Peter Principle might be downstream of the Monotonic Pay Scale, where it is expected that a person who manages others must be paid more than any of them. Conversely, no matter how good you are or how much money you are making the business, you will reach a point where your pay is effectively capped unless you transition to management.
The government suffers from this especially, despite an ostensibly very different incentive structure. The explosion in government contractors (by which I mean, individuals indirectly employed to do jobs in lieu of direct hires) seems to be driven in no small part by this problem.
> This book was meant as satire, and the fact that so many people take it as fact is honestly quite concerning.
The article says it was satire but it also says it was based on their real research. Also satire doesn’t necessarily mean something is meant to be untrue
Yep, many “just-so” stories have some aspect of truth. I feel like people citing the Peter principle as a cliche explanation for many things that are likely to be overdetermined probably correlates with intelligence, as it takes greater intelligence to consider more complicated models of career advancement.
That particular passage in the Wikipedia article on the eponymous book being satire is worded extremely poorly. Satire is a common format for making social commentary. The occurrence in organizations of Lawrence Peter's findings, now known as the Peter Principle, is the social commentary being communicated by the book. It is a phenomenon which had previously been established as occurring prior to the book in Lawrence Peter's research and was the entire basis for the eponymous book being written by Raymond Hull.
reply