No, I don't do SNS. I created it to show it to the police. Looks like "I don't have any social media" is considered to be suspicious and you are "hiding" something. At least that's true in the US. I don't know about Iran though.
Noone ever checked my phone in Iran, there is no reason. But unless you travel to meet family or friends, you need certified tour guide for the stay afaik.
I've climbed routes in ichinokura a few times. It is impressive, and some of them are quite poorly protected. But 800 climbers seems like an exceedingly high number, and that report seems quite vague and unsubstantiated, even if it does come from the government. So I remain sceptical.
Spring is so versatile that people use it in every way they can possibly imagine. Spring is fine IMHO if you keep it simple enough and refrain from fancy ideas. Maybe I'm just saying to keep it simple, regardless of what you use...
I don't know. I started my career as a Java dev, but what made me grow as a software developer was learning Scala. I learned a lot about functional programming, algebraic data types, effects, and so on.
I'd say Java is a great production language, mostly because it's so simple that I don't need to "learn" it (when you know better than using madness like `==` or Serializable).
I went the same route and am still working as a Scala dev. However Scala adoption seems to slowly go down, unfortunately .. Which is a shame because it's a beautiful language and I love using it as FP together with Cats.
However Java has advantages too: the IDE support was miles better than Scala, build times were shorter, most frameworks were more mature and better supported and the language itself was much more stable.
Scala adoption is going down because it's a behemoth of a language with so many features that it takes too long to learn and be proficient with it.
There's beauty in simplicity, and Scala is the antithesis of that, it has not only the kitchen sink but the whole kitchen and some house attachments within it. I fell in love with Scala for a while, worked with it for a couple years, and absolutely hated it whenever I had to train someone new. Nowadays I simply refuse to work with it because I'm not willing to relearn all the stuff it needs to be productive.
> There's beauty in simplicity, and Scala is the antithesis of that
Succintly put, exactly this.
Scala is as bad/good as lisp, and has the same challenges.
It's fun for a solo developer or very tiny close-knit team to do intellectually fun code pirouettes and stunts. Not in a negative way, that does bring satisfaction.
But throw it into a multi-dozen people codebase with many varying styles and soon enough nobody understands what's going on and it becomes a royal nightmare.
There's a lot of value in simplicity if you need to maintain that code over the years and many people.
I get the point you're trying to make, but there's something ironic about touting a language as "simple" immediately followed by mentioning that using the basic equality operator that's used by pretty much every other mainstream language is "madness". I know every language has warts, but that one is pretty egregious both in terms of how quickly people would run into it for the first time and how easily it could have been avoided (e.g. by using something else for the less commonly needed equality operator, like how Python uses `is`). Having things that look correct and compile fine but then fall for reasons that you have to explicitly learn isn't really "simple".
Fair criticism, but it's not really a practical problem. Usually a linter will catch them easily, and even when junior devs ignore the warnings, you can just tell them to use "equals."
The thing is that, equality is the difficult problem. "equals" in JVM languages has a lot of problems. Dynamic languages are much more horrible in this aspect. JavaScript `==` is much worse than Java. Python is guilty too in my view, for using `__eq__` method. The only language I know which solves the problem correctly is Haskell. (Or, `Eq` in Cats)
It's a subjective thing, but to me, having the usage be intuitive even if it means doing a custom implementation is a bit less intuitive is still "simpler". A person in their first day of writing Python code can use `s == "some_string"` and it will work like they expect, and they typically will only need to learn about `__eq__` when they've spent a lot more time writing Python code. With Java, they might literally have to learn that `s == "some_string"` won't work the way they expect and that they need to use `.equals` instead.
JavaScript has an entirely different level of issues, where at first glance it _looks_ like `==` works the way you'd expect, and the issues start cropping up when you accidentally rely on assumptions like equality being transitive. I agree that this is much worse than Java, but it doesn't change the fact that Java still doesn't strike me as the simple, straightforward language you tout it to be. I'd argue that the measure of how simple it is to learn a language should be measured both by how quickly you run into behavior where you need to start caring about the underlying implementation and by how intuitive (or unintuitive) the underlying behavior you need to care about is. At least with regards to comparing equality, Python beats Java by that measure because it abstracts away the concerns about how to define equality from the concerns about how to actually perform the comparisons, and Java beats JavaScript because the extra knowledge you need to be able to compare equality correctly being way more straightforward.
From what I can tell, LLMs tend to hallucinate more with minor languages than with popular ones. I'm saying this as a Scala dev. I suspect most discussions about the LLM usefulness depend on the language they use. Maybe it's useful for JS devs.
I write primarily Scala too. The frontier models seem reasonably good at it to me. One approach I sometimes use is to ask for it to write something complicated in Python, using only the standard library, and then once I have the Python refined I ask for a translation into Scala. This trick may not be applicable to your problems, but it works for me when I find an interesting algorithm in a paper and I'd like to use it but there is no existing Java/Scala implementation.
I use AI assistance to generate code and review code, but I haven't had success trying to use it to update a substantial existing code base in Scala. I have tried using both Claude Code and Cursor and the handful of times I tried there were so many oversights and mistakes that resolving the mess was more effort than doing it manually. I'll probably try again after the next big model releases.
Current frontier models have been the least useful to me when I'm asking them to review performance-critical code inside Scala. These are bits of my code base that I have written to use a lot of mutable variables, mutable data structures, and imperative logic to avoid allocations and other performance impediments. I only use this style for functions highlighted by profiling. I can ask for a code review and even include the reasoning for the unusual style in the docstring, but Claude and Gemini have still tried to nudge me back to much slower standard Scala idioms.
