Re what other developers use. I tried mermaid and other text to diagram tools for work, but, as mentioned above, found them lacking. Most companies / teams I know of use something like excalidraw or miro. Definitely matches your simplicity requirements, but, obviously, no git blame
I long for a deep article about the same topic. The real, core difference between Java and Go for backend is declarative vs imperative coding styles.
This one, as typical for such articles, repeats typical secondary talking points and even makes similar mistakes. For example it conflates the concept of DI with specifics of implementation in some frameworks.
Yes there are older Java frameworks that do runtime magic. But both new Java apps and well designed Go services use compile time dependency injection as a way of achieving dependency inversion.
Java 8+ is basically a declarative language. They even officially started departing from Object Oriented Programming towards Data Oriented Programming ( article by their chief architect https://www.infoq.com/articles/data-oriented-programming-jav... ). Unfortunately, most of the comparison articles come from people who still code POJOs with setters, use for loops and overall rely on mutable and unsafe code.
And using Pike’s own words “go is unapologetically imperative”.
The article you link to does not contain the word "declarative". It simply states that modern Java allows more of Data-Oriented Programming, meaning a emphasis on pure data structures (records) and more expressive types (algebraic types). It doesn't say much about the code that deals with this data, which is of course procedural.
Write that article then. Don’t badmouth the writer’s firsthand (evidently not secondary) experience over the course of a year since they didn’t express your idiosyncratic view that Java is a Declarative Language, which is very different from a data-centric language, which itself is a term from the clojure/scala enthusiasm about functional programming around Java 8.
It looks like the answers are heavily biased towards “my favorite tool”. And don’t take into account what’s actually asked. For a person who doesn’t want to become an swe (e.g. working on a specialized area at a big company) and who is a newcomer the answer is simple: JS, period. Take Next.js and try writing something using SO, chatGPT, articles and books. Treat html , css as “will learn on the go when I need something”.
Next.js is the closest that the JS has to the standardized, pawed path. It covers all you need front-end, back-end, static sites. Batteries included.
Note: I am mostly a back-end / SWE and mostly avoid JS, but I also have to admit that IMO that’s the best match with the authors goals.
I'd consider Nuxt - it has all the benefits of Next without having to deal with React, and it's also pretty popular/standardized. Vue is easier to write than React
Some of the answers are exactly what I've been trying to avoid. My only goal is being able to build my own stuff, I don't really care about kubernetes or scaling. I don't anticipate to have 1m active users with concurrency.
At the same time, I got a bit scared by React quite frankly and hence was only looking at Sveltekit. However you rightly pointed out, its still being shaped despite being similar to Next.js and seems like ideal for React devs who want to jump into more simplicity and "vibes" with DSL.
My only other consideration was Rails but for that one - the learning curve is even steeper.
Reading your question, I think Svelte or SvelteKit is probably a good option like you said. It's basically just JS/HTML/CSS as normal but if you want interactive UI stuff it's very simple to add. At this point SvelteKit is totally stable, it's just not as popular as React so it doesn't have as much community / LLM support.
Look at https://earthly.dev/
But ideally we need more info - language, env and etc. for example both CircleCI and Gradle match your current ask but something tells me you need something else
Big +1 to this. I’ve been using JDBI lately and could not be happier. It is not an ORM, only a lightweight mapper. And it supports all modern libraries and paradigms (Vavr, Immutables, immutable “value classes” …)
I used to have a local only manager but then, obviously, syncing becomes a problem. And then it becomes a choice between syncing an encrypted blob using your own solution (potentially not very secure) vs using a provider who still treats your data as an encrypted blob with no access to the data and tries to do it securely. I think the provider is still more secure (again assuming the 1password access model not talking about LastPass-like providers) plus much more convenient. So if not 1password what would be a recommendation assuming syncing is required?
I switched to 1password after this breach was first announced, but I find it a lot more annoying to use (and I found Bitwarden even worse). Granted, nowhere near as annoying as the breach. Lastpass got in my way a lot less frequently though.
You know if you are talking about lies would be great to provide some credible references
Otherwise the comment is pretty bleak and matches well Putin’s propaganda.
Context: I have relatives in that area
This is true for npm. After the incident with leftpad, you can't unpublish anymore. You can, however, publish a new patch update that completely breaks everything.
> This is true for npm. After the incident with leftpad, you can't unpublish anymore. You can, however, publish a new patch update that completely breaks everything.
You absolutely can unpublish, it just requires more steps. If NPM gets a DMCA takedown request they will absolutely have to fulfill it.
> If NPM gets a DMCA takedown request they will absolutely have to fulfill it.
Assuming the package is released under a Free Software licence, what grounds would there be for a DMCA takedown?
I suppose a developer could include the lyrics to a pop song in their code (possibly encrypted), and then tell the copyright holder about it (since I don't think you can make a DMCA request on behalf of a copyright holder without their permission), but I would hope that such a poison-pill would be caught long before the package became widely depended on.
Perhaps you're thinking someone would risk perjury(?) charges for making a false DMCA request against their package, and NPM would act on the request without questioning it; but remember that NPM is owned by Microsoft and they have previously stood up to frivolous DMCA requests (after a fashion)[0]. That article has the lede: "Software warehouse also pledges to review claims better, $1m defense fund for open-source coders".
> I don't think you can make a DMCA request on behalf of a copyright holder without their permission
In theory, you're right. In practice, there's never any actual consequences for filing a false DMCA claim. Worst case is that the thing doesn't get taken down, but that's no worse than if they didn't file it at all.
Corps don’t care about DMCA takedowns from natural persons. I sent a takedown once, the CEO replied that he was sorry it had come to that, but they still distributed it for years under a license I did not grant. This CEO is licensed to practice law in California, btw.
Some parties that are distributing other peoples' stuff lose a safe-harbor protection from liability themselves if they ignore it.
This means intermediaries who don't benefit much directly from distributing a given bit of content will immediately comply with the DMCA takedown process. But this does nothing if you send the notice to someone who is actually using it.
The correct move is to send DMCA to the infringer's ISP/host. Then the ISP has to take it down unless counter-notified that they say they're not infringing. In turn, that counter-notification improves your position for any litigation that may ensue.
Funny, my company couldn't use Webpack 1 because a dependency of a dependency... depended on an ancient package from the days when it was common to not bother with attaching a license.
Legally, that meant that noone could use it. In practice, nobody but our legal department cared, so we had to wait for version 2 when the dependency chain was updated to remove it.
The people trolling YouTube over copyright are either making false Content ID claims[0] (not DMCA takedown requests), or claiming infringement based on an incorrect match of something they genuinely hold the copyright on.[1]
You're probably right, though, that there is enough imprecision in the system for someone to claim that someone else's code snippet infringes on the copyright of a code snippet the claimant had previously published.
> Assuming the package is released under a Free Software licence, what grounds would there be for a DMCA takedown?
Noncompliance with the license, e.g. by removing required copyright notices/attribution in the code (this has happened in the past). Or straight-up uploading someone else's non-free code.
I didn't remember that particular legal complication, so thanks for prompting me to look it up. It seems that his argument was that Bukkit couldn't be distributed because it contained Mojang's proprietary code, but the fact that it also contained some of his code meant that he was a copyright holder for the purposes of the DMCA.[0]
This seems like an edge case that wasn't anticipated by the DMCA, but I can see the argument that mixing GPL code with proprietary code is creating and distributing a derivative work, in violation of the GPL. Without proprietary code being present, though, I don't think a developer can DMCA takedown their own GPL software.
You are technically correct. The best kind of correct! In practical terms, it depends on the license used. Since most licenses used in open source will prevent you from making these kind of requests, this consequence isn't likely to have any practical implications.
You are assuming that the true rights holders of all the code in the package actually agreed to the given license. Someone unrelated to the package development can still claim it includes an illegally-copied, unlicensed version of their code.
> If NPM gets a DMCA takedown request they will absolutely have to fulfill it.
No, they don't. Honoring DMCA takedowns allow benefit from an additional safe harbor from any existing infringement liability for the alleged infringing content, but are not mandatory in their own.
Your Content belongs to you. You decide whether and how to license it. But at a minimum, you license npm to provide Your Content to users of npm Services when you share Your Content. That special license allows npm to copy, publish, and analyze Your Content, and to share its analyses with others. npm may run computer code in Your Content to analyze it, but npm's special license alone does not give npm the right to run code for its functionality in npm products or services.
First you agreed to ToS when you uploaded things to npm. I haven't read the terms but it should be enough for npm to publish on npm no matter the license.
Secondly and as important if you publish something under an Open Source license(1) then you _cannot
unpublish it_. You granted copyright to
_everyone_ for and existing both now and in the future to distribute and use it(2) (legally it's a bit more complex but that's what it boils down to).
(1): Assuming you had the legal right to do so, but if not you are liable for any fall out, not npm (because ToS, they still need to take it down reasonable fast, but they might be able to sue you).
It is indeed all, even if you ignore the "popular" qualifier. If a license could be unilaterally revoked, it would fail to meet the Open Source Definition for that reason.
The differences between the two are extremely minimal, basically only relating to patent rights relating to the software. Go read https://www.gnu.org/philosophy/free-sw.en.html - the FSF's Free Software definition, and https://opensource.org/osd - the Open Source Definition (both by the respective parties that coined the terms and maintain them to this day) and see what the actual differences are. They're not many.
Because npm install has the insane default behavior of adding a fuzzy qualifier to your package.json, for example ^6.0.2 means all of the following versions are accepted: 6.0.2, 6.0.9, 6.7.84
It’s not particularly insane. package.json and package-lock.json have different purposes, namely package.json specified intent e.g. I want a version that satisfies >=5.2.3 && < 6.0.0 and package-lock.json records the exact resolved version.
Off the top of my head Bundler, CocoaPods, Cargo, SPM, Pipfile(and various other Python dependency managers), and composer also all work like this.
Cargo even makes it implicit that a version like “1” means “^1.0.0” in Cargo.toml.
Very often, package installation is automated as part of a build pipeline. So if you want to build and deploy a new version of your software, you'll kick off the pipeline and that could potentially download a newer version of a package than was previously being used.
Incidents like this highlight that this may not be the best idea.
If you're using NPM without lockfiles, you're gonna have a bad time with discrepancies between trying things on your dev machine and building things in CI machines.
When you have a package-lock.json NPM will install exactly the same version of everything in your dependency tree, making the CI builds much more like what's on your dev machine (modulo architecture/environment changes)
Because of version locks. Normally you install “^X.Y.Z” which means any version at major X with at least minor Y and revision Z. For more conservative codebases you install “~X.Y.Z” which also locks the minor.
npm install will traditionally install the most recent packages that match your constraints. You need “npm ci” to use true version locks
The first line of NPM install's documentation[0] says(emphasis mine):
> This command installs a package, and any packages that it depends on. If the package has a *package-lock or shrinkwrap file, the installation of dependencies will be driven by that*, with an npm-shrinkwrap.json taking precedence if both files exist. See package-lock.json and npm shrinkwrap.
What does happen is: if you have added a new package in package.json it will be installed based on the semver pattern specified there, or if you run npm install some-package@^x.y.z the same thing happens. Further, if you modify package.json by changing the semver pattern for an existing package that will also cause this behaviour.
Running `npm install` in a package that already has a package-lock.json will simply install what's in package-lock.json. `npm install` only changes the lock file to add/remove/update dependencies when it detects that package.json and package-lock.json disagrees about the specified dependenices and their semver patterns e.g. having foo@^2.3.1 in package.json and foo@1.8.3 in package-lock.json will cause foo to be update when running `npm install`.
You're never going to be able to prevent that at a technical level. You can prevent it with workflow, though: 1) sync packages locally and build from those versions; 2) peg to a specific version and don't auto-update; 3) deploy to a test environment and not directly to production.
A key difference with Maven projects is that you specify exact dependency versions instead of “always use latest” or some variant of that, as is pretty common in the Node world.
Admittedly, I don't think it has nearly as wide a usage as it has in the NPM world. Dependabot (I know I'm not the first to mention it, here, today) is probably more of a factor.
Still, it strikes me that this sort of "attack" (or mishap) is exceedingly rare in the Java ecosystem, while it's pretty common in the NPM world, and I don't immediately understand why that would be so.
I was not aware of that feature. To call it rare would be an understatement I think.
> while it's pretty common in the NPM world, and I don't immediately understand why that would be so.
I think it boils down to Node projects typically specifying dependencies in the form “any version >= X”, effectively “always use the latest.” Dependencies can therefore get bumped silently just by rebuilding, essentially. Whereas in the Java world updating dependencies is a deliberate process.
Immutability feels like the best approach here. Go's module system is pretty good in this respect: "proxy" is just a proxy that serves module code, and "sum" is an append-only transparency log of the hashes of all published versions. You can't "unpublish" from the log, but you can get code hosted on proxy removed for various reasons... which users can protect themselves against by running their own proxy. Go's module version resolution strategy means that the chosen module version never changes without explicit input from the user so no "publish a new version that breaks everyone's CI" issue.
All together I don't see how GP's "email php files around" is as any better than this system in any way.
That's another JS ecosystem widespread malpractice.
Autobumping versions, or version ranges as they're called in Maven land.
Dependencies should only use fixed versions and all updates should be manual.
You should only use auto-upgradable versions during development, and the package manager should warn you that you're using them (or your dependencies are).
If package A depends on package C at version 1.0 but package B depends on C at version 1.1, what version of C will be pulled in?
Dependency management is not as simple as only upgrading one direct dependency at a time after careful review.
The NPM ecosystem is particularly difficult to work with as it has deep and broad transitive dependency trees, many small packages, and a very high rate of change.
You either freeze everything and hope you don't have an unpatched vulnerability somewhere or update everything and hope you don't introduce a vulnerability somewhere.
> Dependency management is not as simple as only upgrading one direct dependency at a time after careful review.
Most package managers won't allow these stunts and conflicts have to be resolved UPSTREAM. NPM chose to go the "YOLO" way and will fetch every single version of a package that meets the dependency demands. Terrible design, but the purpose of that was growth for NPM, the company, not the best interest of the ecosystem.
There are package exclusions, package forcing and of course, full dependency tree checks where you review what everything pulls in.
The JS ecosystem will probably have to change but because it's so decentralized, that change will be orders of magnitude harder than, for example, PHPs transition from 3 (4, 5) to 7.
I'm sorry but this is completely wrong. NPM has lock files which explicitly lockdown the version you have downloaded after your first install. These are commited to source control, so all subsequent installs will use the exact same version of dependencies, and nested dependencies too.
You need to ask npm to upgrade or delete your lock file and node modules to run into this issue.
