For me personally, I feel like a lot of tech companies are bloated and a lot of people are justifying their salary by doing unnecessary projects.
In many cases, it's all internal and no skin off noses such as this font project. In other cases, it means the UI changes every 4 to 6 months or even worse, the software becomes so bloated with "features" it becomes unusable so a clean replacement comes on the scene then the cycle repeats.
Sometimes, I feel, it would be better for companies to clap their hands and go "We did it, we solved the problem" then just stop. Keep the infrastructure running, do bug fixes, listen to customers on new features or changes but otherwise not do product churn for the sake of justifying salaries.
To expand on my view in an abstract way, when constructing a building construction workers, architects, project managers, and the whole cadre are hired then the building is built then all those people move onto new projects. Continual development of software is like if construction never stopped so that the construction crew still had jobs. A construction site should strive to transition from architects, cranes, and concrete trucks to maintenance staff, mop buckets, and screw drivers.
> And it sounds like it saves money on commercial font licensing.
Nebula Sans is a derivative of Adobe's Source Sans which is available to use for free for any purpose include commercial under the SIL Open Font License (the same license Nebula Sans has to use as a derivative of Source Sans).
So they could have just used Source Sans for free and virtually nobody but the most dedicated font nerds would have known the difference between that font and Nebula's tweak of it if not for the PR announcement.
All that said, I don't care what Nebula spends their money or time on, so I'm not saying they shouldn't have had this font made... but doing it wasn't a money-saving move.
So in other words, right now you have free choice between Claude and Codex and developers are choosing Claude of their own free will, but you want management to come in and force people to use Codex instead?
If it’s so much better, developers will switch. Lots of devs at my company have switched recently. But plenty of others have stayed on Claude.
I don’t think one is clearly better in every way right now. Or at least not better enough to make people want to learn and set up a new tool.
Is there a net benefit that you see, ignoring the fact that you're no longer dependent?
I've stopped a half dozen times, for around a month each time, but I found that I like the way my brain functions with coffee. The risk of a headache seems like a net win for me, in the grand scheme, especially since I try to do what I can to reduce the risk of dementia and Alzheimers.
I constantly hear coffee drinkers say how much they drink with shame and that they should cut back. It's one of the most common things I hear when someone is talking about their coffee consumption.
Personally, I stopped drinking caffeine when I was around 19 after I figured out it was the source of my chronic headaches (from withdrawal). I had to talk my dad out of taking me to a neurologist at one point in high school. My quality of life went up significantly after cutting caffeine and going through the week-long headache.
I can’t speak for them, there are a variety of reasons they might lead to it. But I do see shame/regret being the emotion.
An example could be that they don’t like admitting how dependent they are on it to function. Reading between the lines, this is vibe I pick up most. Some others in the comments have stated this explicitly as true for them as well.
Coffee (caffeine related products really) from my understanding seems to harshly impact deep sleep.
If you are asking in good faith (which I hope you do because its HN and we are curious people, aren't we!), I recommend looking at r/decaf for seeing people's experience that they are sharing regarding it.
Also upvoting @bossyTeacher comments and re-sharing the good points that they have made:
Interesting, as far as I remember, those effects did not show up in studies (yet?). But it's been years since I looked it up on examine.com which was mostly free back then.
Whether you consider all of them not "bad" or worth the benefits is up to you. People also consider moderate consumption of alcohol worth its benefits.
Everyone has a different risk profile. Know the risks and choose as you please.
Your sure those effects have manifested in studies for moderate caffeine consumption?
Maybe the general consumption went up over the years. I think around 200mg per day was considered safe? That would be around two European-sized drinks.
Already models have gotten really good at a lot of things.
A lot of people would probably be happy to stick with the same model for a year or two if it’s 10x faster and cheaper.
And perhaps older models can become cheaper over time as newer models come out on new silicon for a higher price. That incentivizes people to stick with older models.
Right, but the point is that you can't conclude that a model is necessarily bad because it's not hitting the same scores on benchmarks. I just don't agree with lacker's conclusion, because their logic doesn't seem to consider that. Scoring lower on a benchmark doesn't strictly mean they have a bad model, but it may be the case. Like you said it's one data point, but being the easiest, and obviously most gamed, means you should probably weigh them less heavily.
That’s over half of their business, but they do have some diversification with YouTube, Play Store, and cloud services.
Some of their newer efforts like Waymo and AI hosting for Apple could turn into large businesses to make up for any lost search revenue.
They also have significant costs to maintain their search revenue, such as $20B a year to Apple alone to make Google the default search engine in Safari.
If search becomes less lucrative, they would presumably pay less for such deals.
So yeah, definitely a time of disruption for Google and they need to keep moving fast on many fronts, but they are still well positioned in multiple markets to be successful.
Curious to see how long that lasts - YouTube and Google Maps were fairly mainstay apps for iPhones for a while, and eventually Apple cut the Maps cord to do their own thing. I don’t know if that’s from an existential concern of “we need to eventually move Maps in-house”, but given the Google of it all I wouldn’t be surprised if Apple is already at least planning on how to do the same with AI once the bulk of the usage evens out i.e. let someone else worry about it now while also getting a read on what rolling their own would feasibly require.
To me it looks like he’ll be in a position to actually be unhobble DeepMind - reminder DM was sitting on a ChatGPT product for a whole year before ChatGPT got released (LMChat) and Google didn’t let them release it.
> DM was sitting on a ChatGPT product for a whole year before ChatGPT got released (LMChat) and Google didn’t let them release it.
Heard this multiple time, to me this is pure history rewriting and post-rationalization.
OpenAI also had a internal chat app before chatgpt, Microsoft had multiple, a bunch of other players also had internal chatgpt equivalents + many startups built some using OAI API.
The breakthrough of ChatGPT wasnt because OAI were the first to think of that (absolutely obvious and basic) product, it was because they were the first to get a model strong enough to be actually useful to talk to, vs a mere fun novelty.
There is no evidence whatsoever that DM ever had such a model that they decide not to talk about/release.
Ok, and what if you realize you want these things a million lines in? Do you still move off of Go?
Generic programming isn’t some fancy research language feature like dependent types. It’s just a bare minimum feature in any modern typed language.
It’s perplexing that after C# and Java both notably shipped without generics initially then added them later that they decided to ship Go without generics.. only to end up adding them later.
I guess it's possible that C# and Java taught the wrong lesson (you can add this later) and that actually reduced the impetus to ensure Go shipped generics in 1.0
It is also entirely fair to say there's a lot of complexity here and so there's a risk you exceed your complexity budget which for Go as I understand it was very slim. It is a possible a Go 1.0 with more generics doesn't take off because too many people bounce off the extra complexity and so a decade later it's an obscure thing Google made once that has a few fans but not much adoption.
Or that extra complexity means Go 1.0 ships five years later, after Rust 1.0 has given people an appetite for better performance and better safety and its sharpest corners have already been knocked off.
From what I've seen, I don't think the core Go team was ignoring the lessons of Java or C#.
Here's a sample quote from Russ Cox from 11 years ago on this site: [1]
We have spoken to a few true experts in Java generics and each of them has said roughly the same thing: be very careful, it's not as easy as it looks, and you're stuck with all the mistakes you make. As a demonstration, skim through most of http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.ht... and see how long before you start to think "was this really the best way to do this?"
And of course, they asked other experts for help, including Philip Wadler (of Featherweight Java and Haskell fame): [2] [3]
We’ve been thinking about generics since work on Go began, and we wrote and rejected our first concrete design in 2010. We wrote and rejected three more designs by the end of 2013. Four abandoned experiments, but not failed experiments, We learned from them, [...]
Last year [2018] we started exploring and experimenting again, and we presented a new design [...] and we’ve been working with programming language theory experts to understand the design better.
FWIW, C# generics are way better (ergonomics) than the Java ones (due to type erasure), so Java waited too much. History is more complicated though for Java, since it was either having some generics vs having none. See [this](https://softwareengineering.stackexchange.com/questions/1766...) for a lengthier discussion.
Yes, .NET had the benefit of coming second and using F#, which was originally essentially OCaml 4 on .NET, as it's testing grounds. Same for Async
I am considering .NET for one of my compilers backends because of the reified generics. .NET can even pass around an object with generic methods that get specialized via JIT at runtime each time it sees a new data type (with reference types sharing implementations). Which also ties back to having true value types
It's a shame it took so long for .NET core to come around because even today the platform carries a reputation for being windows first which hasn't really been true for many years now
People always forget this other post when arguing for the home team.
"They are likely the two most difficult parts of any design for parametric polymorphism. In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier."
It doesn't seem particularly damning to me, though, especially written by Russ Cox in hindsight. It's almost a truism that if you had spent less time on approaches that didn't pan out and more time on approaches that did eventually pan out, you likely would have arrived at a workable solution sooner.
For example, if the core Go team had spent more time exploring C#-like approaches (as some suggest they should have), it's possible that would have delayed the whole thing.
(btw, consider me a "long time listener, first time caller" -- I pretty much always pause to read your comments while flicking through discussions here, including I appreciate you often bring in historical context, even if I might have a different take, or even if I might have expressed your take differently ;)
I'd welcome the ternary conditional operator but I hope exception handling never gets introduced (at least as I'm used to it from Java, C#, JS, etc.).
Exceptions should not be conflated with regular error handling, especially when they're allowed to bubble up from anywhere. I very much appreciate that functions that can return errors force the caller to deal with them, for the most part. True exceptions can already be thrown with panic, although I actually find it incredibly rare that I need to reach for that tool. I'd argue that when people talk about exceptions they almost always actually want "unhappy path" error handling.
Now, if Go wanted to add a sleeker way to handle those errors, similar to Rust's approach, I'd be very interested. Minimum three lines for every call to a function that returns an error does get a bit verbose, arguably hurting readability. A little sugar could improve readability without making error handling implicit.
Usually, if you're in microservices land, it's often possible to spin off a separate service and move the part that has different requirements over. Obviously that isn't always trivial, but service boundaries at least give you that option.
I had a team convinced that a particular subsystem was a mess and that they needed a stronger type system to build it properly because Go would just lead to hacks. They built a better one in Rust, deployed it, and moved traffic over.
Ditto, to some extent, if you're building desktop applications. Many large desktop applications already have multiple components or processes under the hood, and if you're at millions of lines, introducing that complexity may be worth it.
However, not all programs fit the above category. Sometimes you really do need a single lightweight binary and it needs to do a lot of stuff. But I think it's relatively uncommon to need one single binary that is simultaneously very large, architecturally diverse, and unable to delegate substantial complexity to other processes or services.
I see this most in the Kubernetes world, where something that starts as a simple binary gradually increases in scope and complexity. I've seen vendors struggle to keep up and start playing whack-a-mole with that complexity, but generally Go still scales surprisingly well here. Outside of K8s, there are also domains where you may strongly prefer a single-process or single-binary application, such as edge computing or developer tools.
Luckily, products where Go excels in these spaces also tend to have a natural upper bound on their domain complexity, because the operating model is generally about doing one or a few things well.
If Go's type system actually starts fighting you rather than merely being an inconvenience, then yeah, I would seriously look into moving off Go.
If you're working in a space that doesn't fit any of the above, I'd genuinely be interested in hearing about what you're building.
So your argument is that they should have gotten it exactly right first time and stuck to their guns?
I mean come on. The Golang team created a useful language people use for building real things — it’s easy to work with especially on large teams, and when the lack of generics turned out to be a pain point in the end (after years of production reality) they understood what the community wanted and actually… added them..
Now what, it’s not good enough?
No one forced you to use go.
No programming language is perfect. I personally find the language has served me well.
And after being so very pro generics myself, i actually find myself not even really using them that much apart from calling the slices module etc which has them under the hood anyway…
Nope, I’m saying that the language that was seemingly designed with either an ignorance of or disdain for the hard-won lessons from decades of prior programming languages.
There was even this condescending attitude that Google engineers couldn’t understand fancy languages anyway, so they had to dumb Go down.
My criticism really isn’t even about Go itself. Yeah it’s improving, which is great.
My criticism is about this anti-intellectual attitude that has permeated the entire Go community since its inception. It’s like hearing that college is a waste of time from people who never graduated high school.
Go only took off thanks to Docker pivot from Python into Go, and Kubernetes from Java into Go, after the respective teams got some Go folks into the project.
The usual RIX approach, followed the whole devops hype cycle that created all those CNCF projects half of which no one in devops space actually knows they exist.
This doesn’t seem like an extravagant expense to me. And it sounds like it saves money on commercial font licensing.