randombytes6869

> . We seem to do stuff that's out of the normal experience (Python to create thousands of individual reports on thousands of rows of postgres data per report)

Sounds like you need somebody that knows Python and SQL, should be easy to find. Everybody thats been in the business for a while has done reports. However everybody also hates doing reports, so you might have to pay more than you want to, or hire interns to do it.

> A maintainer who can find their way through an ugly codebase and quickly fix bugs that are identified by people who know the business domain thoroughly

I would just look for somebody experienced then, maybe 3 years +. Its going to cost more though, especially if the codebase is ugly and most of the work is reports.

> I've been largely responsible for hiring developers (usually on contract)

Hiring on contract is unlikely to get you desirable hires. Good devs have a lot of options.

My somewhat generic advice is to have a coding assignment. Some people won't do them but its the best way I've found to screen candidate quality. Equally important is to have a good developer look at the submissions. The quality of code as rated by good devs has always correlated strongly with the quality produced once hired, at least from what I've seen.

Advice for your situation specifically is to offer a lot of money and don't do contract-to-hire. Reports suck, your codebase sucks. Good developers can find another job within weeks and won't stick around unless you make it worthwhile. Most desirable hires will outright refuse contract-to-hire so you're restricting yourself to a low quality talent pool already.

You can nab good people for a lucklustere job without paying a premium if you're willing to give rare concessions. Fully remote work, flexible hours, part time, 4 day schedule, relative autonomy, etc. If you can't do that or pay well turnover will remain high.

You're not in a good spot right now. If you're open and honest about the job "writing reports in a crappy codebase" you won't get many interested hires and those you find will ask for more money. If you lie/deflect you will hire more but turnover will be insane. Your best option may be to hire interns. They will expect the job/code to suck and ask for little money. Turnover will remain high and quality will be all over the place, but at least it will be cheap.

I heard lack of effective management structure was a far worse consequence of Valve's unusual structure. Heard influence became based on connections and favors, not good results or ideas. Heard many good projects died, even ones that would make sense to a third grader (HL3 L4D3). Hearsay but its all over internet if you're curious

We have found H2 in Postgres mode to be the fastest way to test db stuff, at least in Postgres and Java. In Go you might lose most of the speed advantage since its not running "in JVM". It also doesn't support many of pg's advanced features

Java meets your requirements. It gets a lot of shit but there's reasons why its so widely used.

The standard libraries + community are larger than Go, you can find a library to do anything. Standard library is huge and mostly great.

Compilation time is a couple seconds even for huge projects. You can do automatic reloads using Gradle.

Its very cross platform, including one of the only good cross platform desktop UI's.

You can build smaller binary distributions using JLink or a multitude of third party tools.

Single binaries are overrated. Any app that's widely distributed uses an installer or package management anyways (brew,choco,apt)

> There would be no A bomb without this, for example, nor US moon missions. These were mostly German weapons scientists brought to the US near the end of WWII. The alternative was being sent to Russia. Russia was brutal to PoW's so given the chance everybody tried to surrender to US and European troops. Not really regular brain drain that time.

Brain drain always happens from poor to rich countries. Those able to move to greener pastures will, I don't blame them. This is even happening within the US in Illinois. High taxes and precarious government have led to massive migration away from the state. Highest percent of college students going out of state, and average person moving to Illinois makes nearly $25,000 less than average person leaving.

You can't blame people from wanting a better life for their family. In the end it does concentrate wealth, but maybe it will eventually just concentrate the population? This seems to be happening in China, with massive migration to megacities. Rich or poor, the countryside is being abandoned, so there's not many being hurt by the migration, just empty buildings

> I seriously doubt this was ever an existential in the sense of the shipping cost itself destroying a business.

I've read many e-commerce blogs with US sellers lamenting that they can't compete with China on $5 items because shipping costs are 5X as much within US. Maybe not killing businesses, but definitely keeping many out of the market.

> China is simply able to produce cheaper things because they have lower labour cost and so on, and that is actually good for American consumers

Lower, but not nearly as low as it used to be. Minimum wage in China is almost 1/2 of US now.

There's real instances of shipping cost offsetting lower labor. Manhole covers are a somewhat famous example. They're still made in USA because shipping offsets increased labor and materials. Would it be the same for ecommerce? I'm not aware of any studies but to me, the increased cost and shipping time make it plausible

Its not just a Rust problem, I've run into the same thing in Java and I'm sure it exists elsewhere. The only answer I can come up with is to keep your app cleanly divided into modules. There's some cognitive overhead but its usually worthwhile.

I recently divided a 100k line Java app into 5 different modules and it compiles 4 times faster. The new boundaries have encouraged better code as well. Suddenly we have things like interfaces and IoC. Before, people just stuffed things wherever.

Conspiracy, but I don't think the US ever stopped researching nuclear propulsion. There's too many advantages. They built a few working and miniaturized test engines in the 60's but never put them on planes? I don't believe that. They put nuclear weapons on planes all the time and thats not much safer. More likely, they never told anybody they put them on planes, for obvious radioactive reasons.

An aside, the strange craft reported recently with the famous jet fighter videos had "impossible performance" and were all filmed over the ocean. The ocean would be the only safe place to test nuclear drones. And their performance would be quite unmatched by anything else. The pilots even reported that they submerged, sounds like a great failsafe if your super secret black project gets seen. I doubt you would submerge a jet turbine, but nuclear propulsion could easily work under water

Very true. IMO many people that hate XML config files just haven't used an IDE that validates schema. Its super nice to have auto-complete and property validation on config files, something not offered by JSON or YAML. A good reason to stick with XML for complicated configs.

Its one of reasons I don't mind maven. Yeah there's 1000+ line XML config file, but maven DTD is so tight nearly any syntax issue will be flagged. Something easy to appreciate when you're used to giant config files that don't get validated until runtime.

Very Java-esque name for the largest Java project there is. I like it. "Eclipse AdoptOpenJDK Adoptium" has a good ring to it. Reminds me of the SharedSessionContractImplementor I worked on last week for our Hibernate interface.

You can probably just check the referrer header and display a giant nag message to people coming from that business listing.

"This website is not associated with company X which have been misrepresenting themselves by linking to my site from their maps listing."

That's far too optimistic about storage. For small off-grid systems, you need ~5 days of battery capacity to ride out lack of wind/sun. On a large scale you'll need less because you can move power from place to place.

But still. Sun is down half the day and wind speeds can be low in areas hundreds of miles wide. Its obvious they will need at least a day of battery capacity, probably more. Not hours.

Solar and wind are great. Many areas in the US have hours long periods during the day where power is 100% renewable. But batteries are way too expensive and I don't like when politicians make laws based on predictions 15+ years in the future.

To those lamenting that they're scraping... Google is the biggest scraper of them all. Facebook, Amazon, Google, Microsoft. All the big boys scrape voraciously, yet try their best to block themselves from being scraped. Scraping is vital for the functionality of the internet. The narrative that scraping is evil is what big companies want you to think.

When you block small scrapers from your site but permit giants like Googlebot and Bing all you're doing is locking in a monopoly that's bad for everyone

Java is very similar to C++. Its boring in the sense that most things have been around forever and really old code is terrible but you still have to deal with it because backwards compatibility is so good. If you don't consider Java boring I wouldn't consider C/C++ boring either.

That doesn't make Java a bad choice for building new things

I haven't used XML in our Java apps in many years. Most of them don't contain a single XML file, unless they use Maven, then they have one.

IMO Ruby is already being left behind. HTTP/2 is a good example. Rails doesn't support it, and I can't find anything recent saying support will be added soon. Java is notorious for slow innovation yet language level support for HTTP/2 as added years ago and enabled for basically every popular framework. Same with Python, C#, Go, JS.

HTTP/2 is essential if you want good SEO which makes Rails a non-starter for many projects already

I think job descriptions are just marketing materials for developers at a lot of places. Advertising your COBOL just gets you people that want to make more COBOL.

Every job I take, whatever the oldest crappiest technology mentioned in the footnotes is, ends up being 90% of my job.

Switch to React if you can. I've been using Angular for years and the solution to problems is generally "more magic". Its so convoluted these days I don't think its even realistic to build an Angular app outside of angular-cli.

Trust me, its the lack of standard library. Python and Java are both "batteries included" . You can write apps decently with just 5-10 dependencies if you want. Every JS app I've worked on has like 10-20X the dependencies of projects written in languages with a good standard lib

> at some point you will have a look into your myriad of nodejs dependencies and see with horror that they rely on C++ extension

This is a big selling point of the most boring languages of all, Java and C#. Performance is close enough to C, and FFI is painful enough, that its rare to see any native code in a project. Other languages that are slower or have better FFI have a much bigger risk of bitrot if you're going to keep a backend around for decades.

Where I work we deploy the exact same pre-built artifact to our Mac dev machines, Linux servers, and Windows QA guys. With Go, Python, JS, Ruby, etc we would have to have it built specifically for the platform. They all use enough native libraries that you can't share a zip file. And its a huge pain to cross-compile for anything except Linux.

This is a great idea!

For Deno this seems like a very good choice. Pick the good parts from Go and reuse them. I applaud Deno for going its own way with the module system though... That's been a hot topic in Go for a very long time

Parsing minified JS takes up quite a bit of load time for most sites. Binary formats for VM languages aren't just smaller, they're many times faster and easier to parse and verify

This is actually how maven is for Java as well. the repo isn't official but its so widespread its defacto.

> I would bet good money that most of the management in charge of the websites that make up the web would not waste dev time on migrating to some minified JS file replacement, when webpack-style minifying works "just fine" and allows your team or whatever to keep churning out new features

I don't think so personally. Code size is a huge issue for page performance, and a "bytecode" format would probably be 2-3X smaller and 2-3X faster to parse. Together, this might triple JS loading speed. Maybe double the loading speed of JS heavy sites.

JS with sourcemaps isn't so different from compiled code with debug symbols. The sourcemap support could probably be adapted with minimal work. And its likely the transition would be transparent to most users, nobody really looks at the minified JS as it is.

Another big advantage is vastly simplifying JS parsing and JIT compilation. In Java and C#, most features are added without changing the code format. And when it does get updated changes tend to be minimal. Upgrading browsers and minifiers every time JS adds a language feature is a real burden on the ecosystem

A lot of the newer stuff in JS is great. The baggage is what bothers me. For all the flak Java gets for having ancient stuff, the old stuff in JS is way worse.

Java cruft is better these days if you use 11+ with Lombok. Almost decent. You can also use Kotlin which is honestly good, but unless you pay up for IntelliJ support for it is mediocre at best. I really like Typescript's nominal typing, wish Java chose that road.

I'm not a Python guy, but Java has Streams and RxJava which is great for functional stuff. I'm pretty sure RxJS was originally a JS port of RxJava. The same library has flavors in most languages now, you may be interested in the Python version https://github.com/ReactiveX/RxPY

Publishing to NPM registry is much easier, but everything else is worse. I blame much of it on the lacking standard library. But JS not packaging libraries in archives, plus using minifaction instead of a bytecode format both suck. JS has a huge parsing problem, for some sites half the page load time is parsing JS. VM's with an efficient code representation like C# and Java avoid this. Java and C# package source, compiled code, and documentation in a standardized (and efficient) way. NPM just isn't there yet.

Java is missing async await, but there's also grumbles about supporting it and function coloring. Java has Akka, promises (CompletableFuture), parallel streaming, and traditional threads. The problem with supporting async/await without threads is that it doesn't solve for modern CPU's having more and more cores. In Java/C# its trivial to use the whole machine and share structures.

You should try Vert.X, its very similar to Express. I would almost dare say Express borrowed a lot from it.

There's some good design decisions rolling in, but still plenty of reasons I avoid it when I can.

There's languages better than TS/JS for back-ends. I don't mind Typescript but I only use it because some flavor of JS is mandatory these days.

The non existent standard library and pretty nutty dependency management makes JS a bad choice for back-ends. There was a article a few days ago on how Deno is aiming to fix most of this and other issues, but I wouldn't use it for a couple years.

Back ends tend to stick around far long than front ends. Every company I've worked at is still running their original back ends, some decades old. Front ends are easier to replace because it tends to be just UI stuff, not a lot of business logic. I apt to take a lot less risk on the backend. It's probably going to be around forever and customers don't have to see how crusty it is :)

I don't think its physically possible to read this in the time since its been posted, but since people are commenting anyways I might as well join in.

I've been using JS since the JScript days, and let me tell you it was horrible. Awful. I would rather use VBA, Perl, early PHP, really anything I've touched besides COBOL. It was buggy, horrifically slow, had an even worse standard library than it does now, didn't work the same way between anything. I remember testing performance and getting 1000 integer increments a second in an empty for loop. Even back then an alarm clock running C was orders of magnitude faster.

But the massive popularity of the web has made it decent. Its a good example of the (overused) axiom that you can pour enough money into anything and make it good. With JS, this actually happened. Probably because the other choice was transitioning the web to Flash, Silverlight, and Java Applets. The proprietary solutions lost the battle thankfully, even though admittedly they were better than JS for a long time after they died.

There's still lingering problems, some which may prove un-fixable. The standard library is a joke. The 1 million line ancient Java monolith at work pulls in less libraries, by count and space then create-react-app. And not having threads is just terrible. People that don't know better ape over async, not knowing that most languages have async, threads, sometimes fibers, and fast shared memory between them. And NPM works decently but putting 5 million files into my node_modules folder is absurd. NPM is the only reason I know that most OS'es still have a path length limit. You would think the world could standardize on putting libraries into a zip or something like even ancient crufty languages like Java do. If it wasn't for SSD's modern JS wouldn't even be usable. And can we just compile JS already? Minification seems so normal that everyone's forgotten its a shitty hack. If you're going to minify to the point that JS resembles bytecode why not just standardize a format. People say "JS runs right away because its not compiled"... Well... How long does your WebPack take to transmogrify 150MB of spaghettified JS into a pile of chunks you can actually feed a web browser in prod? Probably longer than it takes most languages to compile. If we just compiled to a reasonable format like other VM languages, we wouldn't waste so much time parsing and keeping these tools working with every semantics update.

Here's to the hope that money poured into JS will finally fix the remaining issues. I give it another ten years and I'll finally enjoy most of my time in JS land.

Deno is the Java-fication of JS. I'm sure there will be Node-like tide of "JS is better than Java now that we have X" even though Deno brings JS closer than ever to Java. Despite being cynical, I don't think its a bad thing. Java does a lot of things right.

Deno -> Java

Runtime security options -> Security Manager.

URL based packages with simple HTTP-> Maven works same way.

Bigger standard library -> Java's is huge.

Types -> Java, yes.

Single executable -> Fatjars.

All the features mentioned in this article have been in Java over a decade. Its relieving to see a JS runtime that finally gives in to enterprise niceties. Us Java devs like to crap on JS for reasons besides being "boomers". The features Deno brings were all real reasons to use Java instead of JS up until this point.

Now if they would only fix threading, I would consider Deno/JS a real contender for backend dev