Hacker News Reader

Comment by rascul | Hacker News Reader

> I don't think I will ever like kitchen sink languages.

What makes a kitchen sink language?

I would describe it as a language where there is more than one strong idiom

For C and Go, there really is only one prevailing idiom on how to write code (for C one could argue that static vs. dynamic allocation are two idioms, and multiple ways of doing concurrency)

For C++, whenever you have the chance to abstract some code into an interface you'll have the choice to create a template or use polymorphism, concurrency can now be done with an event loop, co-routines, threads...

Rust has the same bug/feature where there's more than one idiomatic way of doing things.

I feel like people have been saying this about Go for a while and I don't see how it's true. The only real idioms out of Go are explicit error handling, types implementing interfaces, and the formatter. Otherwise, you can kinda do whatever you want in Go, and I have yet to feel at home reading a Go codebase.

Thank you for the explanation.

“For C…, there really is only one prevailing idiom on how to write code”

You can look at single projects that have changed the way they write C code over time, introducing new idioms all the time. OpenSSL is a perfect example of that in regards to their work to reduce memory related bugs. C’s idioms have changed so many times over it’s life it’s hard to keep track or even read it from one era to the next.

> For C and Go, there really is only one prevailing idiom on how to write code

What’s the one idiomatic idiom in C for a growable list of items? Because I must have a seen a hundred of those in my time.

What’s the one idiomatic idiom in C for a hashmap? I’ve seen about a hundred of those too.

I would think you are referring to implementations of the one prevailing idiom as opposed to seeing multiple idioms for the concept. The idiomatic way to represent a growable list in C is to make a list (using some implementation) and put it in a structure with bookkeeping data, then using that list by passing it (or a pointer to it) to plain old functions to use it.

Of course I'm talking about an idiomatic implementation, what else would I be talking about in this context?

> The idiomatic way to represent a growable list in C is to make a list (using some implementation) and put it in a structure with bookkeeping data, then using that list by passing it (or a pointer to it) to plain old functions to use it.

That sounds like a long-winded way to say "there's no one idiomatic growable list in C".

Having more than one way of doing things is good when it's a consequence of a positive, well-curated language evolution. I think that's Rust case. It doesn't mean that it will become more readable ("beauty"?) in the future, there's a lot of line noise already: <'a>, foo::bar, #[define(...)], etc.

Or, ehem, JS. I think the JavaScript -> ES6,7,8,9 evolution is a good example of positive change: the language improved immensely at the cost of having even more idioms, TIMTOWTDI and transpilers like TS. The old parts are now marked as bad practice and optionally linted to hell. You still have to put up with W3schools-level code once in a awhile though.

Perl and C++ to me would be some bad examples. TIMTOWTDI hampered their evolution way too much. Perl froze for 10 years+. Python was much braver: their folks evolved (from 2 to 3) by breaking compatibility in order to remain true to its Zen.

Zig and Go are examples of rigidity, one-way-only extreme, which is a pain sometimes but, in Zig's case, maybe a good practice for a young language project. Readability in Zig is excellent and I like the choices with the @ functions ie. @as or @ptrToInt() instead of piling-up parens and asterisks. Definitely a case-study of readability and evolution for the future to come.

I don’t think your definition is badly chosen. In fact I think it is a pretty good demarcation between language ideals. However, I would define ‘kitchen sink language’ as one that has a bit of everything in the language itself and has the syntax to ‘support’ those bits of everything. Like a language that has lambdas, functions, methods, type classes, value types, box types, Types of types, macros, lifetimes, templates, multiple looping constructs… the list can go on. I think the real exemplars for ‘kitchen sink’ in this conversation is to differentiate between Go and C++. The amount of concepts in C++ is staggering and Go is in contrast brain dead simple. I think Rust is absolutely on the C++ side of this divide and is primarily what GGP was getting at in their comment.

Reply on news.ycombinator.com