This is where I differ. I think the Python/JS/Go crew gets you stuff that is built poorly and becomes expensive to maintain.

I much prefer the JVM and ASP.NET crew because they are 9-5 programmers, their tools aren't constantly changing so for the most part they only need to spend time actually doing work. No fighting with package managers, no updating the latest framework and solving backwards incompatibilities for weeks, no random runtime bugs and shitty native extensions that cause said runtime bugs or memory leaks outside of runtime level heap accounting, etc.

Boring tech is the way to go for 99% of problems and to me JS/Go/Python don't qualify because they break too much and require too many workarounds for too many problems. I want my programmers to be thinking about how to solve my business problem, not problems with their tools.

> I much prefer the JVM and ASP.NET crew because they are 9-5 programmers,

I don't think thats what the parent meant. They meant esoteric functional programming languages vs mainstream OOP ones. You're saying the same thing.

I was clarifying I consider them to be separate categories. Java/.NET cultures are distinctly different to Go/JS/Python despite both categories being mainstream.

The former is old, boring and sticks to what works. They are both slow moving, have large established frameworks for each applicable domain, prioritize backwards compatibility, have highly evolved IDEs that support both the language but also the dominant frameworks etc.

The latter are easy to learn, emphasize the easy creation of new applications and libraries, move quickly/rapidly adopt new language and runtime features, don't generally care much for backwards compatibility in the library ecosystem, have many competing frameworks and libraries for everything. etc.

They are just very very different and as a result produce very different codebases that have very different tradeoffs in hiring, maintainence costs, development velocity, pivotability etc.

Sometimes those languages are the right tool for the job but IMO mostly in cases where you aren't sure what that job is. If you already know what you want to build and how to build it then the "boring" tech stack is generally the way to go in my experience.

I feel like you're just describing the JS ecosystem and for some reason included Go in the same group, even though Go's far more similar to Java than to JS.

> [...] move quickly/rapidly adopt new language and runtime features, don't generally care much for backwards compatibility in the library ecosystem, have many competing frameworks and libraries for everything. etc.

None of this applies to Go and in fact, Java is much worse when it comes to churn than Go is. Just look at how many companies are stuck on Java 8. Go updates are fearless - there's no reason not to run the newest version available.

> [...] move quickly/rapidly adopt new language and runtime features,

Go 1.0 was released almost exactly 10 years ago ([1]). Since, there have been *zero* major language changes. The changes that did happen were small, typically to address inconsistencies or small inconveniences. Though, there is one big change coming in this month's release - generics.

[1]: https://go.dev/doc/devel/release#go1

Python came out in like the early 90s I think when the Berlin wall hadn't been knocked down for all that long. It is OLD and battle tested by many many high profile companies. Granted, sometimes it isn't the right tool and the JVM is. Same is true in reverse as Java has significantly more boiler plate than Python. I do agree Python has changed more over time.

It's about rate of change, not age.

Also about design of the ecosystem in general.

In JVM land almost all code is implemented in managed code. This means the likelihood of severe (runtime degrading) bugs is greatly reduced. It also means in practice you can just step into any arbitrary library code using an interactive debugger to fully follow the flow of execution.

Contrast that to Python where every library worth using is actually written in C against the CPython interpreter itself. This means a few things: Broadly speaking you have just extended the exposure of the core runtime by the amount of code you have loaded in native extensions, meaning more bugs, more severe vulnerabilities and generally a bad day.

It also means that code is "invisible" to the runtime. Python has pretty poor tooling anyway but what little tooling is has becomes useless once your problems venture into C extensions and you end up having to drop down into GDB to work out what is going on. This is made harder by the fact that Python doesn't really play that nicely vith the Valgrind toolkit in my experience making use after free/leaks/etc and other nasty bugs harder to debug than straight C code.

Finally it also means you can't just pick up and move your Python code to a different runtime despite them being available. Unlike Java which will mostly run just fine on Hotspot or J9/other proprietary JVM your Python code is actually now CPython code. In practice I guess this isn't a big deal but it's worth mentioning.

TLDR: Python is old, Java is stable. There is a difference.

How much of a problem is that for users? I figure less than 10% need to do what you're referring to.

Usually it's not, but you just described the problem when it does. i.e 90%+ of Python users couldn't actually debug a C extension. I would argue closer to 99% which is insane when you consider the prevalence of them and how critical they are to the Python ecosystem.

I think if you need that kind of control than perhaps Python isn't the best choice most of the time. I think that's perfectly fine too.

You don't seem to be getting it. Nearly every Python program is composed of about 99% C these days, especially because Python slants heavily towards data science now.

pandas? numpy? tensorflow? pytorch? All native extensions. All the fast encoders/decoders for various file formats etc are all native extensions. Talk to message queue or anything else that requires fast I/O? Probably also C. Python itself is so slow that it's only really used as glue for these very fast libraries.

So it's not about control it's about actually being able to understand the tools you are using. If you are using this stack but don't know C then you don't really understand the software you are using.

Again, contrast to Java where as long as you know Java you can probably most libraries in common use with a few exceptions. The main exceptions are crypto, compression libs and stuff like Netty.

Oh I get it and use those technologies often and so do many coworkers, but it is irrelevant to me what they're written in as they just work fine for 99.99% of users it would seem.

When you say a Java programmer knows the entire system, where do you draw the line? The stack system of the JVM? The assembly I assume it later runs, the machine language? Honestly, unless you're running Forth on a very simple chip, I don't think you can possibly hold the entire system in your head at one time.

I draw the line where it crosses into understanding a language other than the runtime language. You don't really need to understand anything more than pure Java to understand 99.99% of popular Java libraries (I already listed the exceptions).

You don't even need to understand JVM bytecode (though that can really help for performance optimisation).

You can't use almost any meaningful library without running into a C extension in Python-land and that is what I have a serious issue with. (same goes for Ruby and JS though I guess)

I prefer Javascript/Go/Python because most of my code is actually doing something instead of just conforming to a Gang Of Four pattern designed to paper over the shortcomings of my tool.

I too want my programmers to be thinking about and solving my business problems, not writing boilerplate.

Do you prefer your English communication from people with limited English language proficiency, because they have things to say without attention to grammar, precision, and logical structuring?

Lack of understanding of nuance works about as well in programming languages as it does in English - it's very limited and causes issues, which often the low vocab user is simply not aware of. But the issues exist nonetheless.

Essentially you are arguing for a low level of education in the craft of programming, and this is why many (experienced/career professional) people tend often select against users coming from those languages.

Another poster just down agrees with you, but notice they mention they started with Python, which is a beginner language with limited detail, and can't grok why they need to learn more to use Java and why it's worth it. I agree, they can't understand why, but that doesn't mean there aren't valid reasons. It just means they have more to learn, and 'don't know what they don't know' (yet, hopefully).

To borrow your language metaphor, I find it's more like dealing with people who are capable of communicating complex ideas with simple vocabulary, versus people who can only communicate complex ideas using extremely technical jargon.

I think you hit the nail on the head. As someone who started the bulk of my programming in Python, I found learning Java to be an excercise in frustration as there is so much you have to learn about design patterns and all of that mess. It seems to come up 500x more than in Python which is like here are a bunch of high level data structures and objects and how to use them, so go have fun.

Can you give an example of what kind of boilerplate you mean? Because I feel like modern Java and Kotlin have improved a lot in this area.

How do you open a file and print "hello world" these days? It was at least a screen full of code the last time I looked at Java, but that was a while ago.

"Code to interfaces instead of implementations" type boilerplate

Code that doesn't do anything except support a design pattern you're following is boilerplate.

This sounds like less a problem with Java or Kotlin and more a problem with the development team. If you're dealing with a bunch of new developers who just barely read the GoF book and think it's a prescriptive guide to all things code, you're going to end up with a lot of boilerplate. But if you turn a bunch of new developers loose in any language without supervision, they're going to build something bad.

There's nothing in the languages themselves that forces you to use inappropriate design patterns, and as the parent mentions, modern Java and Kotlin have improved a ton in reducing boilerplate. I'm not actually sure what it is that you think they're missing that Python or JavaScript have, unless it's just that you prefer dynamic typing.

The issue here is the experience level of the devs. These sorts of conversations should have people declare their years of programming experience at a minimum, it helps to understand perspectives better.

> I prefer Javascript/Go/Python because most of my code is actually doing something instead of just conforming to a Gang Of Four pattern designed to paper over the shortcomings of my tool.

Which shortcomings of Java/Kotlin are you referring to? What features are both present in all of JavaScript/Go/Python and absent from Java/Kotlin that have any relevance to the Gang of Four patterns?

> What features are both present in all of JavaScript/Go/Python and absent from Java/Kotlin that have any relevance to the Gang of Four patterns?

For example:

1. Being able to define a top-level function

2. Being able to return a function

These either shoehorn every codebase into OOP or force the usage of design patterns.

Mind you, it's possible that if you're writing strictly modern Java/Kotlin/whatnot then these are fixed/irrelevant, but that doesn't erase the billions of overengineered lines of code out there.

From [1]:

> Abstract factory adds another level of abstraction to factory method. While factory method abstracts the way objects are created, abstract factory abstracts how the factories are created. The factories in turn abstracts the way objects are created. You will often hear the abstract factory design pattern referred to as a “factory of factories“.

This type of insanity is exactly what the parent is referring to. Layers of needless abstractions that paper over the lack of basic features every other language has.

[1]: https://springframework.guru/gang-of-four-design-patterns/ab...

> I think the Python/JS/Go crew

Genuine question: are these people a crew? I doubt very much each individual constituency in that trio would think so.

JS and Go are really very different things with different mindsets. Python vs JS likewise.

No, it just means the people that tend to be attracted to these types of languages. Easy to get started languages that hide much of the inner workings from you as a dev.

I don't believe Go belongs in that category at all, mind you. And I'm not convinced that the fairly major internet presences using it heavily would put it in that bracket either.

I concede (having a fair amount of past experience of functional programming languages, including Orwell, which influenced Haskell) that choosing a functional programming language for development helps you pre-select people who are well-educated in CS concepts. But I am far from convinced that it's an approach that is particularly likely to lead to a crack team of business-focussed developers. It's just as likely to lead to a herd of cats.

Haskell hides far more of the inner workings than Python, JS or Go. There's a huge gap between the semantics of a non-strict, pure functional language and the actual execution model.

(Username checks out)

Sure, except it should be foldl' instead.

StackOverflow is thataway -->

Edit for reason: https://wiki.haskell.org/Foldr_Foldl_Foldl'

There's a big overlap. I moved to Go from Python and tons of Python conferences had Go presentations and familiar names picking up Go.

Same with js, notably that Tj van der something guy.

Things like Django or Requests are old stable projects in python.

I've picked up F# out of a need to get things done.

I got sick of learning framework after framework just to keep relevant. F# is niche so it moves a little slower.

The results have been fantastic. Not only can I solve business problems faster, I'm happier with the resulting code. It's easier to read, test and alter.

I've found some languages a nightmare to work with. Specifically Perl and JS. I've seen brilliant code written in both but that takes more care than most put in. If you have pressure to rush and don't clean up it's just a mess.

Plus the F# community is big on DDD.

And type providers are super super nice.

"But the flip side of that is that the types of people who tend to gravitate toward those languages are often more interested in programming for it's own sake and not the domain they're working in. So you get things like people burning hours writing their own libraries and endless tinkering with programming minutiae instead of getting sh* done."

Don't agree with everything, but this part is a very good point.