With the size of the asteroid, is this one where we could use the gravity tractor[1] or the Yarovsky Effect[2] techniques for deflection, or is there not enough lead time?
To change orbit of so large asteroid, need huge amount of energy.
Unfortunately, humanity now have only small power ready, for such far things just about 50kW, it will need decades to transfer so large energy.
Russians claimed to create nuclear reactor for space with somewhere near 200kW, but unfortunately, now these are just words, very far from real hardware.
It is. There are scraping third party services you can pay for that will do all of this for you, and getting blocked by IP. You then make your request to the third-party scraper, receive the contents, and do with them whatever you need to do.
Why couldn't they add a tool that literally calls stockfish or a chess ai behind the scenes with function calling and buffer the request before sending it back to the endpoint output interface?
As long as you are training it to make a tool call, you can add and remove anything you want behind the inference endpoint accessible to the public, and then you can plug the answer back into the chat ai, pass it through a moderation filter, and you might get good output from it with very little latency added.
It's intended as a replacement for _scala_ builds. Having a build definition in the native language that doesn't require a different syntax (like a declarative syntax such as maven xml or toml) makes task customization easier for the maintainer of a given project. Unfortunately, it also means that you have to know the language and read the documentation for the build system.
If you want something declarative, there's also bleep[1] in the scala ecosystem. And for single module builds there's scala-cli[2]. It's also possible to use gradle and maven for scala projects, but for an java-only shop I wouldn't be using mill or bleep because there's no need to introduce a new language just to manage the build. For scala/java/kotlin hybrid projects though, gradle or mill or sbt would be my recommended tool because of how tightly they are coupled with the cross-platform build matrix nature of scala library and build system plugin ecosystems. For larger builds, it's mill or bazel because there s a performance cliff in sbt and gradle, and bleep is too new to have all the standard plugins ported. We use mill at writer.
The intention has changed, Mill now explicity targets Java and Kotlin as well. It now has dedicated Java/Kotlin docsite
sections and examples, and has grown integrations with Palantir-Format, Checkstyle, Errorprone, Jacoco, and all their Kotlin equivalents (ktfmt, ktlint, kover).
Java and Scala (and Kotlin) are remarkably similar from a tooling perspective, so Mill tries to target both using the same shared infrastructure
> It's intended as a replacement for _scala_ builds. Having a build definition in the native language [...] makes task customization easier for the maintainer
Totally agree! But the title of the post says "Mill: A fast JVM build tool for Java and Scala" :) - it certainly looks like better tool for the Scala community.
For projects that are primarily building Java sources, it'd be nice to have a build system that uses Java code to describe the build. I don't think this exists at the moment.
As one teacher and several profs told me, "You don't need to say, 'I think', because the fact that you are saying or writing it means that you think it". In other words, if you are uncertain, don't express the idea, because no amount of verbal hedging will protect you if you express something that is incorrect.
However, the best way to get the correct idea if you are wrong and unsure is to confidently propose your idea as if it is correct - Cunningham's law applied to everything.
writing 'I think X', 'there a chance that X' instead of 'X is', 'I know that X'
> if you are uncertain, don't express the idea, because no amount of verbal hedging will protect you if you express something that is incorrect.
The problem with this is with the target audience of your writing,
if you're assuming an adversarial audience vs a cooperative one.
the bigger and less self-filtered the audience is the more likely it is to become of the first kind.
> the best way to get the correct idea if you are wrong and unsure is to confidently propose your idea as if it is correct - Cunningham's law applied to everything.
Personally when I see someone being confidently incorrect consistently I just filter them out and their opinions instead of correcting them because a lot of time it's a lost cause.
for example Reddit and twitter, the sheer amount of people that are overly confidently incorrect, it made conversations not worth having there so I just stopped many years ago.
Everyone has their threshold for how many times you are allowed to be incorrect within a given context, sure.
> adversarial audience...
Yes. Even if the audience you target is small and on your side today, a successful piece of writing will gain an adversarial audience, eventually.
> If you give me six lines written by the hand of the most honest of men, I will find something in them which will hang him. - Cardinal Richelieu (apocryphal paraphrase from hearsay apparently but still a great quote).
And yet one of the best ways to lose respect in a technical context, especially as a junior, is to be confidently incorrect. Showing humility helps a hell of a lot for all concerned if you've in fact misunderstood something.
A better interpretation is to express the uncertainty at its core, and not wrapped into your subjectiveness.
For instance if you read it in a publication and kinda agree but don't fully trust it, instead of "I think X" you could go with "Publication Y exposes the possibility of X"
The real point of the advice is to get rid of fluff, not remove nuance or valuable information.
And scalachess is written in scala, to piggyback off a post earlier this month that claimed the language is dead. The project is very successful and has been around and maintained for years.
If all the Rust people knew how nice Scala 3 as a language is... they would be surprised.
What still isn't great is the ecosystem and the build-tooling compared to Rust (part of it because of the JVM). But just language-wise, it basically has all the goodies of Rust and much more. Ofc. it's easier for Scala to have that because it does not have to balance against zero-overhead abstraction like Rust does.
Still, Scala was hyped at some point (and I find it wasn't justified). But now, the language is actually one if not the best of very-high-level-languages that is used in production and not just academic. It's kind of sad to see, that it does not receive more traction, but it does not have the marketing budget of, say, golang.
I think the incompatibilities burned a lot of the good will. I'm very fluent in Scala 2, but I will avoid Scala if I can, mostly to stay away from purely functional programmers.
> all the goodies of Rust
Does it prevent me from using a non-thread-safe object in multiple threads? Or storing a given object which is no longer valid after the call ends?
Does it have a unified error handling culture? In Scala some prefer exceptions (with or without `using CanThrow`), some prefer the `Either` (`Result`) type.
Yeah, that's true. Scala 2 allowed a lot of weird things and sometimes even nudged people into the direction of overengineering and writing cryptic code. I'm not surprised a lot of people were burned.
Basically, you needed a good and experienced developer from the start of a project for it to be a nice code base.
> I'm very fluent in Scala 2, but I will avoid Scala if I can, mostly to stay away from purely functional programmers.
There is the whole [Li Haoyi](http://www.lihaoyi.com/) ecosystem in Scala that is much more python-like, but nicely designed, statically typed and using immutable datastructures by default. I think it's the best you can get nowadays if you want to have immutable datastructures on the JVM. Any other option I've ever tried was way worse.
If you are fine with Java's stdlib then I guess Kotlin is the better choice.
> Does it prevent me from using a non-thread-safe object in multiple threads?
I would answer the question with yes, but maybe in a different way than you might expect. Scala prevents problems/bugs from using a non-thread-safe object in multiple threads by simply having immutability by default. Rust cannot do that (due to performance) so it has to have another way (the borrow checker). I would argue that the Scala way is better if you don't need the performance / memory-efficiency of rust and can live with garbage collection. That reduces the domains that you can use Scala for, but in exchange the code will be simpler compared to Rust code, so in those domains Scala will have the advantage but it's a minor one.
> Or storing a given object which is no longer valid after the call ends?
To this one I would say "in practice yes". Rust is better here, but when using e.g. [ZIO Scope](https://zio.dev/reference/resource/scope/) then the problem isn't really existing. You can technically still do something like that, but you would basically have to do it intentionally. Rust has the advantage here though, but it's a minor one.
> Does it have a unified error handling culture?
No, Scala has no unified culture. Maybe the situation is better than in Rust, but then Rust has its own problems. [Just a few days ago I found a comment about a problem caused by a hardcoded panic that caused issues](https://github.com/orgs/meilisearch/discussions/532#discussi...).
> Does it have named destructuring?
Unless we are talking about two different things, yes it does. I would even argue that Scala is more powerful here, because it also supports local imports and (with Scala 3) exports. So not only can you extract fields of an object into a variable, you can also generally bring them into scope and alias them at the same time, but you can do the reverse as well: [you can export them as well](https://docs.scala-lang.org/scala3/reference/other-new-featu...).
He has very good taste. I wish more Scala people are like him.
> simply having immutability by default
Not everything is a pure data structure. I called a gRPC streaming callback with multiple threads in Scala (got garbled result in the receiver). You can say this is the fault of using the Java API, but the more Scala solution (fs2) involves serializing the access under the hood which is not cheap.
Recalling that my contention is with "all the goodies of Rust".
>> named destructuring
> Unless we are talking about two different things, yes it does.
> Not everything is a pure data structure. I called a gRPC streaming callback with multiple threads in Scala (got garbled result in the receiver). You can say this is the fault of using the Java API, but the more Scala solution (fs2) involves serializing the access under the hood which is not cheap.
Well yes, that's what I'm saying: in Scala you sometimes have to sacrifice performance. Though I don't think that serialization is generally required just because you use e.g. fs2 or ZIO for streaming.
You are making a fair point. I'm also not happy with some of the decisions about pattern-matching.
You can resolve some of those issue by just using `import` locally though. So for example, if you have a case class X with many fields and you want to access many of them, you don't need to extract them all in pattern matching (and deal with _ for the stuff you don't need) but you can rather do `val myX = X(...); import myX._` and then just use the fields.
That is basically equivalent to doing `const {a, b, c} = myX` in typescript. You don't need to do `case X(a, b, c, _, _, ...)` in Scala here.
Not saying that this just solves all issues, but I think ergonomics of Scala in terms of pattern matching, destructuring and scoping/importing is generally/overall not worse than in Rust, at least not significantly so - that's why I think it's fair to say that Scala has the same "goodies" in this area. I did not mean to say that Scala is as good as or superior than Rust in all language features.
Maybe, but the thing is, if you are a new Scala dev, you will 1.) be confused by the number of build tools. Sbt is still kind of standard but there is now also Mill and now Bleep (first time I even hear of it!). And some people will tell you to just use Maven or even Gradle. Well...
And 2.) most people will go with sbt; and while it has improved a lot it is still comparably slow, has some annoying bugs and so on.
Compare that to Rust - I don't think those problems exist there.
When you scroll away you can jump back by hitting anything on your keyboard. Also you can stay where you are, by clicking anywhere. It is a useful feature, that enables you to scroll to your heart's content.
The exact behavior isn't hugely important (although I think off-screen cursors are a useful feature). What matters is consistency between applications. There's no realistic scenario where I do everything in Emacs, so Emacs has to behave in the same way as other applications. If not, I risk data loss or corruption because I might fail to notice the cursor ending up somewhere I didn't expect. This is especially likely to happen with a feature like off-screen cursors that I use only occasionally.
We use it for all new services at Writer. Jack Henry, SiriusXM, Starbucks, Disney streaming services, and Capitol One all have services (not data-science) divisions producing new projects in Scala ranging from the last five years to today.
There are many others, of course, bit those are the teams at places people have heard of off of the top of my head. It's far from dead.
What does seem to be dying are the framework-centric Play Akka, and non Airflow raw Spark jobs out there. Now, a lot of that is because they were framework jobs that happened to originate in the scala ecosystem - scala was largely incidental and was chosen because of founding project members' preferences or due to the need to develop a commercial market, imho.
That’s precisely why people think it died. It became stable and therefore useful. It is therefore not talked about every 3 seconds by startup founders.
Why? Googling every name given returns public job postings for (senior) scala engineers. Presumably scala divisions at these companies are public knowledge?
1. https://en.wikipedia.org/wiki/Gravity_tractor 2. http://ui.adsabs.harvard.edu/abs/2021plde.confE.119A/abstrac...