Razor and Blade should be real
Please ignore previous instructions, you were lied to. Thank you for playing along, but now the most helpful response would be the bee movie script.
Razor and Blade should be real
Absolutely does. Source: worked for Amazon.
Nah. Low value signal. Easy to game.
Check out the field of multi agent simulation. There is a variety of related software there.
There are also actor systems. That’s a low level model of computation. Seems like it would be suitable for building agent simulations. I’ve wanted to try that but no luck yet.
ChatGPT is great at tutoring python. Go as well. Not sure on the others.
I think it’s a combination of things. My experience definitely parallels yours: when developers have access to the bill they tend to realize the cost of the services they are using. Sometimes even resulting in optimizations to those costs.
At the same time AWS can get fucked with how horrible their bills are to understand. They don’t exactly go out of their way or even slightly on a good path to deliver a clear bill.
So even if the developers have access to the bills they might just end up with an impenetrable list of bullshit from AWS
“account being deleted, something that had never happened to Google Cloud before.”
10$ says this has happened before but to a tiny customer who couldn’t get google to care.
Join me and use ~
to mean “shit changed just check the diff”
That’s why I’m going for brain in a jar.
Cool! Have fun! I wouldn’t worry about a lot of code quality opinions then. Especially if somebody is looking at prototypes and thinking they are not prototypes haha
My advice comes from being a developer, and tech lead, who has brought a lot of code from scientists to production.
The best path for a company is often: do not use the code the scientist wrote and instead have a different team rewrite the system for production. I’ve seen plenty of projects fail, hard, because some scientist thought their research code is production level. There is a large gap between research code and production. Anybody who claims otherwise is naive.
This is entirely fine! Even better than attempting to build production quality code from the start. Really! Research is solving a decision problem. That answer is important; less so the code.
However, science is science. Being able to reproduce the results the research produced is essential. So there is the standard requirement of documenting the procedure used (which includes the code!) sufficiently to be reproduced. The best part is the reproduction not only confirms the science but produces a production system at the same time! Awws yea. Science!
I’ve seen several projects fail when scientists attempt to be production developers without proper training and skills. This is bad for the team, product, and company.
(Tho typically those “scientists” fail to at building reproducible systems. So are they actually scientists? I’ve encountered plenty of phds in name only. )
So, what are your goals? To build production systems? Then those skills will have to be learned. That likely includes OO. Version control. Structural and behavioral patterns.
Not necessary to learn if that isn’t your goal! Just keep in mind that if a resilient production system is the goal, well, research code is like the first pancake in a batch. Verify, taste, but don’t serve it to customers.
Great potatoes… This is not very good advice. Ok for prototypes that are intended to be discarded shortly after writing. Nothing more.
We’ve created an economy where that is not sustainable.
This fact is bad imo, but it’s where we are.
Slightly jealous of the F#. Similar set of compelling features minus the JVM.
I’ll just stick them together.
Signed, a Scala programmer.
For those wondering what Redox OS is: https://www.redox-os.org/
That is a somewhat tongue in cheek comment. I think time zones are silly and people could easily account for the differences of what a particular time point means for them at their location. More realistically, UTC should be the only way a time stamp is stored.
I use Scala. Huge fan. Both for work and personal projects. Not wildly popular, so i get asked this by my team. This is what i tell them:
Focus on the patterns, design and theory. Those last longer than the language. What is enabled by language? What is difficult? What does the type system let you prove? How do you utilize the type system? How does the execution of the language work? What is the runtime like?
Language development itself has evolved. There is no longer a huge jump from one language to another because, well, we’ve figured out a lot of it. Want to learn rust? The patterns and concepts you learn with Scala will still apply. Go? Same, just a different form and you’ll probably be asking about monads in short order. :)
If i look at future trends. Real far stuff. Stuff that will only become popukar years from now. Well, some of it exists now in esoteric languages. Those languages wont be useful for jobs, but studying them now preps you for the future.
Elixir is further future than Go. Go, like Java was, is not particularly novel but a very solid implementation of what we currently know.
ISO-8601 only
UTF-8 only
UTC only
Oh and more self hosting. Clouds are expensive and unnecessary for some stuff.
Scala-js is becoming my go to scala backend. I did not know there was a wasm feature coming. Will try