For people who didn't know: Wiz is apparently a internal framework that Google uses for their apps that wasn't ever open sourced (at least, not completely, based on a quick search).
At least they'll be dogfooding Angular now hopefully.
Google uses Angular quite a lot already. Pretty much all internal tools (bug tracker, code review, release tooling etc) is built with it. There's also a number of public facing apps like GCP Cloud Console and the Gemini web app.
Wiz has historically favored performance over ergonomics in the extreme. None of it is open source, and to be honest even if it was it's unlikely most people would want to use the mix of Java+Soy+JS+jQuery-ish API.
Interestingly both frameworks are around the same age (if you count Angular 1.0), but Wiz was kept internal.
What Sarah is referring to is both a big shift in Wiz to get modern ergonomics and a shift in the framework strategy to avoid having two entirely separate frameworks.
> Wiz has historically favored performance over ergonomics in the extreme.
This unsubstantiated claim is being paraded around by Googlers all over Twitter. And there's literaly nothing to back up this claim. Have you seen the extreme performance of the websites it apparently powers?
That thread was amazing to follow. I got a chuckle at the end. These engineers are responsible for the fates of a lot of people outside of Google as well because of how many companies have adopted their tooling (like my company). They should be challenged to defend their views in the real world. If they are good ideas then it shouldn't be a problem.
From the presentation: Angular is for "enterprise" apps. Wiz is for latency sensitive consumer apps (Google Search, Google Meet, Photos). They also mentioned Wiz is tightly integrated with the Google tech stack.
Basically all web frontends I've seen here are either Angular or Wiz, depending on latency requirements, or they're some legacy technology that is being moved to Angular or Wiz.
I can say from experience that Google requires third-parties use Angular when they are developing experiences on behalf of Google — i.e. through their agency partners.
Wiz is a web framework at google that is abysmal to work with. It’s still living in 2010, it’s all Java backend based, the build times are unbearable, and the templating, Soy, is some Java engineer who loves curly braces too much.
It’s a lot of magic and all convoluted, it’s pathetic a company this large has this as their main offering, JSX is a positive move but it’s still lipstick on a pig as it’s not really JSX but just three Java templates under the hood for now. Signals aren’t the panacea they keep saying as they simply don’t scale in big apps since the data flow is all over the place.
Googlers use Angular at google because despite its garbage size and developer experience, believe it or not, the dev experience is miles better than Wiz. It’s also nowhere near the most popular internal usage framework idk why they say that. It’s Wiz by far.
And all this is because googlers just want React or Vue but are not allowed because they are “not sanctioned”. The same reason why you can’t SSR Angular at google, because Node isn’t even sanctioned. This is all just a Hail Mary by Angular because their NPM numbers are dropping and just got surpassed by Preact of all frameworks.
My job skills are languishing at google because I’m writing Wiz and Angular all day
Whatever committee decided to silo the Angular reference docs from the usage docs has caused more harm than most of the hyperbolic non-examples I can come up with.
If you’re writing docs, please, please do me a favor and study the structure of the Django and Python docs.
> Have a reasonable developer tell me what a component viewProvider is and how it’s different from a provider using the @Component docs. It’s impossible. https://angular.io/api/core/Component#viewProviders
I linked to the reference docs, you linked to the usage docs. They're completely divorced from each other. There's not even a link from reference to usage docs.
For the reference docs to be useful you already have to know what the thing is, what it does, why you'd need it.
You can be on the component page where `viewProviders` is documented and get nothing from it if you're coming in fresh.
Why would ever design docs like that?
Angular is the only framework I've ever struggled to learn. It's a complicated framework but that's not the problem. The docs are the problem.
Which is strange. Google knows how to write docs. Or at least I've been very happy with the flutter docs. But now working on angular frontend is awful tooling wise. I don't even get useful inline docs for a lot of libraries.
> Which is strange. Google knows how to write docs.
Oh, they don't. Some of their teams know how to write docs for some of the products. A lot of the time it's autogenerated reference with a couple of bare-bones examples
Short story, they put Angular signals into Wiz, which powers YouTube among others. No concrete Wiz announcements besides that. If you follow the Angular changelogs and plans, the video basically recaps these in a less dry manner - the same as seen during previous ng-confs. There's a short section at the end [0] showcasing a preview of what's in the pipeline but didn't receive much coverage yet, such as less boilerplate when authoring components.
I've been working with Angular for 2 years, then moved to Vue and have been with it for, idk 3-4 years now.
I like the theory of Angular, the modularity, the way it works, but I HATE rxjs and the complexity of it.
And the whole thing on top of rxjs, ngrx.
You can't just simply take one value and compare it, no you have to use pipes and rxjs.
Also there's an Angular discord and they're very hostile towards anyone not fanboi-ing Angular.
I was about 6 months into Vue and wrote how I prefer it, for its simplicity. Then I was constantly harassed until I was kick/banned. With another account I saw, "HEIL ANGULAR o/" written in the chat.
That's just stupid.
You have to be open minded.
Angular has good things, but Vue has good things too and even React does.
Never heard of Wiz before.
Almost a year ago I created an Android developer account I believe it's called and paid the bill.
The name on the invoice was wrong.
I wanted them to update the invoice
They responded with, "This is America, we do what we like" more or less.
Ok, no problem, I have better things to do.
Since I haven't published anything in almost 1 year, they're now threatening to close the account, I paid the $25 for.
My adsense account, no new sites are being approved anymore, previously I could add any site without confirmation, even if it was new.
I had a site that made them and me over 150k, but I got into a fight with my partner of that site and the main domain was shut down.
I took the content and published it on another domain.
Over 7 years of daily mp3 files and images.
The 1st domain had adsense approval, the new one didn't.
They didn't approve the 2nd domain.
Talking to them is not possible.
Google is spiraling downward.
They're essentially cutting into their own flesh.
Since Darth Sundar took over it's become progressively worse.
All the wrong and used hostile decisions.
I still use and like Go, but I'm afraid what will become of it in the future.
It's unlikely I'll return to Angular. It's just too time inefficient and also slower compared to the other frameworks.
>...but I HATE rxjs and the complexity of it. And the whole thing on top of rxjs, ngrx. You can't just simply take one value and compare it, no you have to use pipes and rxjs.
We're working on making RxJS optional. In v17.3 `@angular/core` no longer has a dependency on RxJS. In the long-term we'll enable a path forward without RxJS for other core modules as well.
That said, we're providing an interop package that enables even better RxJS support for people who make the decision to use it.
Edit: in v17.3 we have a minimal dependency on RxJS in ApplicationRef and NgZone, but in practice, it's unlikely that you'd need to use these APIs. In the following versions, we'll remove these dependencies and introduce interop APIs as well.
But on RxJS, yes, it is conceptually complex. I never quite understood whether one should use
- a container component with value-type @Inputs passed down
- a service emitting an Observable and subscribing to that, then passing value-types into the template
- an Observable as @Input
- now Signals? (haven't used those yet.)
Years later though I read a book on functional programming and the whole nightmare of arrays within Observables suddenly made sense.
Vue is the best framework I have ever used. I can't imagine why anyone would use anything else. Angular has gotta be the worst imho, perhaps Ember. There are big communities around these tools though so I guess the approach resonates with certain folks.
As a backend dev that has dabbled in JavaScript (old school), I love Svelte. It makes reactivity so easy while keeping everything more or less optional and vanilla
Angular has gotten progressively better but after picking up Vue3 I dropped everything else and haven't looked back. It's like front-end sanity has arrived.
Hey everyone, I'm working on this at Google and would be happy to answer your questions :)
The tldr; is that we see a lot of similar requirements from developers across Angular and Wiz, so we're looking for opportunities to reuse work. Good example is the Angular Signals library that's now used in all the YouTube Mobile Web. In a similar way, Angular is bringing more fine-grained code loading that Wiz offers.
Over time, we'll continue focusing on what's best for developers and incorporating the best from Wiz in Angular, and vice versa. At the end we can end up with one framework, or continue to coexist.
In the next couple of weeks we'll follow up with a blog post that explains our plan in more details.
tbh - killing of basic html Gmail was the last straw that pushed me to other mail provider... I usually use imap but once in a blue moon I need to access mailbox via browser and regular Gmail client is just abysmal...
Could be interesting/useful, but none of these seem to have any impact on the sites like Youtube which loads tens of megabytes of resources, and every interaction takes a second or so to happen.
> The tldr; is that we see a lot of similar requirements from developers across Angular and Wiz, so we're looking for opportunities to reuse work. Good example is the Angular Signals library that's now used in all the YouTube Mobile Web. In a similar way, Angular is bringing more fine-grained code loading that Wiz offers.
It sounds no different from Svelte borrowing concepts from SolidJS, or Vue borrowing ideas from Svelte, from you said — if it is just adding some features that Wiz has, it doesn't sound like merging? Why put a shocking title that Angular is merging with Wiz, when Wiz has no name recognition in the outer dev community — like we don't know what that means?
Hey, im working with angular for almost 5 years now.. What changes should we -developers - expect in the developer experience. In other words how we work with angular. Are you aiming for the "drop-in" replacement same as with ivy back then? Or new standards are comming with this? Thx!
At this point, we are not anticipating to have to develop a new rendering engine at this point, so it should be a more incremental effort than Ivy.
As an Angular developer you could expect new features and developer experience improvements. Also over time you’d see more of Angular used in popular consumer Google products.
I hate Angular with a passion. It's easily the most verbose, overly complex front end framework I've ever used which just takes the fun out of building web apps and make it a pure pain. I would rather work on a farm and shovel pig shit all day than work in Angular again.
My last job forced Angular on me, I quit after a while (not because of solely that reason) but I told them Angular was a bad choice and they chose to overrule me. Pretty funny now, they will have to endure the pain of migrating a large app which makes me feel good.
To offer a differing experience, I've been working in Angular for a couple of years now and personally like it quite a bit. I don't like frontend frameworks in general, but given the choice I prefer Angular over React.
I seldom see this opinion but I'm glad to read it. People complain about JSX on the React side but what on Earth am I reading when I see the templating language that Angular came up with? ngIf, ngBlah. Much worse than JSX, which is subordinate to JavaScript code, not equal. I also have been forced to use Angular at the workplace and it killed any fun making web apps had. People say Angular is great for enterprise because it removes the burden of deciding things, but this indicates an organizational problem being solved technologically. In other words: Never a good thing.
The template syntax of Angular isn't the problem most people have with it. It's the boilerplate, the forced OOP paradigm, having to work with observables even when they're not appropriate (thus having to understand "hot" vs "cold" observables), and up until recently, having to scatter each component across three different files. And to top it off, when the lack of expressivity is touted as a feature for taming complexity, that points to a development culture that doesn't sit well with me either.
You have literally never had to scatter each component across three files. From the first release of Angular 2, you had "single file components", with template, styles and js all in one file.
It does appear I was wrong about the "until recently" bit: Angular still doesn't have a single-file component format like Vue or Svelte. Of course you can stick templates in string literals (and IDEA will even treat them as angular templates). Just be prepared to escape your quotes I guess. The official tutorial still uses separate files, and the tooling defaults to them too.
Honestly the real shame is that IDEs don't present a more integrated UI for separate files, and that on the other hand in my Vue apps I still have to argue over the order of script/template/style sections. I guess Angular at least avoids that second problem.
Not as much in Jetbrains IDEs: it detects the string is HTML and highlighting, formatting, and mode-specific functionality all just work inside the string. In an Angular source file, all the template properties like "ng-if" autocomplete too, not sure if any code completion inside props works though (it doesn't with the AngularJS 1.x I just tested, but that's a different plugin that's probably less capable). Have to be careful about escaping the outermost quotes too if you use them in the template. So not exactly terrible, but still a little bit janky.
You could do that with angularjs 1.5 components too. But afaik it was/is not standard practice to embed html and css inside your js, because many (most?) editors treat html inside a string as a string instead of as html.
I didn't care so much about the syntax but rather the over reliance on the subscriber pattern that you have to have like a subscriber to even read something as fundamental as query params. And the funny thing is that is will fire once and then again when the query params is actually set. So you will have an empty fire for when they are not yet set for some strange reason, presumably from when the observer is created.
The problem with Angular, especially as the app grows is that you will have many different subscribers that all listen on the same state changes, then fire them again so you will have code that just runs again and again and it's extremely hard to have a mental model on how the system work and what code runs when.
The code also easily gets super slow because you run something, it affect state, then it triggers something else that triggers something else that just happen to affect the first state, whoops now you have a loop. Even if the loop resolves, it's pretty much inevitable to get a loop sometimes if the app is complex enough, at least in my experience working with several other devs.
Sounds more like a misunderstanding of the framework and observables. The problem many faced with angular is they chose not to learn observables, then got angry.
If you have different subscribers, all on the same state change, you may not have chosen to use ShareReplay, or filter, or bothered to use a tool like ngrx that has memoized selectors.
The same problem you're complaining about is the same thing people in the react community are complaining about because they never bothered to understand useEffect, and now have massive cascading updates.
There is a very good reason they chose to make everything a subscriber, and it helps avoid pitfalls, because it doesn't hide away the async nature of everything. Signals are just a simpler way to understand and use that same async nature.
Well perhaps, but I think it's so overly complex and verbose to the point that learning it and making sure that everyone working on the project is on the same level is hard or near to impossible.
I really tried to learn RxJS, I used a lot of different methods like filter and what not but I still got into a huge amount of issues but honestly a lot of that was because angular was not really fit for the type of application we were trying to build. Especially as we relied heavily on query params for state. There were many strange behaviors of Angular Router that I ran into several times. It has some kind of own internal state and fires updates in an unexpected way. I remember sitting hours just to try to get the query params to update correctly and I was not the only one having these kinds of issues.
Even if I agree useEffect is unnecessary complex, it's still far far away from being as complex as RxJS and Angular. I remember I was trying to add some pipe service or whatever it was called and it was near to impossible to achieve what I wanted to do which would be trivial in any other framework/vanilla JS (unfortunately I don't remember what it was).
Then using third party stuff in Angular is a nightmare as well. You have to deep dive into how it's being built to make sure all the stuff is brought into the build step etc. The configuration is a nightmare if you want to do something special like making use of Angular Elements that's barely documented at all.
I never got to use the Signals feature, because I left the company before it got introduced into Angular.
> the templating language that Angular came up with? ngIf, ngBlah
The new templating syntax is simply @if () @else () ... it makes it much clearer to read in many cases.
I never had a problem with *ngIf as long as you are controlling the visibility of one element. It became messy when you needed "else" statements in there.
I’ve hated working on every Angular project I’ve worked on. No matter the team, the experience level or complexity, it’s always been an absolute misery.
I cannot understand how it was invented/why it exists, how smart people at Google convinced themselves to use it. I cannot understand how they let it escape into the wild or even why those not forced to use it, choose it.
I know I’ve begged before for this, and it’s pointless, but please if you’re in the position to, please consider snuffing it out and starting over.
It's worse, everyone jumped from Angular to the React bandwagon. I use these types of things as litmus tests for if I want to join a new company/team. No sense in cussing under my breath all day every day. It's really hard to smile after you just invented a new vulgar phrase to describe mangled tech.
Agreed. I think the earlier days of Angular put a bad taste in many people's mouths. Many people who complain about Angular being verbose seem to only have experience working on smaller apps.
I suspect the migration effort will be fairly minimal. We recently migrated a bunch of stuff in a large codebase to use signals instead of observables and it was very straightforward. Couple of days for a junior engineer levels of straightforward.
I personally find Angular to be fine - sure there is a learning curve but that is true of anything (it's not like you can just pickup modern react and make anything functional without having to know how react works and spend ages picking libraries and installing and learning how to use npm, spending 6 months in a sanatorium getting therapy after realising you have to use npm for react and accept the shit show dumpster fire you are letting yourself in for by relying on npm, and deciding if you should use hooks or not and what about JS vs TS etc etc ). I find JSX in React an uncomfortable compromise that throws out a bunch of hard-learnt best practice in computer science (mixing up and confusing presentation with business logic in the same file). Separation of concerns is a good thing.
Angular will continue to be a solid choice for large professional outfits that care about things like maintainability, repeatable builds, dependency management, readability etc etc. Having Angular be the framework that powers websites like google.com and YouTube is just going to make it even more of a "no-brainer" choice than it already is if people are picking a web UI framework.
This seems to be true for many and happened to me. It is an absolute nightmare trying to upgrade Material. Now I’ve convinced my team to move to a different framework.
You can upgrade all the way to Angular 17 without having to adopt the new MDC components. Only this May with Angular 18 support for the legacy components will be dropped completely.
That’s the reason we’re currently migrating all our remaining usages of Material components to ng-zorro.
No but Angular 17 is backwards compatible with @angular/material@16 so you can upgrade Angular without having to upgrade Material [1]. We currently run @angular/core@17.0.8 and @angular/material@16.2.12 in production without problems.
In the end this only buys you another 6 months but helped us get ready for Angular 18 in May.
The announcement post for Angular 17 included a few sentences about this [1]
We deprecated legacy components in v15 to be removed in v17. Even though they’ll not be part of the Angular Material v17 package, you can still update your apps to Angular v17 and use the v16 Angular Material package. This will be an option until v18, after which Angular Material v16 will no longer be compatible with newer versions of Angular.
There are still issues with density not working well with some angular Material controls. This forced us to do some hacky css stuff. Some of the github issues have been open a long time now...
Angular is getting partial hydration (seems automatic from the keynote but it's not clear) and deferred views which are like components that don't load until something happens (eg entering the viewport).
Performance has increased considerably too thanks to the use of signals.
Honestly I'm quite impressed. I wish Svelte had partial hydration but the team keeps arguing against it.
We're not arguing against it, but simply haven't committed to doing or not doing it as Svelte 5 has been higher priority. We would rather be deliberative than introduce a feature where we don't have the developer experience fully thought out. We want to understand what the experience would be for Svelte users both with and without SvelteKit and have good guidance around the trade-offs of different rendering modes.
Can anyone recommend a good resource discussing the interplay between highly optimized js bundles and code caching? i.e. it seems to be me that one would benefit by serving the same js blob on most / all pages even if it includes unused code because then you pretty much always utilize the code cache.
Maybe I’m misunderstanding your question but why would you want a single bundle vs multiple bundles?
If you have a single blob you have to invalidate the whole thing when it updates. If you split your code out into multiple bundles you can invalidate only the bundles which contain changes. As far as I know this has been standard practice for the last decade at least.
I think it’s a good question, and the answer isn’t quite as straightforward as you suggest.
The advantage of bundling is that you can do cross-module minification and dead-strip unused code.
The extreme version of “multiple bundles” would be to minify each JS module individually, but don’t bundle them. That would clearly miss a lot of size optimisations. (And as I understand it, this is how Deno’s new package manager is meant to work, which makes me a bit suspicious.)
The opposite extreme of one bundle for the entire app is great for optimisation, but as you say, then you have to invalidate the whole thing if anything changes.
One bundle per route is tempting but then common code gets duplicated.
Vite’s default behavior (via Rollup) is to make one bundle per common module. That works pretty well but I’ve found the number of output bundles can explode in surprising ways. In a recent project I manually split the code into chunks and loaded them via dynamic import() and that worked pretty well -- good balance of size optimisation, caching and manual control.
I confess I wasn't thinking about a particular build tool. My recent experience has been with Vite, where I took a similar approach to what you describe, but haven't had to dig deep into bundle performance because that's not a bottleneck for our application. The last time I did deeper work on the subject was years ago with Webpack.
I thought Webpack at least did dead-code elimination before splitting things into chunks. If I'm reading this random GitHub issue[1] right (and the asker is also right), Webpack does partially behave as I expected, but the pre-chunking optimization pass occurs before things like constant expression evaluation.
This is probably some big hairy statistical optimization problem. 100 bundles across 1,000 routes. How to you pack up the 100 bundles into n (n<100) larger bundles such that average time to interactive is smallest. Of course, you get different answers depending on first time vs returning site visitors.
We have a single bundle of JavaScript with all our helper functions, then a page specific bundle that uses some of the helper functions. The same helper function bundle is delivered to all pages--not a different tree-shaken version delivered to each page that only has the functions used by that page. One helper function bundle is bigger, but since every page gets it, this bundle is code cached.
Bundling everything together and letting it be cached is how most single-page apps do it, yes. If the code isn't used by anything at all, it gets removed from the bundle entirely: that process is called "tree shaking". Modern frameworks like Nuxt also tend to do something called "code splitting": for example, I have a Nuxt app that contains, among others, pages like /vehicles, /drivers, and /fuel. Instead of creating a single giant js bundle, Nuxt creates several, including a file for code that's used by just the /vehicles page, a separate chunk for code that's only for the /drivers page, and so on, along with common chunks that are used by all of them. Script tags are then generated for each of these three pages so that when you hit one of the pages, you only get enough of the code for that page, and the rest is loaded when you navigate to another page. It's still a single-page app, but with multiple entry points, each one optimized to initially load only what that entry point needs, the rest being dynamically imported when needed. Each bundle's filename contains a hash of its content, so they can be cached forever (that does have consequences when upgrading though: a typical SPA has to do some some version checking and self-updating on its own, as the browser will otherwise be eager to serve stale code)
In dev though, one usually doesn't even bundle, and runs the app on a dev server that dynamically compiles and serves individual modules. When I initially load the app off the dev server, my browser makes close to a thousand requests for all those modules, but pipelining and caching make it all quite zippy regardless. Bundling is still faster and uses less bandwidth though, so for production one typically does still build a bundle (or several code-split ones).
There's gory details at https://webpack.js.org/guides/code-splitting/ (for webpack; other bundlers like Rollup work similarly) but frameworks like Next/Nuxt do it automatically as part of the build process.
Ugh, this isn’t Angular anymore. This will be just like the v1 -> v2 transition. Presignal -> signal. The second they start deprecating the previous syntax, we will hit very difficult migrations
There is a pretty usable migration tool built into Angular CLI at least for switching over to the new template syntax. Requires some manual cleanup here and there but overall it’s not painful at all.
Apparently another Google web framework... I had never heard of it, but I know this company called Wiz and thought it may be related for a second: https://www.wiz.io/
I hate to say this, as I'm generally optimistic towards most developments like this, but over the last decade I've become so apathetic towards anything and everything from Google. They've lost so much mindshare and credibility. Their org structure leads to stagnation left, right and centre.
I'd rather tolerate the poor status quo in React land than take any sort of bet on Google getting something "newish" right.
Everyday that Sundar is still CEO leaves me more and more bewildered. I cannot figure out how Brin and Page (who together own voting majority) look at google of 2024 and say "Yup, this is what we want Google to be".
The goal of a public company is to increase shareholder value. Hard to argue that Sundar hasn’t done that. Revenue has increased 5 years straight. Market cap with the exception of a dip during Covid is strong and is approaching its all time high.
As a Goolgle user and long time admirer, there have certainly been some disappointments and mistakes over the years. But there’s also been some major accomplishments which people sometimes overlook.
While still early, Waymo seems to be on the right trajectory and may be a key player in autonomous vehicles. Let’s not forget Googles work on transformers, which is heavily responsible for the current AI boom. That’s just two that come to mind, I’m sure there are others. Maybe these were started before Sundar, but he’s been CEO for almost 9 years now. So he gets credit.
Google may have some culture challenges to work through, brain drain, and identity issues. But I don’t think their story is written just yet. With a giant stock pile of cash they have plenty of time and resources to buy or figure their way out of any perceived issues (if that’s even what they need to do).
Microsoft did it. And if you really want to have your mind blown, go take a look at IBMs stock chart. I didn’t expect to see it approaching an all time high.
What choice can you point to that has increased Google's market cap? Google's search quality is deteriorating, Waymo is yet to make a profit, GCP is struggling, "Attention is all you need" was too early on to credit Sundar, and since then Google's reputation is flagging due to embarrassing AI models...
I think Google's market cap is increase _despite_ Sundar, not because. That said, Google does have enough resources to turn it around, I just don't think Sundar is the right person to do it.
GCP is struggling? Is that an opinion based on experience or based on actual stats? Because GCP revenue has increased every year since 2017. AWS and Azure are capturing more market share. But I’m not sure I consider third place and $33B in revenue last year a struggle.[1]
> I just don't think Sundar is the right person to do it
That was sort of my point. Does Google need to be turned around? All stock metrics and revenue metrics show that they are doing well as a company.
Sure the AI model stuff was embarrassing. But it doesn’t seem to be having an impact on the value of the company. Maybe goodwill was hurt. But if we’ve learned anything from the Meta drama over the years, people will be quick to forget about it. I don’t think a few fixable and public missteps like that will sink the company. Does anyone outside of tech even know about it? It’s possible it’s indicative of a larger internal issue thats brewing. But it’s not impacting the value of the company… yet at least.
Google Cloud Platform's growth is slowing [1]. It's finally profitable, but I don't think distant third place is what Google was looking for after 10 years of pouring billions of losses into it.
At the time of this news, Google's stock fell 5 percent, so it is hurting company evaluation, at least temporarily.
Google's stock might be rising, but what is causing that? I can't point to any material success of Google in the last 10 years to explain it, seems to me Google is coasting.
Google is in the familiar position where there numbers are good, the charts are all pretty, but when you go put your ear to the ground, you only hear sounds of trouble.
If google had proper leadership, the company would easily be worth twice it's current value. Easily. Instead we have a situation where raw capitalist inertia is carrying the company forward, while active discussions of the company are ridden with grievances and frustrations. Grievances and frustrations in a market where there are competitors that users can flee to. It's a bad spot to be in.
There is no reason Google shouldn't be the ones on the cusp of releasing GPT-5 level LLMs. None. Instead however they have a middling LLM that is scared to mention white people. So back to the drawing board so they can work out the racial kinks, while the competition blasts past them.
Google needs big company technology focused leadership 5 years ago. But tomorrow would be good too.
You make a good point about the possibility that they could be even more successful with stronger leadership and product focus. I can’t argue with that and don’t disagree.
My points were focused on the fact that the data just doesn’t currently show Google failing or declining as a company.
It’s going to be really interesting to see how the Google AI strategy plays out. I agree that they could have absolutely been the leader. They had the money, resources, and ingredients to make it happen.
I believe that AI is a threat to their current business model. How much did that influence their investment and focus on it?
There are several features that can be considered neat on their own. Most of those features are probably derived from other languages, but together they form a very powerful language that simply takes away the pain that I feel using other modern languages, such as C++, Python, Java and NodeJS.
Here are a few on top of my head:
1) CSP concepts embedded deeply into the language (goroutines/channels/select) making concurrency easy to do correctly
2) Standard Library and Go toolchain providing everything that most languages use third party libraries for (formatting, testing, benchmarking, fuzzing, HTTP, crypto, etc...)
3) Compilation into a static binary that can just be copied from machine to machine without any dependencies whatsoever (even C struggles with that on Linux, due to glibc NSS fiasco)
4) Cross-compilation by changing two environment variables
5) Minimalistic distribution system - just write `import "github.com/person/repository"` - no need for packaging, pom.xml, requirements.txt, package.json, etc.
6) Interface-based modularity (structural typing), making code reuse much easier than the usual OOP-style abstract-class based modularity (nominal typing)
7) Extremely fast compilation, which makes read-modify-run development loop as fast as with interpreted languages
If your post is intended to be a remark on how nothing in Go is "revolutionary", please read the first paragraph of my post, and notice how there isn't a single language in your list which is in all 7 categories.
Additionally:
- Erlang does not implement CSP, it implements Actor model
- Java does NOT have all the listed features included in its default toolkit - hence the existence of Gradle, Maven and all other packaging/testing/benchmarking solutions
- The "until mid 1990's" is the keyword here - I'm talking about modern languages and I explicitly pointed that out
- ACT is not part of any language, it is an external tool that may or may not be reliable, but definitely does not have toolchain/standard library level of quality/stability guarantee.
- "Until the repo changes" - packages can disappear from any system, see leftpad incident
- "forbids distribution of binary libraries" - not true, see [0]
However, if I have misread your tone, and your post was intended to be an informative list of languages Go was inspired by, then thanks for the information. But some of it is misleading or false.
My opinion on Go's "innovation" is well known on HN, and gonuts back when I cared pre-1.0.
I could go over those points, one by one into detail, including Russ Cox point of view on disabling binary distribution, but not feeling motivated to press the further the wound.
I have no idea who you are nor do I care about internet pseudocelebrities, sorry. Your opinions, to me, are just words from a random stranger, whose merit is only insofar as I can learn something new from them.
> and notice how there isn't a single language in your list which is in all 7 categories.
Implementing, sometimes quite poorly, all 7 categories does not a revolution make.
Golang looked at the past 60 years of programming evolution and decided it needed almost none of it, and ignored any developments in programming languages of the past thirty years or so. This is not revolutionary. It is, at best, reactionary.
The way concurrency works is pretty unique amongst mainstream languages.
Java has just copied some parts of how concurrency works in Go, but that's nearly 20 years after Go was released.
It's extremely easy to start up code concurrently with "go foo()". You can start up lots of such functions concurrently, as it works in userspace. Like async code, but no "colored functions" problem.
It's not the case in C#. It is discouraged, but mainly because there just used to be so much sloppily written async code that managed to bring down threadpool to its knees despite hillclimbing and blocked threads detection doing a lot of heavy lifting, so the community has grown scar tissue against this. It's rarely an issue if ever in the last 5 years or so.
Exactly, but the Go team appears to have the exact opposite mindset as Google product managers. They care about maintaining a product and compatibility, without major API revisions. They appear to care about first principle engineering, not "let's make a new product!".
Okay, watching this video, and they just infantized their audience "if someone makes you uncomfortable, come find a staff" as if the conference goers aren't adults. That makes me really uncomfortable that they think adults can't handle themselves and work things out.
It was mostly always like this. You might go back further, but since 2008 I've been dealing with google snake-oil. They sold a customer I worked with a "search appliance" in 2007 that was more or less a paperweight. They packaged up "commodity hardware" in a fancy yellow google case and overcharged this military unit out the ass for what was a half-assed map-reduce algorithm with no security and no means of compartmentalizing the data that was stored on the appliance. This was years before the elk-stack. I can still distinctly remember the commander - an old special forces guy - telling the google-rep that he wanted to do a Roshambo game (Cartman nut kicking contest). A year or so later I cracked open their case and saw that they'd essentially packaged up an old dell poweredge 6K series with slow magnetic drives (and raid-5 lol). Maybe that fly's if you'd chained fifteen of these things into a cluster but that's not how they sold them to their customers. Google is a dishonest company filled with immoral lechers.
Google was too innovative and successful to use external consultants and so the consultants joined the company as employees and did it from the inside!
Google today feels like Nokia of the mid-2000s. Victim of its own massive success, taken over by internal politics and divisions. Employs lots of smart people who figured out key ideas for next-gen tech early, but the organization is unable to take any of those innovations to market. And so it’s just stuck milking its cash cow.
Google’s AI strategy is as clear as Nokia’s smartphone software strategy was.
They took some of the best brains, spoiled them with high salaries and glory and took their best years to make them work on dumb problems and projects that were cancelled at various stages of their life.
Those best brains did produce lots of interesting things, back in the day (not recently). The Google search algorithm, the ads auctioning system, Gmail, Golang, certain parts of Google Cloud like BigQuery (create relational tables, just stuff data in there, just scales by itself without "provisioning", write SQL queries including joins e.g. over hundreds of billions of rows...)
In this case I spent 5 minutes trying to find a different source but the tweet thread is the best I could find unfortunately. There is no official blog post afaiu.
i checked them, but libredirect removed the twitter option from the config menu (i guess because of the changes in the twitter api) and the other just a generic url to url redirect. but thanks anyway
At least they'll be dogfooding Angular now hopefully.