Live data from Hacker News

Why Go is my favorite programming language

michael.stapelberg.de

61–70 of 256 posts

Re: Why Go is my favorite programming language

#61

Earlier quoted context omitted.

I know this is repeated often, but only because it apparently still has to: interface{} is very different from void*. It carries type-information with it. That makes it safe.

No, it's not safe. It's basically a way to disable compiler checks, so it is by definition, not safe.

It is way safer than void * : A void * can be cast to (and then used as) any arbitrary type, leading to all sorts of undefined behavior. On the other hand, the following code will just panic() (i.e. exit cleanly without corrupting memory).

  var x int = 5
  var i interface{} = &x
  *(i.(*string)) = "boom"

Re: Why Go is my favorite programming language

#62
post #55

Earlier quoted context omitted.

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.

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"…

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?

Re: Why Go is my favorite programming language

#64

Earlier quoted context omitted.

> go has a short list of reserved words I use go a lot now. However, I must admit I find the use of interface{} "aka empty interface, aka void*" a weird one. It's technically correct, but it's an odd semantic.

I know this is repeated often, but only because it apparently still has to: interface{} is very different from void*. It carries type-information with it. That makes it safe.

Safe as in nil not even being equal to nil any more, I know I'll sleep better.

Re: Why Go is my favorite programming language

#65

Earlier quoted context omitted.

No, it's not safe. It's basically a way to disable compiler checks, so it is by definition, not safe.

It is way safer than void * : A void * can be cast to (and then used as) any arbitrary type, leading to all sorts of undefined behavior. On the other hand, the following code will just panic() (i.e. exit cleanly without corrupting memory). var x int = 5 var i interface{} = &x *(i.(*string)) = "boom"

True, now imagine that program was controlling some kind of device and due to the panic it wasn't able to turn the device off.

Re: Why Go is my favorite programming language

#67

Earlier quoted context omitted.

> the only point directly related to that is that go has a short list of reserved words (which is true of most languages). The number of keywords of a language is completely unrelated to its complexity (see Brainfuck or Lisp).

On the other hand, see ABAP. https://www.slideshare.net/PrakashThirumoorthy/complete-list...

SAP ABAP syntax includes:

+ 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.

[1] http://www.se80.co.uk/saptables/v/vbak/vbak.htm

Re: Why Go is my favorite programming language

#68
post #55

Earlier quoted context omitted.

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.

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 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).

Re: Why Go is my favorite programming language

#69
post #67

Earlier quoted context omitted.

On the other hand, see ABAP. https://www.slideshare.net/PrakashThirumoorthy/complete-list...

SAP ABAP syntax includes: + 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…

> Golang can have less keywords, because it has less features.

So, you are saying… because it's less complex?

Re: Why Go is my favorite programming language

#70
post #40

Earlier quoted context omitted.

Re: getting tooling "right" and that driving adoption/popularity. I'll argue that Java and the JVM are very similar in this respect. Few will argue Java is a "good" language and the JVM has many shortcomings. However the ecosystem of IDEs, JVM tools, and decades of big company investment (Sun, IBM, Oracle) have created an amazingly productive environment.

Yes, my impression is that Go was created partly to be used in corporate environments to replace Java with a less verbose language that scaled well, and it seems to be doing well in that regard.

Sadly, it ends up far more verbose than Java when you have (as I did after trying to port a project from java to go) over 200 copies of the same observable, sorted, copy-on-write set implementation, because Go doesn’t have generics. And then you change one thing in one place, and gotta change it everywhere again.

No thanks.

Post reply on HN