[chisleu]

Right, but most people using it use model or data repository patterns to ensure correctness. It does offer nearly infinite flexibility provided you use it correctly. You can add fields without any sort of DB work, you just start adding fields to rows as needed and let it catch up organically.

There are use cases where mongo makes a lot of sense. It's very popular in the node.js / RAD world for sure. I certainly have never been a huge fan by any means. Only relatively recently did they solve distributed writes.

[toomuchtodo]

Unfortunately, I’d argue PostgreSQL gets you all the same benefits with JSON storage (fairly equivalent to Mongo docs), while also giving you all the goodness of a relational, transactional, schema enforcing RDBMS. PGSQL became Mongo faster than Mongo could become PGSQL.

[WrtCdEvrydy]

This is the same thing that happened in Java.

Other languages started prototyping features... that eventually just end up being implemented in Java.

[int_19h]

Java did it way too slow, and that is a significant contributor to it being relegated to "legacy" in many areas. If it waited for the other languages to prototype stuff, it might have not been the case. The problem is that it waited for them to prototype it, refine it, release it, popularize it, and for their community to adopt it, before even starting to work on it in Java - which means that by the time they had it, most people who needed it were already elsewhere (not necessarily off JVM, just another language).

Lambdas were a very good example - if you look at the closest competitor, C#, it got the first take on them back in 2005. Then a major refinement in 2008, adding type inference. By 2010, lambdas were idiomatic in C#. Java, in contrast, released the first version in 2014. And even then, they're still less powerful.

[pjmlp]

Looking around the office and my phone, Java is anything but "legacy".

As for alternative JVM languages, while they are cool and have brought many fresh ideas into the platform, they remain a very tiny portion of the Java developers' market.

Java takes a very long time, because backwards compatibility and cooperation among giant companies takes years.

C# has basically Microsoft deciding how the roadmap looks like and rebooting the platform multiple times.

C# 8 won't even be fully supported on the .NET Framework.

[int_19h]

And yet Google is investing into Kotlin.

Yes, Java takes it slow because its target market - enterprises - want it, and they have good reason to. There's nothing wrong with that. All I'm saying is that there are many other niches where developers find lagging too far behind other available options, and there's a noticeable decline in its use because of that.

And so the analogy with PostgreSQL in this case isn't working well.

[pjmlp]

Google is investing into Kotlin due to politcs with Oracle, and JetBrains (makers of InteliJ which powers Android Studio) pushing Kotlin everywhere they can.

They even separate Kotlin/Native graphical debugging from InteliJ, so that developers get to shell out for Clion license as well.

The only variant where InteliJ and Clion come together is on Android Studio, thanks to us NDK users being vocal how 3rd class it felt versus Eclipse CDT.

On platforms where developers can make use of standard Java there is less pressure to adotpt alternative JVM languages.

Just like F# will always be a shadow of C#, never getting to play with all toys, with C# slowly picking up all features that matter.

[manigandham]

Runtimes are different from languages. The C# language has never been rebooted and is fully backwards compatible, and there's no better example of long-term support than Microsoft. You can still run apps from the MSDOS era, and even upgrade MSDOS through to Windows 10 if you have all the CDs today.

[pjmlp]

Runtimes and languages go hand-in-hand, a runtime that doesn't support everything that one expects from the standard library breaks compatibility.

Code starts getting full of #ifdefs

Siverlight, .NET Core, WinRT, UWP just to give three reboots.

No support for dynamic APIs, appdomains, IL generation on the fly, reflection APIs done in a different way, ...

Actually C# is not fully backwards compatible, variables declared on foreach statements changed their semantics in C# 5.

https://blogs.msdn.microsoft.com/ericlippert/2009/11/12/clos...

MS-DOS is only supported in 32 bit variants, a species in extinsion.

[int_19h]

> The C# language has never been rebooted and is fully backwards compatible

This is not true - there have been several breaking changes in C#-the-language since 1.0. For example:

https://davefancher.com/2012/11/03/c-5-0-breaking-changes/

[general8bitso]

So, like DOS 3.3 to 5 to 6.2, and Windows 3 to 3.1, to 95 to 98 to 98SE, to ME, to XP, to 7, to 8 to 8.1, to 10?

I think I was using floppies until Win 98?

[kjeetgill]

Huh. I didn't know they worked any differently in C#. In what ways are they less powerful in Java?

[int_19h]

For example, in Java, lambdas cannot capture mutable variables from the outer scope - it must be final, or effectively final. C# always let you do that, from the very first implementation of lambdas.

[eropple]

C# lets you do that because C# doesn't have a way to declare a local readonly/final variable at all. I significantly prefer features that encourage the use of `final` variables everywhere that it is possible in Java.

I write C#, Java, and Kotlin in roughly equal measure. Each has its pluses. But the claim that Java's lambdas are worse because it doesn't let you--and this was a conscious design choice!--do something so potentially catastrophic and difficult to debug is an odd one.

[chrisseaton]

What’s the memory model for captured variables being mutated by multiple threads?

[vvanders]

Yeah, or value types. Still waiting on those...

[pjmlp]

You can use the extensions in IBM J9 or Azul, just like some use GCC C while claiming it is C. :)

Also looking forward to them and disappointed they weren't there since the beginning.

[imtringued]

A lot of useful features don't end up being implemented in Java and even if they do, libraries and frameworks have to update to take advantage of them. With a new language libraries are built from the ground up based on the new features.

For example adding async to the language isn't necessarily going to change your programs to be async because every widely used library has already adopted threads and doesn't support async yet and often never will.

[d4l3k]

Pretty much all of the things you'd want in a relational database are now present in Mongodb too.

The real benefit of MongoDB at this point is the ability to easily scale beyond a single machine with shards and high availability using replica sets.

Postgres will get you pretty far, but beyond a certain point the scaling story breaks down and you have to hack some sort of user space sharding solution. At that point all the schema update and backups become a nightmare.

Schemas: https://docs.mongodb.com/manual/core/schema-validation/

Transactions: https://docs.mongodb.com/manual/core/transactions/

SQL: https://docs.mongodb.com/bi-connector/master/

[pritambaral]

> Pretty much all of the things you'd want in a relational database are now present in Mongodb too.

On the "relational" front, it has denormalized-only schema validation and limits transactions to replica sets (so no transactions with sharding), while also recommending single-document transactions over multi-document transaction via denormalization. (FWIW, transactions aren't available in any open source release).

On the "database" front, it has a history of misleading users and remorselessly dropping data.

> Postgres will get you pretty far

Postgres is an actual relational database, open source, battle-proven with a good design and a great team behind it. It never claimed to be good at, let alone capable of, doing things it could not actually do (well, or at all).

> but beyond a certain point the scaling story breaks down and you have to hack some sort of user space sharding solution.

Scaling IS a hard thing, and presents itself quite differently to different use-cases. Nevertheless, horizontally scaling Postgres — for when one truly hits the petabyte-scale — is a problem that has been solved correctly many times before (out of core). For a similar-to-MongoDB method, check out Citus, with the assurance that it only adds to an actual database; as opposed to the MongoDB way of doing things: make up and promise magic scaling solutions that "Just Work", then try to build a database on top of it.

[ams6110]

Most databases will never need this kind of scaling.

[atm0sphere]

https://m.youtube.com/watch?v=b2F-DItXtZs