And Rust's traits are a far more principled (and thus better!) approach to overloading than anything C++ has (Boost's concept checks?). Traits turn concepts into language entities that are directly expressible in Rust syntax, rather than in awkward English documentation.

It's also fun when you don't realize a particular function has a default argument until you make a function pointer to it and assign/pass it to something that you mistakenly think is compatible. Depending on how nasty your codebase's use of templates and overloaded functions is, this can be a nightmare to debug.

You made me curious how release 1.7 affects performance of popular routing packages for Go (Gin, Echo, Httprouter).

I don't see how that helps your argument. For loops are more than enough for that task, it's easily readable and universal.

And Go does support first-class and higher order functions so not sure what you're talking about here.

> [2]:

How's ditching inheritance in favor of composition "ignoring the last 40 years"? It's the biggest example together with goroutines that proves that phrase is a meme, and that we've learnt a lot on typing best practices as an industry over the past couple decades.

And as an added bonus, another thing that's a good example of Go actually looking back and improving upon what's been done before is the select statement. Most popular languages fall through by default with the switch statement.

Outside of examples on the internet, I can't recall right now the last time I've seen a switch statement in the wild that didn't break at the end of every case. Making the case (pun not intended) for a fallthrough statement and having switch/select break by default.

Agreed. Which is why switching your org from C# to Go is going to do nothing (at best) for productivity or project completion rates.

Edit: Likewise if you are having trouble hiring C# developers it is very unlikely you will have an easier time hiring Go developers (although for a few geographic locations it might be true).

Both Java and C# are really more suited to enterprise services. It is difficult at best to communicate with the underlying OS behind the VM. you really need to be using C / C++ to reach the kernel on Unix. Probably the same on Windows, though I'm guessing .Net provides some sort of integration.

Type classes alone don't give you anything like Go's interfaces.

Type classes plus existentials give you something kinda like Go's interfaces, but requires explicit casts (in the form of unwrapping the contents of an existential constructor and putting them into another existential constructor).

Type classes plus rank-N types can express Go's interfaces, but at that point Haskell already has subtyping, induced by subclasses. (Or else how do you think “a Lens is a Traversal” is possible?)

Yes.

> It takes months, even when using a simple language like Python. Or even BASIC, which was designed specifically for beginners.

I never said anyone can learn everything there is to programming in a week. I only said anyone can learn the Standard ML language in a week. You might encounter far more difficult things along the way, but they shouldn't be related to Standard ML itself.

I suspect your "pray" == monitor closely and fix fast (often never).

I agree it can be problematic that there is nothing in the language that indicates that the author is explicitly in 'pray' mode. It could well be that even a brief defence of a missing error check during a PR code review is not worth avoiding (un-triggered) err handling.

Put another way, you can make something that looks simple and pleasing, but hides a lot of complexity that's required to understand in order to be able to do your work.

Sounds like something that won't hold up as well over time.

Marketing.

The docs are quite clear on this behavior and say "Timer will send the current time on its channel after at least duration d." -- key words being at least and says nothing about when you choose to read from the channel.

See https://github.com/golang/go/issues/11513 and https://groups.google.com/forum/#!topic/golang-dev/c9UUfASVP... for some background.

Which doesn't make code easy to read when there are 10th of these blocks in a single function.

I wasn't aware that all of those working implementations had stopped working.

Popularity is just one dimension a language can be placed on. Java utterly dominates the volume of new code being written in regular industry and has most likely done so for the entire lifetime of Go.

And this says little about their other relative virtues.

As programmers, we deal primarily in abstractions. Our programming languages offer formal tools for creating and manipulating abstractions. In my view, any language that offers more tools for abstractions is better than another language that offers fewer such tools. As a professional whose primary job is to deal with abstractions, any new kind of abstraction is of interest. All programmers should be not only willing to be constantly learning new techniques and new abstractions, but we should be eager to learn and apply these things. Bigger toolbox => better quality of life w.r.t. work.

Even at my day job, I've heard things like "that's too computer sciency for mere mortals". I'm sorry, are we not computer scientists? Are we in the habit of employing people who are not professional programmers to write our software? And to think I'm the only developer in the office without a master's degree, as if they all decided that once they graduated they were finished learning...

Heaven forbid you should have to learn something! To educate yourself! To grow in terms of knowledge and skill! Do we have "development goals" every year for no reason at all?

As if spending an hour or two learning something would kill you!

AAARRRRRRRRGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHH!!!

But the classpath and jars? Write your application, 'gradle distZip', copy zip to target and unzip, invoke the launch script Gradle generated, done.

And if you can't be bothered to unzip, there's: https://github.com/pivotal/executable-dist-plugin

I agree with the classpath issue and hopefully it will be fix in Java 9. Separate jvm install? Why? JVM is backwards compatibility.

> And let's be honest, how many people target more than Linux/x86_64 on the server side.

Those that develop non server apps since Java is a general-purpose language.

So you surely should be aware of the existing options to compile Java to native code, just like Go.

Most languages which provide a reduce() permit programmers to provide an initial "carry-in" value. This is a neater and more useful way to handle the cases of a zero- or one-element list. Moreover, it lets you do more interesting things with the reduction. Consider the following, using ES6-style JavaScript to collect a set of the unique values of a list via reduce():

    function unique(list) {
    	return list.reduce(function (sofar, item) {
    		if (!sofar.includes(item)) { sofar.push(item); }
    		return sofar;
    	}, []);
    }

Edit: karma_vaccum123 has greatly edited the gp comment but for the record, Google has been using golang since 2007.

There is little need for this kind of absolutism. Citing a haskell as one the best language in a contest where op ask about rust and c++ is dangerous.

To op : if your domain calls for modeling relatively 'type stable computation', and need strong correctness garanty, haskell is a great match.

I disagree. You should look at OCaml (and Standard ML, though the eqtypes in SML are a botch): generics are dead simple there. Much simpler than Go interfaces, in fact.

Sure, there's always "one more thing" you could add, but that's always true for anything in any language. Slippery slope is a fallacy for this reason.

> or else you force people to use dynamic checks/allocations/casts that reduce your type-safety and bog the code down relative to the "optimal" design

Which is what happens even more if you don't have generics!

A language designer can provide let polymorphism, refuse to add more, and call it a day.

> (higher) order/kinded types,

This is orthogonal to parametric polymorphism. Higher-kinded types are problematic for inference, and the way Haskell has implemented them has unfortunate consequences for modularity.

> where clauses,

This is just syntactic sugar. (FWIW, what I think Rust needs is better inference, rather than ways to make type signatures less verbose.)

> dependent types,

This is unrelated to parametric polymorphism.

> specialization

This is antithetical to parametric polymorphism.

> or else you force people to use dynamic checks/allocations/casts that reduce your type-safety and bog the code down relative to the "optimal" design.

Standard ML doesn't have dynamic checks or unsafe casts, and I don't find myself longing for them.

I now generally prefer Haskell.

You say that like it's a small thing, but what proportion of bugs in C code does that cover? Im guessing you'd hit over 50%.

Go 1.7 performs nowhere near the set of optimizations that GCC and LLVM do. GCC/LLVM have a huge number of algebraic simplifications (InstCombine), aggressive alias analysis, memory dependence analysis, instruction scheduling, an optimized instruction selector, a highly tuned register allocator with stuff like rematerialization, SCCP, etc. etc. It will take years and years for Golang to come close.

> Go (the language) can be made just as fast as C (the language), for many cases.

No, it can't. The M:N scheduling model will always have some overhead relative to 1:1 if you don't need the performance profile of C10K-style servers. The dynamic semantics of "defer" is an unavoidable performance tax over RAII. Unwinding is mandated by the language, inhibiting some optimizations. There is little control over allocation: language constructs allocate in ways that are not immediately obvious. The fact that interfaces result in huge numbers of virtual calls results in a good amount of overhead that (unlike Java) Go can't even eliminate with inline caching, because it's AOT compiled. This is just off the top of my head.

> Go has the advantage of making it much easier to use multiple processors, though.

Not really. Go's parallelism primitives are just as low-level as those of C. The "one size fits all" scheduling algorithm is a poor fit for getting the most performance out of multicore. The lack of generics is a real problem: it prevents you from using optimized concurrent data structures without paying the tax of interface{} or going through code generation hoops.

In any case, the lack of SIMD basically kills Go's applicability in these domains.

Conversely if you're using C/C++ through a ton of heap/virtual pointers then you're losing a lot of the value the language brings and should be using something higher level.

After previous implementation has made Go a lot slower.

GHC 8 also introduces the Strict and StrictData pragmas[1] which allow you to make a module (or its types) fully strictly evaluated.

[1]: https://ghc.haskell.org/trac/ghc/wiki/StrictPragma

Here's what my experience is with certain features in languages: They enable some programmers to do great things, while also enabling a few programmers blinded by hubris to do maddening things. Over the life of a large project, the unfortunate coincidence of different pieces of hubris driven code sometimes causes an outsized amount of frustration.

Analogy: Most people, most of the time, have the good sense to operate cars, drones, and high powered laser pointers without becoming a dangerous nuisance. However, there is a potential for a minority of users of such devices to cause far more than their share of public nuisance. Therefore, there are rules and restrictions about how such things are used by many people at scale.

So yes, as an individual you are probably just fine. But you aggregated with a whole bunch of other programmers is likely to be a different story.

https://en.wikipedia.org/wiki/Tragedy_of_the_commons

Rewriting code is expensive. As my office knows well. We maintain lots of old embedded systems and have to periodically rewrite or rehost it because the old hardware platforms aren't available or aren't performant enough for new features. These become multi-year, multi-million dollar projects, for relatively little gain.

By ensuring that developers and architects conform to certain conventions, it means (in theory) that this code maintenance is much cheaper, and that rewrites can be avoided or minimized. This is a good thing and lets organizations be more flexible and productive, as their time and money is no longer wasted on the old things, but can be spent on the new things.

In reality, these two methods do completely different things. `std::mismatch` is a completely generic algorithm that 'returns the first mismatching pair of elements from two ranges', which can be used for much more than `strings.HasPrefix`.

Sorting a slice is a pretty obvious counterexample.

No.

Python: toCheck.startswith(prefix)

JavaScript: toCheck.startsWith(prefix)

Haskell: prefix `isPrefixOf` toCheck

What other languages does Go compete with that don't have a "string starts with" in their standard library.

Since I feel I've proven my point about all other languages Go competes with having this function, what other helpful functions do you think Go has that it's competitors do not?

  to see if a string starts with another string in C++

  std::mismatch

  strings.HasPrefix(toCheck, prefix)

  toCheck.compare (0, prefix.length (), prefix) == 0;

  toCheck.StartsWith(prefix)

https://github.com/golang/go/issues/16721#issuecomment-24015...

...and I haven't felt this kind of pinch when using C#, ever. But what do I know? I'm just a .NET wage-slave pleb who's too mentally handicapped to see Go's glory.

Perhaps an example of where map/reduce is a significant improvement to the expressiveness would be appropriate for the discussion?

By the way, http://www.deathandtaxesmag.com/200732/google-admits-its-fam...

https://lparallel.org/preduce/

Second-class polymorphism is what Damas-Milner gives you: let-bound identifiers may admit more than one type, in which case every type they admit is subsumed by a type schema.

Second-class polymorphism rules out polymorphic recursion if you consider every recursive definition as syntactic sugar for applying a fixed point combinator to some expression of type `a -> a`, for whatever monotype `a`.

Actually, even Go isn't helping as much as it could here -- sometimes you want to have an array of objects that lays out each column (field) of memory contiguously, which Go gives you no easy way to do. But then neither does C or C++.

Isn't allocation just a couple instructions for basically GC languages?

When I see this link I get different impression.

http://mechanical-sympathy.blogspot.com/2012/10/compact-off-...

It is only heavy use of sun.misc.Unsafe and unidiomatic coding style that give Java semblance of memory efficiency.

   provide just let polymorphism 
   and ML-style type inference

My main caveat would be that even a basic language needs a mechanism to glue related code together, objects, modules, structs with row-typing, existentials, not sure. But something.

That's interesting. Why is that?

Clarity is good. Clarity comes from both including every relevant detail (which pulls away from terseness) and excluding irrelevant details (which pushes towards terseness). Clarity also comes from saying everything that has to be said exactly once and no more than that (which pushes towards terseness).

Unfortunately, when you program in Go, you often have to pay attention to irrelevant details, and you have to say what you want more than once.

> Is safety the only issue or always the top priority?

The benefits of typeful programming go beyond type safety. They also include: “economy of thought”, “fearless refactoring”, “less time wasted on fixing stupid mistakes”, etc.

For me, it's entirely about expressiveness. This:

    reverse: 'a list -> 'a list

    reverse : list -> list

Beyond being able to express and communicate intent, there's the added benefit that the type system can statically check that the input elements are the same type as the resulting elements. There's also no worry about information loss associated with subsumption (the rule of subtyping that allows a value of a subclass to "become" a value of one of its superclasses, losing specificity in the process which may only be regained with a type cast (this is one reason I tend to favor row polymorphism as well -- no subsumption means no information loss and no need to cast)) because no subtyping is involved in this case of parametric polymorphism.

Parametric polymorphism is simple and well understood. And not exactly new either: it has been understood for some 40 years already.

> I could see an argument for parametric collections and parametric sorting in Go.

C++'s <algorithm> header is proof that there are lots of algorithms that benefit from being expressed generically, not just sorting.

> In your experience, what kind of "cost" has there been in unsafe casting to use collections?

Without type safety, there's a disincentive for decomposing things into smaller parts, because the cost of manually verifying that the parts are compatible is greater than the benefits of decoupling them. Would a Go programmer even dream of bootstrapping fancy data structures from simpler ones?

> Even in environments like Smalltalk, where all use of collections amounts to "unsafe casting," I've rarely seen situations where a mistake of this type wasn't found trivially.

At scale, the law of large numbers says that even improbable events will occur every now and then. Unfortunately, a program with even one bug is still incorrect.

> The argument is that simpler is better at scale. Airplanes can move freely in 3 dimensions, but airliners are constrained to fly in particular ways around busy airports and cross country.

For one, I just debate the premise the simplicity has anything to do with cardinality of features/concepts. But let's take that argument at face value: then why _not_ assembly if this is the case? Why not a language with the absolute minimum number of concepts? I think if you interrogate this premise you'll find it doesn't hold a lot of water and that Go doesn't really aspire to this goal anyways. I think we have some amount of working memory for being able to intuit programming with a certain number of concepts. There's a valid argument that some languages suffer by breaking that barrier (though I personally think Go underestimates where that barrier is), but it seems incorrect that language designers should be optimizing for a minimal number of features.

I think complexity at scale has more to do with features that interact poorly (or cause poor interactions more frequently with a larger number of people). Specifically its about composition. For instance, there's a valid argument to be made that asynchronous exceptions (i.e. the ability to interrupt another thread with an exception) and locks poorly compose. Mutable state is a common example of a feature that's a detriment to composition. But parametric polymorphism, if anything, gives us a much greater ability to compose. It allows us to define functions that work on data arbitrarily parameterized by other types, which makes them conducive to composition. And likewise, we don't suffer ability to reason about composition at scale with parametric types. A parametric function does not gain complexity as more team members are added, more code is written, more deadcode accumulates, etc. Parametricity changes nothing at scale.

> In your experience, what kind of "cost" has there been in unsafe casting to use collections? Even in environments like Smalltalk, where all use of collections amounts to "unsafe casting," I've rarely seen situations where a mistake of this type wasn't found trivially.

That's an argument for Go to not have types. But Go does have types, and type safety is often espoused as a benefit of Go. If you're going to have types, it makes zero sense to me why you should not have parametric polymorphism, since this is the only way to have things like typed collections without opening yourself up to the possibility of casting errors. Frankly I find it bizarre that people claim that they have found type errors to be trivially fixable, because the scope of where a type error can be introduced is enormous in an untyped language... its literally every location that potentially calls into the code where the error occurs.

> Does your frustration come from having to abandon the "assured safety" the type system would give you, or does it come from an experience of the costs?

Yes, type safety is an enormous advantage to writing correct code in my opinion. It's one of the best mechanisms a programming language can give you for enforcing invariants about data. The curry-howard correspondence is a huge advantage to writing correct code. Every place a type checker isn't being used to delimit acceptable data is a potential source of a huge number of bugs. It's also a frustration because casting introduces conversation and type checking boilerplate that a type checker could ultimately take care of for you.

In VisualWorks, there were different two ways of writing a short script to verify this in a matter of seconds. You could also sometimes achieve this with a few cascaded searches through the Refactoring Browser.

It's nice to know that you remember stuff from the textbook. However, how often do you need to do something like this for real production code? Depending on what it is you normally do, it's entirely possible that you need to do this every other project. It's also possible that you never have a real need to do these things. (It's also possible that you never have a real need to do these things, but you do them anyways, which is far, far worse.)

> The law of large numbers certainly applies to >100 KLOC codebases, unless your bug rates are somehow magically two or three orders of magnitude lower than the average.

True, which is why I'm pretty confident that 15 years of Smalltalk development on many large code bases without running into a heterogeneous collection debugging conundrum is possibly a valid data point.

Contrast that with an endless parade of "hubris coding" in the same timeframe. My impression is that the damage caused by "hubris coding," or the gratuitous worship of "cleverness," far outweighs that caused by insufficient type information by 2 or 3 orders of magnitude. If you're going to be clever about applying your clever, you need to apply it in a fashion where it gives your company's business the biggest bang for the buck. Most coders in their 20's are just trying to impress their fellow programmers.

Please tell me how a code search performed by library author Foo will ensure that library user Bar won't break invariants Foo intended to enforce.

> What kind of nonsense is this?

In ML, I can prove that users my library can't use my library wrong. Maybe they won't be able to use my library at all - they type checker will reject every attempt. But it guarantees that, if they can use my library, they will use it right, in the sense that every invariant I enforce won't (and can't possibly) be broken by users.

For example, there may be multiple ways to realize the same ordered set as a red-black tree (balanced differently), but I can arrange things so that the difference can't be observed by users of the ordered set abstraction.

> The library users in Smalltalk would do such searches.

Library users shouldn't be in the business of enforcing invariants that are only relevant to the library's author. See? This is what I mean by “Smalltalk can't separate concerns”.

I'm not saying all of this to be mean. It's been known for quite a while that parametricity is the mathematics of abstraction and separation of concerns [0]. If you need to insulate users of your code from your design choices, you absolutely need parametricity. (Or “social conventions”, but those don't work in the long run.)

[0] http://www.cse.chalmers.se/edu/year/2010/course/DAT140_Types...

Most languages don't have abstract types (not to be confused with abstract classes!), so there's that. Abstract types protect invariants of modules from external tampering. This is a mathematical fact.

> However, that was your example. My argument is that's a really poor example. And now you are abandoning it.

I'm not abandoning anything. I'm only saying that the use cases of parametricity go far beyond parametric collections.

> I also like separating concerns.

Good! Then what do you gain from the existence of reflection (which is pretty much the opposite of type abstraction), or the possibility of sending wrong messages? This is as anti-separation-of-concerns as it gets.

Even more worrisome is what you have said in another post: “Decompilation in Smalltalk is trivially perfect, excluding local variable names, so closed source was fairly pointless.” (https://news.ycombinator.com/item?id=12340864) How can you pretend this is compatible with separating concerns? You're talking about inspecting the structure of arbitrary parts of a program!

> I'm also not a dynamic typing bigot, though you seem to be imagining you are arguing with one.

I've just made technical claims. I haven't personally attacked you. If you think I did, my apologies.

> How in the heck did you get here from parametric algorithms? This smacks of intellectual dishonesty.

I also request that you refrain from making personal attacks.

Anyway. Parametricity means more than you think. The inability to inspect the representation of an abstract type is an example of parametricity too.

> And earlier, you were claiming something about refactoring. Do you see a contradiction here?

Nope, I don't see it. Refactoring produces a different program with a different fixed structure. And the difference shows up when the old and new programs have different types. The reason why types are helpful is precisely because they guide the evolution from the old to the new program.