slackingoff2017

Spring MVC is probably what you want then.

Really though, you should invest some time in learning typescript and react. These days most apps are just API calls on the back end and you deal with templating, forms, and other bs in the frontend.

Because most apps are built this way now, you won't find any "modern" Java frameworks that support what you want, and you're pretty much gonna be stuck with the older clunkier stuff.

The learning curve for new SPA frontend stuff is high but I've found it much more productive now that I'm into it. With HTML generated on the server it's too damn hard to get pages to do what you want

Java and Go are much harder to learn. Much more complex from a language perspective, more complicated build process, bigger standard libraries.

This leads to a lot of "first languages" being the latter and a perpetual glut of recent grads that know nothing else so will do those jobs for less

This is true even with most SV darlings. Netflix, Google, Uber, and Amazon use tons of Java. Probably the majority of their systems.

Microsoft is an exception because they built C# which is basically a more modern but less popular variant of Java. There was even a project for a long time that let you use Java code in C# projects by converting the bytecode, they're that similar.

The notable exception is Facebook. They were stuck in PHP hell for so long that they redesigned the language to make it work.

Google has a huge amount of code written in Java, I would say the majority of their systems. Just look at their open sourced projects and job listings. Over 50% Java easily.

Take a look a vert.x and Dropwizard. Spring Boot can handle maybe 10k requests per second, but Dropwizard is around 200k and vert.x maybe a million.

If you're only using them for a REST API they offer similar features. Spring Boot supports loads of other stuff you probably don't need for something API driven

Eh, vanilla Java or Go is at least an order of magnitude faster than those other languages without messing with anything. You can mess around with the JVM and interfacing to native code but it's rarely needed because it's already within a low multiple of C performance writing things normally.

Arguments about what language is better are pretty flamey but it's hard to argue that performance is not an advantage of Go/Java

True, horizontal scaling will always save you no matter how slow the front end is. Cost becomes significant at a certain level too though. For example, Google estimates each search query goes to over a thousand machines. If you need 100x 1000 machines to serve a query because the back end is PHP it adds up.

And you can make Python or even PHP fast if you try hard enough.

My argument is that the engineer overhead for Go and new breeds of Java frameworks are small enough that it makes no sense to use anything else if you're planning on scaling for real.

If you start with something else the cost of making a slow language fast and the multiples of extra machines you need costs far more than just using the faster language to start with

For the benchmark you posted, take a good look at the "realistic" vs "stripped" implementations and whether the test used an ORM. You'll quickly see that the realistic test applications with any kind of ORM are exclusively C#, Java, Go, and C++

I'm talking about API calls where you make a few database queries, not local or batched.

Java/Go with pretty much any database can manage about 50,000 individual queries+REST calls a second.

This is not true. Java and Golang can use asynchronous IO and maintain thousands of concurrent connections. It's just another case where slow languages are... Slow

This just isn't true on any decently designed system I've seen. Practically any database can manage 5k complex-ish queries per second. For the common simple queries closer to 50k.

Good luck getting more than 100 calls per second out of the slow languages

And most of those other companies like Facebook are writing endless hacks, VM's, or entire languages to fix the slow runtime :)

Why does anyone write web apps in Python? PHP? Ruby?

Modern Java and Go are so much faster than the alternatives that it's stupid to consider anything else if performance is important.

Golang and Java can manage over a half million HTTP responses a second. Node is pretty fast but why bother when Java is many times more mature in features, tooling, and and supports concurrency... And uses less ram and is usually faster. People moan about the "huge" Java runtime when JavaScript uses 3-5x more memory and has a huge runtime of its own.

All the big companies are using Java and Go almost exclusively for high volume endpoints and it blows my mind the amount of mental gymnastics some companies go through to avoid following suit.

Java has come a long way since J2EE. These days it's asynchronous, non-blocking, serverless, etc.. pretty much all the acronyms thrown around about node except its not JavaScript, which IMO is a huge win.

Async avoids callbacks by restoring your calling context under the hood just like the compiler does for normal function calls and callbacks. It just does it in a way thats clearer IMO

Lol. I'm sure random people walk around your house all the time unless you're in the middle of nowhere.

What's stopping a random guy from walking around taking pictures through all the windows when they see you leave? Nothing. Dude just dresses up like the meter reader and does whatever he wants. Even if you "catch" the guy he did nothing illegal. In most places it's totally fine to stroll around on other people's land unless "no trespassing" is clearly marked. Got one of those big signs in your front yard?

If you ever leave the house I'm sure pictures of you with your family have been streamed on countless webcams over the years and probably live TV.

You have no real security unless you've got a cement room with no windows and a metal door. Anything less is just to make people feel better

Your perceived privacy violations sound pretty mundane to me.

Reminds me of this https://www.theawl.com/2015/06/a-complete-taxonomy-of-intern...

What RX gives you is a smooth flow to the last callback. Async is admittedly less flexible but the only way I know of to trigger asynchronous flow without a callback.

I worked in the C# world for a while and I'm still in envy of how clear and powerful good async support is.

let val = await Thing();

Vs

Observable.of(thing).subsribe((res)=>{call back}

For all(most) cases where you only need to hear back once

Different racial and cultural groups live in different places because people self-select for it. If you're going to build something that breaks down racial barriers you'll need to actively counter against existing bias IMO.

Less politically charged example with food.... If your service simply shows all the different kinds of food available, users will generally stick with whats familiar. If the algorithm is designed to show them mostly food they've never tried before you can counter that bias and increase the likelihood the user will try new foods.

RX is a hilarious pattern IMO. 90% of the usage I've seen would be simpler and less code just doing things the old fashioned way.

The vast majority of observer pattern use cases are solved a lot more clearly by using async

Devil's advocate here, but how are skin color and body size any different from eye color or height preference?

The only way to do it truly fairly is to disallow any physical characteristics. By only blocking some you just change the criteria/groups who are discriminated against. But who would use a dating site where you have no idea what the other person looks like?

Better to use statistics to level the playing field by, for example, showing people with less % likes more often. This is pretty much how affirmative action works. Give people biased against by other humans more opportunity to make up for it. Lot easier than trying to fix the bias in the humans.

If you think you can make humans ignore their sexual preferences by hiding certain identifiers you're a lot more optimistic about humanity than I am. I expect the most popular openers on the site to be "r u fat?" for men and "r u at least 5' 10"?" for women. Isn't it just better if those people never talk to each other in the first place at that point?

Two problems. The name is a nightmare for any large company. Countless people have brought this up and the dev team is apparently deaf to the issue. Idiots.

The second major issue is technical. Building something like Spanner requires a very accurate time source that absolutely will not skew. Ever. This is how Google avoids partitions and essentially breaks CAP theory. Perfect time gives you globally accurate timestamps without exchanging data. Distributed transactions without locks or shared state, just usually benign contention.

They're not that hard to build, just no demand. Possibly some issues with ITAR preventing such accurate clocks from becoming commodity hardware? It could easily lead to extremely accurate IMU's which are definitely limited. Not sure, but that's what I ran into researching fibre optic gyros. Atomic clocks could probably be built on SMT scale for a few cents IMO.

As usual, it seems Google is already doing this and has been for years. We either need to wait for the trickle down that Google thankfully does after about 5 years... Or get some deep pocketed tech behemoth to foot the bill for everyone else

No proof, but I have a feeling its more of a way around regulations for most tech companies. For example, in hiring, IQ tests are known to have predictive value but they're basically banned because they discriminate against women and minorities.

So you build a grey box neural network that analyzes resumes to find "good" candidates. Underneath it might draw correlations between female or minority names. It might decide that people who lived in certain places or came from country X are "bad employees". Since nobody can explain how it works once you've trained it, you're free to build it using whatever biases you want.

Same with financial regulations. The network could rely 100% on insider trading. Analyzing the HTML of websites for leaked information that isn't visible to humans yet. Again nobody knows this is how it's so good at taking in bytes at one end and buying stocks on the other.

Same here. Zenni frames are cheap, and the lenses are pretty good. But the frames are built from cheap plastic, and so are the linkages, they just plate them with metallic coating. I've had the linkages break on 10+ pairs from fairly innocent things like falling asleep with them on.

They work fine, but it's like buying anything else designed to be disposable. Make sure you have a few pairs on hand for backup

I have been involved in using a system built like this. All I can say is... It feels like you're building a database out of an event stream.

A shitty one at that... Basically the write log part, only without a way to apply that state reliably like a real database. So you have to keep the log around basically forever. It's like you're in the middle of a DB recovery all the time.

After insane amounts of research and deep thought my personal opinion is that this is the wrong way to do scalable systems. Event sourcing and eventual consistency are taking industry for a ride in the wrong direction.

In my quest to find a better way I found some research/leaks/opinions of Googlers, and I think they're right. Even Netflix admits that using eventual consistency means they have to build systems that go around and "fixup" data that ends up in bad states. Ew. Service RPC loops in any such systems are Pandora's box. Are these calls getting the most recently updated version of the data? Nobody knows. Even replaying the event log can't save you, the log may be strongly ordered but the data state between services that call each other is party determined by timing. Undefined behavior.

You'll notice that LinkedIn/Netflix/Uber etc all seem to be building their systems using this pattern. Who is conspicuously absent? Google. The father of containers, VM's, and highly distributed systems is mum.

Researching Google's systems gives some fascinating answers to the problem of distributed consistency, a solution I'm stunned hasn't seen more attention. Google decided as early as 2005 that eventually consistent systems were too hard to use and manage. All of their databases, BigTable, MegaStore, Spanner, F1... They're all strongly consistent in certain ways.

How does Google do it? They make the database the source of truth. Service RPC calls either fail or succeed immediately. Service call loops, while bad for performance, produce consistent results. Failures are easy to find because data updates either succeed or fail immediately, not in some unbouded future time.

The rest of the industry is missing the point of microservices IMO. Google's massively distributed systems are enabled largely by their innovative database designs. The rest of the industry is trying to replicate the topography of Google's internal systems without understanding what makes them work well.

For microservices to be realistically usable for most use cases we need someone to come up with decent competition to Google's database systems. When you have a transactional distributed database all the problems with data spread across multiple services goes away.

HBase was a good attempt but doesn't get enough love. A point missed in the creation of HBase, that becomes clear when reading the papers about MegaStore and Spanner, is that it wasn't designed to be used as a data store by itself. Instead, it has the minimal features needed to build a MegaStore on top of it. The weirder features of HBase/BigTable (like keeping around 3 copies of changed data, and row level atomicity without transactions) are clearly designed to make it possible to build a database on top of it.

Unfortunately nobody thus far has taken up that challenge, and outside Google were all stuck with shitty databases that Google tossed away a decade ago.

The product zuck runs is sleazy by nature, and he's made a lot of statements that tell me he's either naive or out of touch with the average persons reality.

I think Trump is a twit but I would rather have someone that seems grounded, like bill gates for example, than a guy with floaty dreamland ideas that Facebook can make everyone like each other.

My biggest problem with Angular2 is how restrictive an obtuse the framework can be at times. I've ranted about it in other comments so I'll save space and just say that Angular makes easy things hard and difficult things nearly impossible once you step off the dotted line.

Also the lack of a really solid UI library has caused many headaches. Material isn't very configurable, PrimeNg is okay but somewhat buggy and poorly documented.

The big players are increasingly doing it already. LinkedIn and Facebook only have very limited spidering.

What Google has liked to do recently is take all your data and replace your service. Search for recipes, jobs, music, or weather for examples.

They're trying to make leaving the homepage irrelevant by using sites data in their search results. Eventually the web will rebel.

WASM is going to kill spidering. We can't leave HTML if we want google to be able to read the page.

I think Google is very afraid of this. Hence their push for Angular/Polymer/AMP. If they can build a good enough platform in JS they can stall the inevitable.

In the future only marketing parts of the site will use JS/HTML. The "web app" part will be some language compiled to WASM throwing frames to the canvas

+1 for vert.x it's based on the venerable Netty project and has extremely high performance, about as close to C as you can get besides maybe Golang

Also DropWizard is pretty quick and offers a good combo of features.

Spring is the most feature complete, it's a shame it's so slow in comparison

If none of the data is visible server side why is this a service in the first place? Everything is a bunch of js running in-browser.

Just sell it like JetBrains. Sure home users will pirate it but with IDE's the money is made with companies and enterprise versions anyways.