It is even worse than that as Martinique is a “territory governed by France” in much the same way that Hawai’i is a territory governed by the USA.
Martinique is a region and department of France—and administrative subdivision of the same type as those in the French mainland, differing only in that the the top two levels of subdivision (region and department) are coextensive rather than nested in Martinique and the other overseas region/departments.
First I thought it could make sense considering the territories have some differences in taxes on imports. But in that case, why is Åland missing then?
Inspired by the Dobble card game, a friend and I built an iOS version where the symbols are emojis! You can customize the difficulty with options like “only green emojis” or other themed sets.
We don’t want to put ads in the game, but we’re exploring ways to add non-free features to make a little money from it. Has anyone done something similar? Any insights or past experiences with monetizing a casual mobile game would be really helpful!
One note from having worked with both that I don’t see mentioned: Golang dependencies are sources you basically pull and compile with your own code. In JVM-land dependencies are precompliled packages (jars). This adds one little step.
...or a big step, if cross-compiling is required (e.g. Kotlin Multiplatform)
I'm surprised there is no source-only dependency solution for JVM -- it'd solve this issue. Pull down the source and build on the fly. Perhaps there is and I'm unaware?
I'm afraid Java/Scala/Kotlin compilers are too slow to make that convenient. Even currently building pure Java projects can take minutes when it's compiling just like 300k lines. What if it had to compile millions of lines from all the dependencies?
The actual compilation step is 100% not the bottleneck - it can go as fast as 10k-50k lines per second! (According to the Mill benchmark, but that’s the Mill-independent part).
Comparatively, Go does “only” 16k lines per second based on some HN comments.
But you’re likely comparing on different hardware though. Go compiling only 16k lines per second is hard to believe for me. Maybe they meant on single CPU core. Rustc compiles over 50k lines per second on my MBP in debug mode and Go must be definitely faster, as everyone knows rust is very slow to compile.
But anyway, you may be right. I just ran mvn install for the second time with no source change on my current project. It took 57 seconds.
The java metric is also from a single core. But you are probably right that it should only be taken as a rough ballpark, but java is definitely in the same ballpark as go in compile speed.
What issue would it solve? The fact that you can build a jar in any OS and then just use that anywhere else is actually a huge benefit of using Java, as you don't force everyone to re-compile your library source code.
Well since the builds tend to be monstrously complicated for some reason, and there’s no standard build tool, maybe it’s more impossible than possible to consider source based distribution. Or it would be like JavaScript where you still need a build and publish step to turn “developer Java / other languages” into “vanilla source distributable Java”.
Maybe so... but so do Python or Javascript. It seems to me some other languages have only one stack (rust: cargo, rustfmt...; the .net world as well). Does it make them better? (honest question). Then again, what's Java official stack?
I'd pick sbt over mvn no doubt. Haven't played with either fury or mill, so can't comment on those (even gradle... I never really used it). But coming from years of Java/Maven I think sbt is way better. Things start complicating a bit if you have lots of plugins or macros probably.
Opposite for me. After years of Scala (which I like) I recently tried to port a few things to Scala 3 and it really feels like some of the wtf-implicit part is gone. We'll still need to make a complete idea about this version 3 though.
sbt is not perfect but new build tools are coming up lately for Scala (check out lihaoyi/mill and propensive/fury to name) plus people are working with bazel (but i guess that's more for monorepos/very big codebases. my experience (7 years and counting) with sbt is that it's very very good until you need to roll out your own tasks/plugins.
Yes, it's the same idea. But Julia's differentiable programming capabilities are far more advanced and mature than Swift's. As far as I'm aware, Swift still doesn't support differentiating code with control flow (branches or loops), which, needless to say, eliminates pretty much all non-trivial programs.
Compare that to the situation in Julia: ∂P works today on arbitrary programs—like the ray tracer and other examples in this paper—programs which are highly non-trivial and use iteration, recursion, mutation and global state. All of which Julia's ∂P can take derivatives through.
When you additionally consider Swift's essentially non-existent computational and data science ecosystem, it's a bit hard (for me at least) to rationalize the Swift ∂P effort. (Are we going to differentiate iPhone apps?) They're attempting to bootstrap their computational/data ecosystem by allowing calling Python code, but as soon as you call into Python, you lose all ability to take derivatives which only works for pure Swift code. So any program which relies on Python to do some of the computation you want to take a derivative of won't be differentiable, which kind of defeats the point of having ∂P in the first place. We'll see how it pans out but the Swift effort has considerable technical and social challenges to overcome.
