Another take on the matter is: interruptions are inevitable, so reducing the "recovery penalty" is key, and can be learned.
That's something that you learn to do when you have a kid: suddenly, your periods of 4 hours of focus free time (for coding, exploring tech, whatever) during the weekend just _disappear_. You only get max 30 minutes of free time in a day; this is extremely frustrating initially; there is no boss to complain to, no meetings to blame, no solution but to deal with it. Progressively, you learn to switch tasks much more efficiently, by making regular check points, so that you can get interrupted any time and get back to deep work _quickly_.
Yeah this is something I want to learn more about for sure and is the weakest part of this piece. What have you found that works for you? Or is just that knowing that you’ll get interrupted will force better discipline?
this is part of the promise of the Pomodoro Technique. Named after a tomato shaped kitchen timer, the idea is to work for 25 minutes and then stop for 5 and step away from what you were doing, rinse and repeat. Being able to pick back up becomes important.
Talking about monetization strategy, there is a world where we would not have to remember "Zillow" or "Spotify", and instead ask for real state or music related actions, and have OpenAI "decide" for us what is "the best" options... As in "the option that paid the most to get promoted".
There has been a move in the past 8 years away from Java on the back end, notably to Go, by several large engineering organizations, which made the move, "motivated" by the example of companies like Google or by projects like Kubernetes, and seduced by the promises of a language simple to learn, build, and deploy.
> seduced by the promises of a language simple to learn, build, and deploy
That's actually quite correct and I'm saying this as someone that does Java on daily basis. Go is in fact superior in terms of deployment. I would rather deploy a Go-written service than a Spring Boot one. That being said, I love using Java for monoliths - large code bases crammed with business logic. I personally don't see Go doing very well in that direction.
Businesses often deal with old databases, message queues, SOAP services, legacy systems. Java has a truckload of well-established connectors (Even more than Python!), well-supported JDBC drivers, and vendor-supported SDKs.
Also features like transaction management, dependency injection, validation frameworks, AOP-style cross-cutting concerns are better addressed in Java.
Java has collection streams with great customizability (filter/map/reduce/etc). Far better writing your 10,000th for-loop in Go. You can also get automatic parallel streams without writing any extra code.
Go's profiling tools (esp memory) are very primitive, sorry. JVM profiling tools beat Go's by orders of magnitude. So does the other tooling - GC tuning, monitoring, etc. Java flight recorder and VisualVM are gorgeous.
That said, Go is still better at memory efficient, tight network software like lean k8s controllers. Though frankly, Rust is encroaching into this space.
I'm not them, but there are few things better for operational insight than the JVM. It has a boatload of tuneables, it has a very rich dynamic code load mechanism (Reflection, ClassLoaders, the new Modules system, and it used to have a strong sandboxing system but they killed that), and at the intersection of those two things is JMX, which is dynamically tuneable deployments via API. It's like having JVM-local feature-flags that one can twiddle without needing to bring down the JVM
And sure, it's not everyone's cup of tea, and/or plenty of people will chime in with "yes, but"s to defend golang or every other platform that isn't the JVM. I'm not yucking your yum! I'm just saying for me, the JVM is the bees knees
> by several large engineering organizations, which made the move
The problem with this type of trend is it's often hype and you never know what actually happens or how does it evolve over time.
I've seen organizations make certain announcements, switch maybe 5%, give up and go in different directions, but only the initial announcement ever hit the news.
> and seduced by the promises of a language simple to learn, build, and deploy
It's always simple if you rip it all up. Nice and shiny toys are always great.
As far as I can tell from my local health organisations, paracetamol is one of the safest painkillers for pregnant women.
That doesn't make it very safe, but NSAIDs carry well known risks during later stages of pregnancy, and opiods aren't exactly harmless either. Even aspirin carries risk (and aspirin doesn't even work as well compared to other drugs).
As far as I can tell paracetamol is still the first choice for painkillers while pregnant, but only because none of them are completely safe to use. It's probably fine for short term usage, but that also goes for non-pregnant people to be honest.
No it’s the only allowed pain reliever for pregnant women in the US. It’s also allowed in the UK and the EU from what I can tell. What countries are you talking abou?
Sincere apologies, I mixed ibuprofen and paracetamol.
Ibuprofen is forbidden for pregnant women in the last 4 months in France at least - and by "forbidden", I mean "strongly advised against in a case of self medication".
You are probably thinking of ibuprofen which is considered non safe during pregnancy. Paracetamol is pretty much the only OTC pain relief medication that is recommended for pregnant women.
There is another _shocking_ realization in this work: there are 11 types of people: those who know what binary means, those who don't, and those who say they do but actually don't.
"The era of 1-bit LLMs"
Representing { -1, 0, 1 } can't be done with 1-bit, I'm sorry -- and sad, please let's all get back to something vaguely sound and rigorous.
> please let's all get back to something vaguely sound and rigorous
Something rigorous would be to actually read the paper rather than stop at the first part of its title. The authors are not claiming their LLM is 1-bit.
It feels like civil international airports is the best place where dedicated embedded systems could be required for authorizing if not guiding airplanes to driveways.
Every way I look at it, Go brings tremendous regression when it comes to "modularity & composability" in the general sense of the terms.
Package management, package definition, interface definition, exporting, protecting or hiding components, feel like they were an afterthought, and as if specified by people who had absolutely no prior experience in other languages or actively ignored it.
There is no nesting of packages in Go. There is no selective visibility protection among packages except on the very first level. Exporting is such an afterthought that it is declared by the change of the first letter to uppercase. Local development of cross-modules was only introduced recently (workspaces) and is extremely primitive (no transitive replacement -- so workspaces depending upon other workspaces is not a thing, workspace-vendoring in the next release but will essentially conflict with mod-vendoring). This probably works with skilled and disciplined teams with strict linters and other tooling, and operating in a large mono-repository or on ultra small codebase. For others, it ends up in a large plate of spaghetti code with no help to untangle, and every single newcomer shedding blood, sweat and tears to wrap their head around a codebase which inexorably became monolithic by the invitation of the very language.
All learnings obtained from decades of building very large-scale applications in C++, of managing and publishing packages in Java or C#, was essentially put aside and ignored.
The sad but good news is that it's all being progressively rediscovered, but relearning from decades of nuget and maven for example, will take time, effort, exemplary humility and open mindedness.
That's something that you learn to do when you have a kid: suddenly, your periods of 4 hours of focus free time (for coding, exploring tech, whatever) during the weekend just _disappear_. You only get max 30 minutes of free time in a day; this is extremely frustrating initially; there is no boss to complain to, no meetings to blame, no solution but to deal with it. Progressively, you learn to switch tasks much more efficiently, by making regular check points, so that you can get interrupted any time and get back to deep work _quickly_.