Google: Angular and Wiz Are Merging(twitter.com)
twitter.com
Google: Angular and Wiz Are Merging
https://twitter.com/sarah_edo/status/1770478763253379488
178 comments
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. 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?
Here's Youtube's extreme performance: https://twitter.com/dmitriid/status/1770911027766370648
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?
Here's Youtube's extreme performance: https://twitter.com/dmitriid/status/1770911027766370648
The engineers congratulating each other on writing slow, awful bollocks reads like AI-generated NPCs in a real bad video game.
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.
Yea, but look at how fast that 11MB loads.
lol. lmao even.
Any tips on preparing to work with Wiz as an incoming intern. I heard its identical to Stimulus: https://stimulus.hotwired.dev/
There is also AngularDart, which is a fork. But it’s been a while since I left Google and I don’t know how much it’s used nowadays.
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.
I thought some teams at Google were dogfooding Angular for many years now?
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.
Any tips on preparing to work with Wiz as an incoming intern. I heard its identical to Stimulus: https://stimulus.hotwired.dev/
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.
Lots have been [0,1]
0, https://changelog.com/jsparty/310
1, https://changelog.com/jsparty/312
0, https://changelog.com/jsparty/310
1, https://changelog.com/jsparty/312
Yeah. I distinctly remember Google using it itself a big motivator to go with AngularJS and then Angular in side projects, so I was not wrong...
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
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
> My job skills are languishing at google because I’m writing Wiz and Angular all day
Do people actually spend months prepping for Leetcode interviews to get the job? To improve tech skills? Or is it just the money? ;)
Do people actually spend months prepping for Leetcode interviews to get the job? To improve tech skills? Or is it just the money? ;)
Any tips on preparing to work with Wiz as an incoming intern. I heard its identical to Stimulus: https://stimulus.hotwired.dev/
For years I’ve been saying “Angular is the wrong choice now but it will be the right one someday…” I didn’t think it would take 5 years to get there.
The Angular team has been doing incredible work lately.
The only thing that I still don’t like about Angular is trying to learn anything from the reference 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
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.
The Angular team has been doing incredible work lately.
The only thing that I still don’t like about Angular is trying to learn anything from the reference 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
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
Like this?
- https://angular.io/guide/hierarchical-dependency-injection#u...
- (new docs site) https://angular.dev/guide/di/hierarchical-dependency-injecti...
Like this?
- https://angular.io/guide/hierarchical-dependency-injection#u...
- (new docs site) https://angular.dev/guide/di/hierarchical-dependency-injecti...
Exactly my point.
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.
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
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
First, create an AnimalService with an emoji property of whale
You can leave all the FlowerService related code in place as it will allow a comparison with the AnimalService.
You can leave all the FlowerService related code in place as it will allow a comparison with the AnimalService.
[deleted]
Yeah it’s not great, but they do both show up as results via search.
What makes it the right choice in your opinion?
Not as exciting as the title might imply.
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.
[0] https://youtu.be/nIBseTi6RVk?t=4790
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.
[0] https://youtu.be/nIBseTi6RVk?t=4790
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.
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.
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.
Your post touches too many topics.
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.
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.
I hate to be THAT GAL, but... try Svelte! I love it more than Vue.
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.
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.
Question (you might need to pass this one up the chain of command):
Was basic HTML gmail deprecated because users so overwhelmingly preferred slow, bloated UIs that there was no demand for an alternative?
Was basic HTML gmail deprecated because users so overwhelmingly preferred slow, bloated UIs that there was no demand for an alternative?
We’re building infrastructure for these products rather than the products themselves.
I’ll be happy to answer questions about Angular and our collaboration with Wiz :)
I’ll be happy to answer questions about Angular and our collaboration with Wiz :)
If those products end up bloated and slow, perhaps, some blame can be placed on the tools, too?
Maybe that's justified, but it's just as likely that it's not.
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...
[deleted]
What are specific "innovative approaches to perfromance" is wiz bringing?
Even though it's claimed that it powers many of Google's websites, most of those websites are very far from being paragons of performance.
Even though it's claimed that it powers many of Google's websites, most of those websites are very far from being paragons of performance.
It introduced very fine-grained code loading on interaction and something the community refers to as resumability.
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.
Other sites like Photos are fast and performant, but I wonder if it's due to whatever perceived advantages of Wiz or due to the team actually caring: https://medium.com/google-design/google-photos-45b714dfbed1
Edit: replaced incorrect link with a correct one
Other sites like Photos are fast and performant, but I wonder if it's due to whatever perceived advantages of Wiz or due to the team actually caring: https://medium.com/google-design/google-photos-45b714dfbed1
Edit: replaced incorrect link with a correct one
Performance always needs to be a priority for a team to hit satisfying metrics.
Wiz is designed to make it harder to get bad metrics if performance is not your top goal.
Wiz is designed to make it harder to get bad metrics if performance is not your top goal.
> 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?
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?
Merging is the ultimate goal! Both teams are already working closely together on shared designs and specific implementations.
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.
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’m more familiar with Preact Signals. How does Angular Signals compare?
Fundamentally they are similar to Preact Signals, Solid Signals, Vue signals, etc.
We took some different trade-offs and listed the details here https://github.com/angular/angular/discussions/49683
We took some different trade-offs and listed the details here https://github.com/angular/angular/discussions/49683
Anyone has any non video source with more info on this?
We’re going to share a blog post with more details in the next couple of days.
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.
Make stupid choices, win stupid prizes.
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.
Make stupid choices, win stupid prizes.
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.
Angular was made for you, basically. I've always seen that as the use case.
It never seemed suitable for mostly-frontend devs, but it's probably perfect for mostly-backend ones.
It never seemed suitable for mostly-frontend devs, but it's probably perfect for mostly-backend ones.
Yeah, that makes sense I suppose. My Java background also means the verbosity and structure doesn't bother me much.
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.
Similar conversation 10 months ago:
https://news.ycombinator.com/item?id=35811256
Similar conversation 10 months ago:
https://news.ycombinator.com/item?id=35811256
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.
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.
Isn't dealing with bare string literals for HTML-like syntax a terrible developer experience?
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.
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.
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.
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.
That's the problem, you have to learn all that crap. Excuse me, you have to hold it properly.
> 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.
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.
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.
Why did you hate working on every Angular project?
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.
So React is equally bad in your view? If so why?
What do you use?
What do you use?
I've been working with large Angular projects for years and I really enjoy the development experience.
Especially now with the new template syntax, signals, and other recent changes.
Especially now with the new template syntax, signals, and other recent changes.
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.
[deleted]
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.
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.
I hear most Angular projects being stuck at around version 15 due not being able to migrate away from Angular Material "Legacy".
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.
That’s the reason we’re currently migrating all our remaining usages of Material components to ng-zorro.
They previously announced [1] these would be removed in v17, did that change?
[1] https://blog.angular.io/angular-v16-is-here-4d7a28ec680d
[1] https://blog.angular.io/angular-v16-is-here-4d7a28ec680d
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/[email protected] and @angular/[email protected] in production without problems.
In the end this only buys you another 6 months but helped us get ready for Angular 18 in May.
[1] https://blog.angular.io/introducing-angular-v17-4d7033312e4b
In the end this only buys you another 6 months but helped us get ready for Angular 18 in May.
[1] https://blog.angular.io/introducing-angular-v17-4d7033312e4b
Where did you get info for Angular 18?
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.
[1] https://blog.angular.io/introducing-angular-v17-4d7033312e4b
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.
[1] https://blog.angular.io/introducing-angular-v17-4d7033312e4b
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...
After angular17 came out, my project has been upgraded from v11 to v17. I don’t think there are any problems.
This is great.
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.
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.
> We're not arguing against it, but simply haven't committed to doing or not doing it as Svelte 5 has been higher priority.
Please. This discussion has been going on for years Ben. Even before SvelteKit or Svelte 4 existed.
Please. This discussion has been going on for years Ben. Even before SvelteKit or Svelte 4 existed.
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.
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.
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.
Thanks for the thorough reply!
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.
[1] https://github.com/webpack/webpack/issues/16672
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.
[1] https://github.com/webpack/webpack/issues/16672
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.
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.
I hate wiz. But maybe having a public facing user base will force basic usability.
Any tips on preparing to work with Wiz as an incoming intern. I heard its identical to Stimulus: https://stimulus.hotwired.dev/
This is not Wiz the web builder product you know about. It's an internal framework used by Google.
It's hard to ask this without sounding like a jerk: does this matter to anyone externally?
When I was still at Google, the web dev I knew who was in touch with outside stuff, talked about Angular as if its day had passed
When I was still at Google, the web dev I knew who was in touch with outside stuff, talked about Angular as if its day had passed
Angular is my favorite framework among the front-end frameworks I use.
I wasn't even aware Wiz exists!
I hope someone manages to extract Wiz out ouf Angular later on.
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
We just got done porting everything from AngularJS to Angular D:
A joke or really? At this point, I would just port it into Svelte, it is the same amount of effort anyway and it has been so long!
We started the transition years ago; large codebase to port. Trust me, if it was my choice it wouldn't be Angular. I trust no google product.
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.
How "not painful" would it be for a codebase with thousands of files, hundreds of which are widgets?
Angular I know… but what the heck is Wiz?
It’s the internal framework they use for Search and YouTube. I’ve heard of it from Xooglers but besides them I don’t think it’s well known.
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/
No relation.
Exciting? Possibly for those involved.
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.
It wasn't always like this.
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.
It wasn't always like this.
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.
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.
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.
[1] https://www.statista.com/statistics/478176/google-public-clo...
> 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.
[1] https://www.statista.com/statistics/478176/google-public-clo...
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.
https://www.reuters.com/technology/google-parent-alphabet-re...
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.
https://www.reuters.com/technology/google-parent-alphabet-re...
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.
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?
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?
Imagine having the talent and money of Google and accomplishing essentially nothing in ten years, but collecting 200 million a year.
I agree as someone who has spent the past decade working in Angular all day and then React. And I don't love React.
Golang is one of the Google products that I consider revolutionary in programming.
But then again, it may just be because they employed the rockstars (Rob Pike, Ken Thomson, and Robert Griesemer) to work on it.
I suppose it's less about the company, and more about who the company chooses to work on the project.
But then again, it may just be because they employed the rockstars (Rob Pike, Ken Thomson, and Robert Griesemer) to work on it.
I suppose it's less about the company, and more about who the company chooses to work on the project.
I hear "revolutionary" claimed about languages like Rust, Haskell and Zig, but rarely about Go. What about Golang is revolutionary to you?
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
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
1) Modula-2, Active Oberon, Erlang
2) .NET, Java, Smalltalk, Common Lisp
3) Any compiled language until the mid-1990's.
4) Amsterdam Compilers Toolkit, 1980
5) Until the repo changes, forbids distribution of binary libraries
6) Standard ML, Caml Light, OCaml, Haskell,...
7) Turbo Pascal on CP/M, MS-DOS computers running at 7 MHz, with 640KB.
2) .NET, Java, Smalltalk, Common Lisp
3) Any compiled language until the mid-1990's.
4) Amsterdam Compilers Toolkit, 1980
5) Until the repo changes, forbids distribution of binary libraries
6) Standard ML, Caml Light, OCaml, Haskell,...
7) Turbo Pascal on CP/M, MS-DOS computers running at 7 MHz, with 640KB.
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]
[0] https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGh...
---
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.
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]
[0] https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGh...
---
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 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.
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.
Topics where Go has failed:
- No tail call optimization
- No meta-programming
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.
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.
Actually Java brought back the green threads model that it had before Go came to be.
The difference is that now red and green threads are exposed at the API level, and not an implementation detail.
Hardly copying Go.
The difference is that now red and green threads are exposed at the API level, and not an implementation detail.
Hardly copying Go.
> but that's nearly 20 years after Go was released.
Go 1.0 was released in 2012.
Go 1.0 was released in 2012.
Quoting "colored functions" is a problem of skill. It is a tell of engineer's lack of understanding of concurrency.
Can you please elaborate why?
The concurrency model basically came from Erlang, which in my opinion does it better.
Colored functions is only a problem in JS
And Python... And Rust... And C#...
And C#, Python, Rust...
You can de-color an async function by blocking.
In most implementations, blocking in an async function has unintended side effect of blocking all other async function running on the same executor.
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.
[deleted]
[deleted]
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.
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.
I fail to see in what sense.
It is basically a revamp from those rockstars previous efforts (Limbo and Oberon based dialects).
It is basically a revamp from those rockstars previous efforts (Limbo and Oberon based dialects).
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.
[deleted]
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.
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...)
Don't forget Google Wave.
May 2010 - August 2010.
https://en.m.wikipedia.org/wiki/Google_Wave
May 2010 - August 2010.
https://en.m.wikipedia.org/wiki/Google_Wave
Off topic, but is there any chance to avoid sharing Twitter links? Would rather not log in to the site
+1 rage against walled gardens
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.
Why not post a direct link to the video that the tweet embeds?
I have considered this as well but the video is a whole keynote about various things. Was not an easy decision.
i'm with you, i used to use nitter with the firefox extension, but it seems to be dying, is there any alternative?
There is https://twstalker.com/ but the site is very very dodgy.
thanks, maybe that will become something later, but i am looking for an browser extension that doing the work for me
Maybe one of these:
https://libredirect.github.io/ https://einaregilsson.com/redirector/
Note the site I linked is very dodgy, so probably not trustworthy.
https://libredirect.github.io/ https://einaregilsson.com/redirector/
Note the site I linked is very dodgy, so probably not trustworthy.
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
You can easily add twstalker to the generic one.
[deleted]
At least they'll be dogfooding Angular now hopefully.