Hacker News Reader

Comment by wasted_intel | Hacker News Reader

The "easy to learn" argument is getting old. If the cognitive load never decreases, that's one thing, but initial ramp-up time shouldn't be a large determining factor. The MVC pattern, ADTs, functional programming, and so many other useful concepts were foreign at first, but have a substantial impact on how you think and work. With the exception of channels, Go doesn't add much when compared to other languages. Maybe that's a pragmatic choice, but it feels short-sighted to me.

View on HN

With the exception of channels, Go doesn't add much when compared to other languages.

It doesn't add things, it takes them away, notably exceptions, inheritance, generics. I disagree that's short sighted, it's precisely for long term maintenance that it becomes important to have less ways to do things. You may not agree with the choices, but they are not only about being easy to learn, more about being easy to read.

People just end up inventing idioms to handle those, anyway. Go's nil-check error handling is a prime example. That's a beautifully solved problem with ADTs, but it's impossible without generic support, for starters. Runtime errors, abound!

Go can handle errors in a very deterministic way, and it can easily recover from a weird panicked state. If someone's Go code has "runtime errors abound" then they probably didn't RTFM ;)

Ah, so when I think of deterministic error handling, I think of compile-time enforcement, like that provided by a Result or Option type. Those can be ignored too, though, although the effort to do so is a little bit more explicit. :)

> It doesn't add things, it takes them away, notably exceptions, inheritance, generics.

s/exceptions/error handling/

What Go proposes is awful for a modern language.

Go has error handling, it doesn't have exceptions for non-exceptional error cases.

Go has functions with multiple return values. That's not at all the same.

I didn't talk about multiple return values, did I? Every language has error handling support, some languages hijack an exception mechanism as a control flow path for non-exceptional error states. Returning error values is more ergonomic than exceptions, but Go's lack of sum types makes this slightly tedious (still better than exceptions).

Right, I jumped ahead; multiple return values is the how Go returns error values, it's not error handling itself. I don't like exceptions much either, but sum types / ADTs are just so nice for this sort of thing.

I agree that sum types are nicer, but I don't see how they constitute error handling in a way other return mechanisms do not. The difference isn't categorical, it's ergonomic.

I'm starting to find it weird that things like "error while passing string as int" trigger an exception rather than return an error.

There are always error cases to check when handling user input. It's a natural part of the program flow, not really an exception.

I would expect an 'exception' to be something like out of memory or disk corruption.

Presumably you mean "user provided a string which was supposed to be decodable as an int, but was not"? If so, then yes, this should be handled as an input error and not as an exception (programmer error). I don't know if you meant this as a criticism of Go or not, but you should find that Go programs almost always return errors (as opposed to panicking) under such circumstances.

Sadly our entire industry is based around being short sighted.

Quick to learn is only important if you have the lack of patience to spend the time to learn something you'll be using for years.

Our industry is hugely based on illusions and misconceptions. There are only few places on earth where people regularly rebuild the skyscrapers to build taller ones. The IT industry simply forces you to re-learn the same old paradigms in a new package just to gain 0.1% of something we cannot even define as an improvement.

Quite common in fashion driven industries.

One thing I've been looking at lately is the various strands of engineering (civil, electrical, mechanical). I've been looking for common threads and general principles that apply to software engineering that otherwise haven't been.

A part of what inspired that search is what you discuss: a huge amount of rework. Tools that shift like sand dunes. Many principles and best practice based on "this is what worked for us".

I can't seem to shake the feeling there must be a better way.

The fundamental difficulty is the blue sky nature of software. You can literally code anything you can imagine. Language semantics, algorithms, architecture, it's all up for grabs, it's all cheap, and the applications are unlimited. Compare with traditional engineering disciplines where you have massively constrained costs, materials, and even goals.

What would civil engineering be like if instead of the immutable laws of physics you had a system designed from the tiniest quark up to the largest galaxy by humans, and if that design was subject to change on a whim?

I think that attempts to unify traditional forms of engineering with software engineering are doomed to failure, because they're so different as vocations.

For example, the design and construction stages are indistinguishable (any sufficiently detailed design of software is effectively an implementation of the design). Normal engineering is not the same, and is likely one of the reasons that software prototyping often become the final product (which is definitely not true for traditional engineering). Fields like electrical engineering that use software engineering quite heavily are only similar to traditional engineering because of the traditional components of the other engineering discipline (electrical engineering requires circuit-board design that is distinct from fabrication, and prototypes are rarely promoted directly to the final product).

That's true. I don't think that there are major things in those disciplines that are directly applicable in a timeless fashion.

My main goal is to find out how these disciplines came about. How exactly did they settle upon their body of knowledge such that they can produce reliable results in the way they do. Not so much what those methods are, but rather how they came about. What is the common thread there and how, if at all possible, can we use that accelerate the same maturity in software?

Maybe it's a process that has to run its course? Maybe at 80 years old, if I live that long, I'll look on a very different kind of software development.

With that said, I also have Fred Brooks whispering "no silver bullet" into my ear on the other shoulder.

Maybe the other engineers would love to be able to do more rework, but since they deal with hardware, changing things is a lot more expensive. Why do you think that their ways are superior? Construction projects too run way over budget and sometimes even fail, just like software.

You make a good point. Maybe their ways aren't superior - I didn't consider this. In that case, perhaps the issue isn't because we need to be more like other engineering disciplines but less like.

I'm feeling for answers. I'm not saying I know what we need. I am, like I think everyone else is, still in the observation stage looking for hypotheses.

I did find evidence based software engineering. This offered some interesting papers. I recommend this. There isn't much and it's far away from a cohesive theory but hopefully we can get there, as a field, soon.

If someone is further along, or has some ideas, I'd love to speak with them.

This is what I most dislike about Go: it's a modest improvement. It could have been much better, with a higher-level and less verbose syntax and allow metaprogramming (e.g. like Nim).

Architecture is thousands of years old. Programming as we know it is maybe 60.

We're still figuring out how to do things correctly. Maybe we just figured out how to build a log cabin, but now some people are going back to mud huts because they're simpler.

Lot of new languages try do to everything which is imo a big mistake.

Huge success of mongodb was due to "easy to learn" advertisement, paired with getting shit done and rewrite later agile trend, and web scale.

Is this a positive or negative example?

It matters for large teams and when you got hundreds of languages to choose from. I am sure Haskell is great but after a couple of weeks studying it I realize I don't have time for something I don't know if will pay off or not. In contrast with Go you can see benefits almost immediatly

Two weeks is a tiny investment to properly evaluate a language. Haskell is tripping you up because you're likely new to proper FP and very strongly typed languages. Pushing past two weeks, even if you don't use it, will make you a better developer, and the next FP or strongly typed language will come more easily.

You probably mean statically typed, not strongly typed. The distinction is clarified in "What To Know Before Debating Type Systems":

https://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wr...

I didn't, actually! I don't know how else I'd express it, but I'm thinking of Rust, Haskell, etc's "step beyond" plain static typing with sum/ADTs, pattern matching, and exlusion of null. A seemingly small detail, but it does feel like it makes the type system more deterministic and "stronger", in a sense.

Reply on news.ycombinator.com