mikeschinkel

Nice technique, but wondering if the trailing "; exit" results in consuming non-zero exit codes passed to os.Exit() in the Go code?

I ran a very successful company (successful for a time) that sold Visual Basic developer tools via a printed mail-order catalog named VBxtras.

Two things killed Visual Basic:

1. The web. Visual Basic was first and foremost a Windows desktop app development tool, and their UI-first model of app development did not translate well to the web, or at least the attempts to translate to the web did not resonate.

2. Microsoft. Rather than continue the simplicity Visual Basic offered, Microsoft "improved" it by releasing VB.NET which abandoned the core simplicity that made Visual Basic so wildly popular among "Occupational Programmers," as Kathleen Dollard[1] and I lamented back in the day. The upshot was that former Visual Basic programmers fell into two (2) camps; they either:

A.) Abandoned VB for something else, or nothing at all, because they did not want to have to become a professional programmer, OR

B.) Switched to C# because if they were going to learn how to be a "real" programmer they might as learn C# and not C#'s disfavored sibling VB.NET.

I blogged about occupational programmers several times back then: https://mikeschinkel.com/tags/occupationalprogrammers/

BTW, the company that has developed XMLUI was one of our better vendors of VBX components for Visual Basic. They have since renamed to /n software, but at first they were named IP*Works (I think I stylized that name correctly per how they did at the time.)

[1] Ironically Kathleen is now leads the .NET Core CLI at Microsoft, and is also lead over VB, I think: https://devblogs.microsoft.com/dotnet/author/kathleen-a-doll...)

Wow. That looks painful.

Sigil soup!

As a counterpoint, I have many times had to interact with the those technologies, and thus been able to use their source code as packages and/or learn their source code techniques which I have then used in my own Go programs.

What does that prove? it proves that no single developer's anecdotal evidence can be used to validate a broad-brushed claim like "The language they are written in is irrelevant."

Interfaces are one way to inject stubs, and a good way, but not the only way. You can also use function values as callbacks.

Agree with your assumption, but then I also know that developers often read recommendations and convert them into dogma, ignoring the specifics for when those recommendations should be applied.

Early in my career I taught programmers and I was horrified to come back to one client and find they followed my advice, but not where it applied meaning that what they did was actively harmful.

Ever since that, I realized when a developer makes a recommendation they need to be very explicit about when it applies otherwise they are doing more harm than good and hopefully someone will publicly challenge their recommendation to bring their unstated qualifications to light.

PHP is not controlled by one main corporate entity.

{Runs, ducks, hides. :-D}

Deno 2.0 explicitly copied Go in many features, especially with dependencies being referenced via URL, and many of the CLI's commands are inspired by Go such as install, fmt, and test.

I recognized exactly that way back in 1995. I used to teach Clipper in the late 80s and early 90s and you could do so much with it. It's competitor was FoxPro, which was far less capable.

However, in hindsight after I quit using it I realized that Clipper developers often focused on perfecting code — myself included — whereas FoxPro developers just got shit done for the client/end-user. #fwiw

In all your comments you seem to be hitting the nail on the head.

Someone can say the German language is a bad language. But it is not the language that is bad, it is the person's perception.

When they try to evaluate German while thinking in English it is no surprise they consider it sub-standard. Germans, OTOH, are much better equipped to evaluate the German language than those who only know how to think in English.

(Full disclosure; my grandfather was German but I only know how to think in English.)

As a counterpoint, Go is currently the only language I do not find revolting.

And complaining about "thing string" vs. "string thing" seems high on pedantry.

Yes, there are aspects of Go I really dislike, but I find fewer things to dislike in Go compared to things I dislike in all the other languages I have programmed in.

Sounds like a lack of good code review.

But true enough.

You can only force everyone on a project to use a formatter if you are the one who has the authority to decree what will be done on the team. OTOH, if you are but a team member and you join a team where the manager does not think common formatting is important, then you get f*ck all.

So being built-in, idiomatic and expected cannot be over-appreciated.

Cool, thanks for the answer.

Just curious about your just curious; what is the architecture of the current Tumblr back end?

This appears to be 6 years old. Is it still relevant?

http://highscalability.com/blog/2012/2/13/tumblr-architectur...

> "Running them is as simple as `java -jar program.jar`."

That is several steps too complicated:

1. Do you have Java installed? 2. Is it in the path? 3. Do you have the Required Version of Java installed?

None of those need be issues with a self-contained compiled Go program. And that is one of the key reasons we chose Go over any other language.

(And for the other languages that can do the same, Go was the easiest to learn and potentially master.)

> "The last think you want for general server side programming and cloud systems programming is Java? Because of the JVM?"

Yes, for the smaller companies that do not have the effectively unlimited resources of Google and Amazon. Go is just so much easier to work with and deploy for my tiny company.

Then use panic() and recover() for that special type of use-case. Just as easy as exception handling.

But then you have to spend lots of extra time trying to discern between the errors that were okay, and the errors that actually indicate flaws in your code.

As they say, an ounce of prevention...

> If you say XML you lose (it is a config fmt get over yourself...).

"Besides that Mrs. Lincoln, how was the play?"

As someone who started Go when Modules were already available, I don't think you'll run into it (unless you try to use older packages.)

I would say you can't know if it will cause you pain until you try it. Using the metaphor, some people actually like certain types of pain, and pain is something that is very hard to understand simply by listening to the complaints of others.

I was one of the many who argued strenuously that they not add try(). I spent an entire day writing up my reasons who I posted to the ticket on GitHub.

Bottom line, try() had too many flaws — especially related to consistency with the rest of Go — to be an appropriate addition to the Go language.

Adding try() to Go would be like adding a disco ball to the Sistine Chapel. Sure, disco balls have their place, but some places are just not appropriate for disco balls.

Or as Yoda says:

"Do or do not. There is no try." (Fortunately!)

After working with Go for a while I actually find code with error handling easier to read because it is more clear to me what it happening. I look for the error handling as an indicator that the code can actually fail vs. code that cannot fail.

And maybe it's because I've developed a very consistent pattern, and when I find that there are too many errors to handle in a function it helps me realize the function is probably doing too much and needs to be split into multiple functions.

IMO it is all about training your brain and being accepting enough to work in the dialect of the land, as opposed to demanding to speak English when living in France. :-)

> That's why exceptions work so well in most languages

But there are many people including some well-known and highly-respect people who believe that exception handling in fact does not actually work well:

- https://www.joelonsoftware.com/2003/10/13/13/ - https://blogs.msdn.microsoft.com/larryosterman/2004/09/10/st... - https://www.atlassian.com/blog/archives/exceptions_are_bad - https://stackoverflow.com/a/1736320/102699 - http://xahlee.info/comp/why_i_hate_exceptions.html - http://www.lighterra.com/papers/exceptionsharmful/

#justsaying

Given that I have worked with VB long before .NET even existed, I have a broader view of it than just the more recent criticisms.

VB's biggest problem IMO is that it tried to compete with C# instead of maintaining its original raison d'être which was to be a highly productive tool that required very little programming skill to be able to start building real solutions for business use.

But I digress...

You do not have to be precise in Go either, and you don't have to know all the faults. All you have to know if where a return value that implements the interface `error` is not nil.

Visual Basic is hardly academic; they is a tremendous amount of line-of-business code that has been written in VB over the past 25 years.

But yeah, Go dev do not see VB's features as being "features."

Curious, do you see other communities that are not passionate about their languages?