The number of keywords of a language is completely unrelated to its complexity (see Brainfuck or Lisp).
The number of keywords of a language is completely unrelated to its complexity (see Brainfuck or Lisp).
+ database retrieval and manipulation as a 1st class concept. ABAP doesn't require a 3rd-party ORM and therefore, SQL statements are 1st class syntax.
+ GUI capabilities as 1st class syntax (user interface elements for forms, lists, grids, visual reports, etc)
Golang core doesn't have those, so it understandably doesn't need extra official keywords to address that functionality.
SAP ABAP has more keywords that's typical for a 4GL type of language. Like other business-domain 4GLs, the complexity isn't the language syntax -- it's navigating the gigantic data model to find where important information lives. (e.g. Out of 10,000 tables, where does the sales invoice live? If an invoice is paid, where is that status field? And to make it harder, many of the database column names are German instead of English ... like AUGRU[1] for "auftrag grund" instead of English "OREASON" for "order reason".)
If Golang language spec was revised to include a 1st-class ORM and GUI & report builder into its core syntax, it would be a more apples-to-apples comparison. Golang can have less keywords, because it has less features.
So, you are saying… because it's less complex?
"Complexity" is not a useful label unless you look at what you're actually building:
- If the goal is to show "hello world", yes Golang is "simpler".
- If the goal is an ERP system, Golang is way more "complex".
Between those 2 extremes requires analysis on a case-by-case basis.
I could bootstrap a .Net/Java/whatever app to do the same thing, but our team is swamped with a backlog years long - I could only afford a couple days to develop and release this so a dozen Force.com licenses ended up saving tons on development and ongoing maintenance costs.