I'm writing some Java at the moment for an Android app, and it's just killing me after doing Scheme and Python, but I have to admit, if that start-up had used Java or C#, they might have been better off in the long run.
Hiring really good, disciplined people is super, super hard. My current thought is that if you don't have a super-star CTO who can attract and keep real A+ coders, don't use advanced languages. And if you do have that CTO, do it, but make sure you are architecting to make the rewrite in C# or whatever doable when you sell your company. If I were starting my own business now, I'd use Clojure or Scala or F#, and design things so that in 5 years new owners had a decent path to switch to C# or Java wherever they want.
Android isn't Java though. It's some frankenstein contraption made from a mutated version of Java from a decade ago.
> I were starting my own business now, I'd use Clojure or Scala.
I personally wouldn't ever choose Scala for anything. It's tooling is horrible (Sbt is a special hell, and scalac is as slow as a C++ compiler).
I'm currently in a code base like you describe, scala core with a switch to Java. It's not fun. Were stuck with these legacy library and framework choices that don't fit into the Java ecosystem and it slows down development considerably.
Scalac is as fast as Javac if you don't overuse Scala-specific features which are known to compile slowly - implicits and macros. But it is unfair to use these features and than complain on compile speed or compare it to a language that doesn't offer similar feature set.
Also, in our Java/Scala project it turned out that Scala+Bloop was way faster (10x-100x) at incremental compilation than Java+Gradle. Bloop is based on SBT libraries so there are some things that SBT does right.
Kotlin has wayyy better interoperability with Java
i wonder if Java is judiciously choosing the non crazily digressive parts of Scala, as they both evolve.
So far I’ve just seen a complex and wild stream API that mimics it in practice, without all the mental model behind it.
Oh, and what’s this nonsense with Java Option?! Really?
For better I'd say you should look at things like virtual threads vs async/await or kotlins when vs switch expressions.
The question is: if this support is enough or should the type system be enhanced so you can abstract over/compose a functor and/or a monad ?
The answer to this question is IMO still open.
Screw that... I should have been told sooner
"Over the last 12 months, 75 per cent of the most active “buyers” of $100m+ technology companies have been PE firms. This is despite the fact that the combined cash balances of the “Big Five” tech companies is an eye-watering $330 billion. Today’s most active tech buyers are private equity firms like Silver Lake, Francisco Partners, and Vista Equity. Not Google, Facebook or Amazon."
https://ftalphaville.ft.com/2019/01/07/1546862666000/Guest-p...
One of the things that is not obvious to people coming from the VC world is that once the company has gone from VC to PE, it's likely going to get flipped several more times from PE to PE. At a guess, I'd say 3/4 of what I look at are one PE to another. Depending on the firm, they will sell every 3 to 7 years or so.
iain
You used it twice, but it's not on Google...
that’s a logical fallacy. chances are that if they used Java or C# they might be dead by now (ie it sucks but usually it’s a good problem to have)
For any significant Python codebase, I make sure to put extra effort into precise and strict type annotations so I can rely on type safety. Sometimes after fixing all the statically detected type problems, my program works on the first try.
Python was strongly typed from the beginning, before it was statically typed. When you add a string to a number in Python, you get a type error. Python's static type system– which is formally part of the language and has multiple implementations– is an elegant and natural fit to the language. Unlike TypeScript, where the type system is artificial, and restricts what you can do with JavaScript.
Language features that made it into ruby– like blocks and unless– were rejected from Python because they would have made it possible to create advanced DSLs, which is something the language maintainers aim to avoid– enabling the creation of arcane application-specific special languages.
PEP-484 is the static type system's name: https://www.python.org/dev/peps/pep-0484/ (implementations include mypy and Pyre)
I don't feel confident when I program in Python, nor in Javascript exactly for the lack of proper typing. One could argue that if you know exactly what you are doing, types can even be ignored, which is kind of true - but they're there to help the developer and his team. I don't see any good reason to use Python over Golang, for example, if we only consider the language itself and the confidence that you get from using a statically typed language.
One company I worked at had "we hire the best!" as its slogan, and they used it to justify so much bad practice. No code reviews (we just don't hire people who write bad code), no unit testing (same reason), python used for huge sprawling 10+ year old codebases that's on its third or fourth generation of maintainers, and no documentation anywhere. Everything is a spelunking expedition, and there's no type safety or anything to help you figure it out. There are more than a few thousand-plus line functions that make PyCharm chug every time your touch a character.
On the flip side, the Java and C++ codebases were similarly abused (no tests, no docs, four generations of maintainers/oral tradition, no code reviews ever) but are at least two orders of magnitude easier to traverse because the type system keeps everyone honest across decades in a way that dynamic languages just do not.