Exactly there's so much stuff you simply cannot configure otherwise. For example disallowing applications to take sole ownership of a mic, in-detail power plans, etc. If they remove the old control panel, your machine basically becomes unconfigurable.
Tidal is using a revenue share model, just like Spotify. A higher per-steam payout just means users on Tidal are listening to less music than Spotify users.
Those of you surprised to see Java so prominent, where have you been all your careers? 10 people startups with nodejs backends? You must have been entirely shielded from enterprise software companies.
It's a weird one - I've been at Google for more than 5 years. I know from the stats that we have a zillion lines of actively developed Java, there must be huge swathes of the company that you could even call a "Java shop". I dig into random bits of code all the time. And yet I've looked at Java maybe three times in my tenure. And if I needed to submit Java code, I would not have a single contact to ping for readability review.
Java was the first language I learned in my CS degree, I still think this was a sensible choice by the CS department, but I don't think I've written a single piece of Java since I left 10 years ago!
It seems like a lot of Java usecases may be big and important but kinda isolated! Something about where they sit in the economic value chain perhaps?
And later, I thought I'd check, you know, what Google itself has to say on this: ;)
what are the main programming languages used at Google
Result (unformatted):
AI Overview
Google utilizes a diverse set of programming languages across its various products and services. The main programming languages used at Google include:
C++:
Widely used for performance-critical applications and system-level programming, such as in the core search engine, Google Chrome, and other backend infrastructure.
Java:
Essential for Android app development and significant portions of Google's backend systems.
Python:
Employed for a wide range of tasks including scripting, data analysis, machine learning, and web development (e.g., YouTube).
JavaScript:
Fundamental for web application development and frontend interactions across Google's web-based services.
Go (Golang):
Google's own open-source language, increasingly used for cloud-based projects, microservices, and network programming due to its efficiency and concurrency features.
SQL:
Crucial for managing and interacting with databases, which are integral to almost all data-driven applications at Google.
While these are the primary languages, Google also utilizes other languages such as Rust (for projects like Fuchsia OS), Kotlin (for Android development), and Dart (for Flutter framework development) for specific use cases and projects. The choice of language often depends on the project's requirements for performance, scalability, development time, and existing infrastructure.
Dive deeper in AI Mode
AI responses may include mistakes. Learn more
So it looks like the main ones I missed were Rust and SQL.
Dang! I should have thought of SQL, at least for their IT ops, but I was thinking only about their customer-facing apps.
I work on stuff that's adjacent to system software (I'm actually mostly a kernel engineer). But I've touched code in all the major languages at Google: loads of C++ and Go, much less of Python and Typescript. But Java/Kotlin is the only one I've never touched at all.
The financial sector, insurance sector, healthcare sector all jumped on Java a couple of decades ago, and they have massive repositories of Java code, and are actively migrating their COBOL code to Java.
What do you mean by this? To me it sounds like people are saying they are both "old" languages, but I don't know what you mean.
I work in a shop that has lots of both Java and COBOL. We are not "actively migrating" COBOL code to Java. It looks like mainframes will continue to exist for decades to come (i.e. >20 more years). Obviously, brand new applications here are not written in COBOL.
I've said this myself as Java's reification of mid 90s OO and poor interop via JNI are not to my taste. But I've spent 25yrs in banking with JPMC, BoA, Barclays et al. Done lots of interop with Cobol on S/390, AS/400 and VME. Never heard of any of those systems being rewritten in Java. Have encountered key mainframe prod systems for which source is lost.
I know of one investment bank (a former employer) that rewrote its mainframe-based settlement system in Java (on Linux). Front office systems were often Java (replacing Obj-C in some cases).
That was two decades ago – almost a generation! Interesting to think that some of those systems would now be considered “legacy”.
I'm guessing Swiss Bank/UBS as a mate used to trade there and had a NeXT workstation and loved Wingz. Later I heard they were doing server side pricing work on Apple servers. I stand corrected; thanks!
I might be mistaken but as I understand it COBOL never had the reach that Java does. It's everywhere, from embedded systems to massive clusters, as bulky VM, slimmed down VM or native. Business, science, recreation, the sector almost doesn't matter, it's going to have Java somewhere in there.
Wasn't this whole thread about joking that Java is the new COBOL? And a lot of enterprises use Java and that is becoming the new entrenched/old/stodgy language that the hot new kids don't want to use?
In its day, a lot of 'cool' companies used COBOL, back then. Because it was an ok solution, back then. So to say, today, Netflix is cool and uses Java, thus Java is different and still cool, is not valid. Does not invalidate the point. It is the same situation, just decades later.
Maybe shouldn't have conflated SAP, but they seem to be just all part of the same giant ecosystem of 'current/entrenched' solution that 'we use because we have to, not because it is better'. Not unlike COBOL.
I'm not saying COBOL is a bad language, far from it, which the billions of lines of code running production proably also attests to. The first COBOL program i ever edited, in 2008, was last edited in 1987. It had run flawlessly every day for 20 years. COBOL when invented was invented to allow business people to express business logic programatically, which is also why it has such a large footprint in finance, insurance, etc.
I'm not saying Java is a bad language either. Java is great, much like COBOL was, and like COBOL, Java still evolves today. It has flaws, but so does every other language, and most of the flaws in Java are understood. There is literally also nothing you can't do in Java that you can do in <insert fashionable language of the year>.
We probably shouldn't write web frontends in Java, and most people figured that out a decade or more ago, including the financial institutions.
The typical flow in a financial institution is something like "Angular (in some form) => Java Backend => COBOL on mainframe => DB2", where "=>" can be anything from REST to message queues (i was tempted to write MQ, as most will likely be IBM MQ, but others exist and are used).
Most companies migrating away from mainframe (and thereby often COBOL), have also started implementing microservices instead of giant monoliths, which is what has kept the mainframes of the world running for so long. Most companies i've worked with, have had 45,000 - 90,000 COBOL programs running every night, with almost as many running on demand, and each and every one depends heavily on the output of the previous part of the chain.
Thost giant chunks are now being migrated to microservices with well defined couplings, meaning that when it eventually becomes time to migrate away from Java, it will be somewhat easier as you can eat the elephant one mouthful at a time, and not have to reimplement 50+ years of legacy code and conventions in one go.
I've said it before, and will gladly say it again, if you choose a COBOL career today, you will most likely never be unemployed for long until you retire.
Anyone who is surprised is not from Finance sector. I wouldn't just say enterprise though because there could be non-finance enterprises where Microsoft and .NET/C# rule.
Have you had any significant issues with scams? In my home country we have a huge problem of scammers calling and tricking elderly people to transfer their savings with a similar instant payment app.
Scams are a social problem that can't be solved with technology alone. That said, Pix includes several features to help mitigate them:
The recipient's name and part of their ID are displayed on the confirmation page. This allows you to verify their identity, as the name must be linked to a real ID.
Users must set transaction and daily limits, with any changes taking effect only after 24–48 hours.People are encouraged to maintain lower limits.
Since transactions are tied to real individuals, it becomes easier for law enforcement to track down the recipient after a scam is identified.
Preservatives achieve their intended function by broadly destroying and preventing the growth of microbes, which are an integral part of our digestive system. So I would flip the question: what evidence is there that preservatives don't damage a healthy human microbiome?
Kotlin does improve on the primitives/boxed situation. For example in Kotlin there is just "Int", not both "int" and "Integer". The language will use stack-allocated primitives wherever possible and boxed objects when necessary (in Collection generics or when you've explicitly opted into nullability). The distinction is abstracted away from you as a programmer. Sounds like the consistency you want.
reply