Every time I've seen this, it's been a disaster. Custom DSLs for business logic are, 100% of the time, a red flag of a development process gone off the rails.
(We may work in different industries.)
Go prevents you from doing this at a very low level. This is a huge advantage.
And it's worth noting that many (all?) of these particular systems were actually initially made as custom DSLs for internal use within a single company - Rails for 37signals/Basecamp, Pandas for AQR Capital Management, Django for Lawrence Journal-World, Tensorflow by Google Brain, etc. They were the exact thing that you describe - a custom DSL invented for the business logic that the particular company needed repeatedly. And they were not a disaster but the right thing to do in their case - mostly because they had the ability to make a somewhat good DSL though in all those cases it was an 'okayish' DSL initially and became good only through years of substantial changes. Yes, for every such case there are many bad internal DSLs. "Not Invented Here" is a common problem. You need to ensure that you're using good DSLs, and good DSLs generally gain wide adoption within that domain instead of every company building their own shoddy DSL.
I've seen a bunch of nightmarish financial systems with horrible DSLs. However, even in that case the DSL problem was that this DSL was horrible not that a DSL shouldn't have been used - any fix or rewrite would generally require replacing it with a better DSL/framework/whole-encompassing-structural-API/whatever, instead of sticking to the core programming language (which would just result in another emergent "DSL" of some core libraries/classes, which would be lousy compared to something you intentionally design to be usable).
The differences between programming languages are smaller than the differences between DLS's implemented in the same language. Code in Rails (Ruby) and Django (Python) has more in common than code for Django and Pandas. Writing Tensorflow code in Python is somewhat similar to writing TensorflowJS code in Javascript, but very dissimilar to writing Pytorch code that does the same thing.
They're not really independent libraries, they're frameworks that suggest, influence and sometimes even mandate most of the infrastructure around your code and the structure of your code in a much more stringent manner than the core language does. There's a fundamental difference between making a few calls to a black box library versus having the content and style of most of your code being dominated by the traits of that "library" - the large frameworks overwhelm the small(ish) core languages. So I believe it's justifiable to consider the frameworks I mentioned as DSLs.
So you're right, for programming in the large it's very important how well the language supports creating good reusable APIs and data structures. I think that's why so many people make such a big deal about generics in Go, though personally I think it's a poor example and the complaints are tiresome. I think I'd focus more on whether the language has things like macros and lambdas/continuations that let non-API idioms be expressed consistently and conveniently, as though they're part of the language (even though I think creating a true DSL is usually a bad idea). Not sure Go meets this standard TBH.
Well, nothing I'm aware of beats the LISP family of languages as far as "making a good DSL" goes, but none of those are particularly popular :(
But that’s another topic.
(defclass foo (superfoo1 superfoo2)
((some-slot :type bar)))
(defmethod baz ((some-foo foo) (some-bar bar))
...)
(defmethod foobar ((some-foo foo))
(baz foo (make-bar)))
Some tool that can point where in a 1M lines of code project those classes are being used, and if they would need to change.
That's a good thing. But then comes the git merge (or any other automatic code altering tool). How do you know something hasn't been messed up in the process ? (unless you wrote unit test for every argument of every function)
Lisp has compilers.
Some do also some type checking, here SBCL 1.5.2:
(declaim (ftype (function (fixnum) fixnum) foo))
(defun foo (a)
(+ a 1))
(declaim (ftype (function (fixnum) string) bar))
(defun bar (a)
(if (zerop a)
"zero"
"not-zero"))
(defun baz (a)
(foo (bar a)))
* (compile-file "/tmp/test.lisp")
; in: DEFUN BAZ
; (FOO (BAR A))
;
; note: deleting unreachable code
;
; caught WARNING:
; Derived type of (BAR A) is
; (VALUES STRING &REST T),
; conflicting with its asserted type
; FIXNUM.I had convinced myself I was reading Clisp, instead of CLOS.
Common Lisp has an object system with classes since the early 90s. In fact it was the first standardized object-oriented language.
Common Lisp also has optional type declarations. Not very sophisticated, but they are there.
Check out the SBCL implementation, which has a compiler which does some static type checking/inferencing.
But one usually can use types/classes at runtime, too.
The maintainability of the code is mostly determined not by how good the underlying language is but how good is that DSL. To take an example that's been widely discussed in HN, let's think about machine learning - the look, structure and maintainability of your code is highly influenced by the choice of your framework/"DSL" e.g. pytorch vs tensorflow1.x vs straight numpy vs Caffe will have major differences despite being in the "same language".
And in that regard, the features of the core language matter only in regard of whether they facilitate making a good DSL. Of course, some languages fail because their choices result in the "core DSL" i.e. standard libraries that everybody uses being fragmented and confusing; Go has it quite good IMHO for the standard library; but for every specific domain it also matters if the DSL for that domain is good, whether it's an ORM layer or a OpenGL interface or a deep learning framework or an physics simulation library - whether the language abstractions mean that these DSL's (often being interfaces/wrappers to some third-party code written in another language) are going to be good and convenient, or whether the language structures limit the DSL so it becomes unwieldy to use.