Assorted Thoughts on Zig and Rust

Re:Assorted Thoughts on Zig and Rust by q3k on Tuesday October 20, 2020 @08:47AM (#24836654)

As coined by Google engineers: software engineering is programming integrated over time. Languages that are paragons of cutting edge PL research unfortunately tend to forget that. Go’s simplicity tends to be brought up as a negative trait (dumb language, dumb users, etc) mostly by those who weren’t yet woken up by a page that required them to quickly read, debug and fix things. Or even jump into another team’s codebase to do the same thing. Last thing on your mind then is the type safety and elegance of a language.

[ Parent | on HN ]

Re:Assorted Thoughts on Zig and Rust by mcherm on Tuesday October 20, 2020 @09:31AM (#24837040)

> Go’s simplicity tends to be brought [...] mostly by those who weren’t yet woken up by a page that required them to quickly read, debug and fix things. Or even jump into another team’s codebase to do the same thing. Last thing on your mind then is the type safety and elegance of a language.

Actually, type safety can be quite useful in such a context: it allows the person who designed the types in use to enforce certain restrictions on the developer who is hurriedly adding code to an unfamiliar codebase, thus reducing the requirement for that developer to understand larger issues in the system.

[ Parent | on HN ]

Re:Assorted Thoughts on Zig and Rust by rob74 on Tuesday October 20, 2020 @10:23AM (#24837613)

On the other hand, more often than not the developer who is (more or less hurriedly) adding code is trying to do something that the original designer didn't think of beforehand, and because of that they now have to jump through additional hoops to make it work...

[ Parent | on HN ]

Re:Assorted Thoughts on Zig and Rust by q3k on Tuesday October 20, 2020 @10:37AM (#24837804)

This is a good observation. Some of the best codebases I’ve worked with are the ones whose authors insisted on keeping things easy to modify or remove (not by introducing unnecessary abstraction, but by simplifying things as much as possible). Some of the worst codebases are those where the author assumed that their elegant solution is ultimate and will never be read in circumstances other than to be admired.

[ Parent | on HN ]

Re:Assorted Thoughts on Zig and Rust by smiths1999 on Tuesday October 20, 2020 @10:21AM (#24837590)

I don't disagree, but this goes both ways (and I typically only see one side of this argument put forward). They also allow the person who designed the types to make the types so complex that the average user cannot understand what is going on. You may argue "well that person has no business looking at the code" but sometimes you have to look into other people's code when you are debugging an issue.

No doubt type systems can allow you to write safer, more robust code. But they can also allow you to introduce new risks to your codebase, one of which is difficult to read/understand code.

[ Parent | on HN ]

Re:Assorted Thoughts on Zig and Rust by dnautics on Tuesday October 20, 2020 @11:18AM (#24838330)

I don't think that people complain about Go's simplicity. People complain about the hamfistedness of Go's simplicity. The downstream effects of it include, for example the wat that you handle JSON in Go.

But there are a lot of quite frankly crazy choices, like making (milliseconds) an integer type that is incompatible with numbers. This means to multiply an time with a non-constant integer, you have to cast an integer to millisecond type first, then multiply. Which breaks the brain of a scientist like me and makes me want to throw my computer out the window.

My daily driver is Elixir, and it's not impossible to jump into totally foreign code and debug it. In fact, just the other day I did an interview where the 20 minute technical problem was drilling down from the frontend into the backend of a new-to-me system and finding the logic bug in a database query that was causing the wrong data to be surfaced.

[ Parent | on HN ]