[wyager]

What do you think is worthwhile about Go? I agree that the tooling is nice, but beyond that, there is nothing interesting to me. Goroutines aren't interesting; languages like Erlang and Haskell got green threads right many years before Go was on the scene.

[kjksf]

You should ponder why Erlang or Haskell achieved a fraction of Go's adoption despite being on the market 20+ years longer.

Some people see languages as a bag of features (immutability! generic programming! laziness! operator overloading! algebraic types! hindley-miller type inference! pattern matching! exceptions! manual memory management!). See http://yager.io/programming/go.html for an example of that line of thinking.

Those people won't get Go.

Designing a language is not about cramming every feature you can think of. It's about making good trade offs.

A trade off is: you get something but you also loose something.

I use Go because it made the biggest number of good trade offs.

Or to put it differently: I program in Go because when writing code, it irritates me less than other languages.

If you want a longer explanation of that: http://commandcenter.blogspot.com/2012/06/less-is-exponentia...

[wwweston]

> You should ponder why Erlang or Haskell achieved a fraction of Go's adoption despite being on the market 20+ years longer.

This line of thinking serves more to call in to question the engineering and management cultures we have than it does to reflect poorly on Haskell and Erlang, and if it's true that Go's essential strength compared to them is that it is well-fitted to these cultures, that's not particularly flattering, however locally practical it may be.

[AnimalMuppet]

That sounds almost like denial to me. "If everybody doesn't adopt what I think they should, it has to be because they're dysfunctional! It can't be because the stuff I like is less generally applicable than I think it is!"

If people disagree with you, your default assumption should be that they are looking at different evidence than you, not that they are incompetent or stupid.

[jshen]

If languages like Haskell and Erlang gave a competitive advantage, wouldn't we see companies which used them succeeding over those that don't?

Maybe Go is fitting into the cultures that succeed, and if that's the case, well it's the better choice, right?

[lmm]

> If languages like Haskell and Erlang gave a competitive advantage, wouldn't we see companies which used them succeeding over those that don't?

We are. WhatsApp generated a flurry of interest around Erlang. Heroku uses it. I'm sure there are more examples.

Google is at this point already a large corporation and probably already in decline (IMO). The tools they use are optimized for interchangeability of mediocre programmers, not for high productivity from a small team. Go is a perfectly good Java 1.4.

(There's Docker using Go, but I think their whole approach is a bad idea).

[jshen]

You are seeing companies that use those languages suceeding at a higher rate than those that don't? I bet I can find 10 succeeding that use ruby or node for everyone that uses Erlang.

We could also look at the open source world. For every riak there are 10 java sucesses of a similar kind.

We'd need to do some real statistics but my bet is that we see no benefit from those languages in terms of success of the business.

[lmm]

> I bet I can find 10 succeeding that use ruby or node for everyone that uses Erlang.

But that's not the question, is it? There are a lot of companies succeeding with ruby or node, but also a lot of companies failing with them. I'll bet the strike rate is better for Erlang companies.

[pjmlp]

> If languages like Haskell and Erlang gave a competitive advantage, wouldn't we see companies which used them succeeding over those that don't?

Like these?

https://www.haskell.org/haskellwiki/Haskell_in_industry

https://www.erlang-solutions.com/industries

https://ocaml.org/learn/companies.html

http://fsharp.org/testimonials/

[codygman]

The stock price of Standard Chartered is 939 GBX currently.

[wcummings]

I get the impression some of the folks in the Golang crowd are "Blub" programmers [1]. It's not so much a matter of simplicity and trade-offs as it is a matter of "I don't need things I don't know about", which isn't a good argument to use Golang.

[1] http://www.paulgraham.com/avg.html

[enneff]

Most Go programmers I know, including the language designers themselves, have a lot of experience in more feature rich and expressive languages. What appeals is the simplicity of Go, which gives you a lot less of a language to think about, so you can just think about solving problems instead.

“I like a lot of the design decisions they made in the [Go] language. Basically, I like all of them.” – Martin Odersky, creator of Scala.

I don't think anyone would accuse Odersky of being a "blub programmer."

[jeremyjh]

Martin has something nice to say about everyone's project. I seriously doubt he likes that a new language was created in 2009 that allows null references. But we'll never hear about it if he doesn't. Still, that doesn't make him a Go programmer.

[tree_of_item]

This is a great way to insult a bunch of people and start a fight.

"Beating the averages" is not a very good essay, I don't think you need to drag it in here.

[djur]

"Blub" as a concept isn't really useful anymore. I've seen people attacked as "blub programmers" for criticizing Go for its lack of features. At worst it's a personal attack ("you are a short-sighted programmer"), at best it's kind of supercilious ("language X is great, it's just over your head").

[Dewie]

I think "blub" is just another example of "you don't know what you don't know", which is always going to be relevant. And not everyone have tried, or intend on trying, obscure/sophisticated/mind-bending programming languages. And that's fine, since we all have different interests (as long as we don't try and pretend that we are very knowledgeable about something which we don't really have an interest in pursuing).

But to call someone a "blub programmer" does come off as quite rude.

[timtadh]

I feel like you haven't met a lot of Go programmers in that case. The programmers I have met who use Go or are interested in it are often genuinely good programmers. Of course there are "crowd" followers in any language as popular in Go but Go is not a "Blub" language nor does it attract Blub programmers.

Do I as a Go programmer sometimes wish that Go had feature X. Of course I do! I want that feature when I want that feature. But, I find Go to occupy an extremely practical position in my personal programming language continuum do to its fairly unique mix of features. Note, it is not the features themselves that are unique many languages individually have them. Indeed, they often also include features I miss in Go. Rather, it is the particular mixture which is useful.

EDIT: To respond directly to the Blub article.

Features pg calls out for LISP:

    Garbage collection, introduced by Lisp in about 1960, is now widely
    considered to be a good thing. Runtime typing, ditto, is growing in
    popularity. Lexical closures, introduced by Lisp in the early 1970s, are
    now, just barely, on the radar screen. Macros, introduced by Lisp in the mid
    1960s, are still terra incognita.
 

Go score card:

    Garbage Collection [x]
    Runtime Typing [p]*
    Lexical Clusures [x]
    Macros [ ]

    * Go has some dynamic typing capabilities but nothing like Python or LISP.
      Many would consider that a "good thing". It partially depends on what you
      are doing.

Go has a 3/4 on the score card of features. Macros are of course enormously useful but also very difficult to shoe horn into a c-family language properly since they need to be expanded at compile time (unless you just go ahead and embed you compiler backend into the runtime system of your language. That would be kinda of crazy/awesome but you could do it). Rust has of course proven the utility of such a choice.

I can't speak for pg, but Go has many fantastic features and is not a Blub. The features which are missing are not, by and large, features of LISP.

EDIT 2: To add some more fuel to this fire...

pg concludes the article with:

    During the years we worked on Viaweb I read a lot of job descriptions. A new
    competitor seemed to emerge out of the woodwork every month or so. The first
    thing I would do, after checking to see if they had a live online demo, was
    look at their job listings. After a couple years of this I could tell which
    companies to worry about and which not to. The more of an IT flavor the job
    descriptions had, the less dangerous the company was. The safest kind were
    the ones that wanted Oracle experience. You never had to worry about those.
    You were also safe if they said they wanted C++ or Java developers. If they
    wanted Perl or Python programmers, that would be a bit frightening-- that's
    starting to sound like a company where the technical side, at least, is run
    by real hackers. If I had ever seen a job posting looking for Lisp hackers,
    I would have been really worried.

Note, he explicitly says here: not all languages are the same. He would worry when a company wanted Python programmers. Why? Because to him Python mixture of features represented a nice chunk of what LISP is providing him. Let's do another score card:

Python Score Card

    Garbage Collection [x]
    Runtime Typing [x]
    Lexical Clusures [x]
    Macros [ ]*

    * It is somewhat possible through black magic hackery to create an AST level
      macro in Python. It is messy. It is cool. It's kinda crunky. And I am not
      sure anyone has ever seriously used this ability. It certainly isn't main
      stream. Checkout https://github.com/lihaoyi/macropy for inspiration.

Norvig agrees with this assessment: http://norvig.com/python-lisp.html . Given that many people are ok with moving from Python to Go <https://www.reddit.com/r/golang/comments/2aup1g/why_are_peop... it seems reasonable to conclude that Go is an exceptible replacement for Python. Something no one has concluded about Java (for instance).

Therefore, I believe pg would have been equally worried or almost as concerned about Go programmers as Python programmers.

[TheHydroImpulse]

> Macros are of course enormously useful but also very difficult to shoe horn into a c-family language properly since they need to be expanded at compile time (unless you just go ahead and embed you compiler backend into the runtime system of your language. That would be kinda of crazy/awesome but you could do it). Rust has of course proven the utility of such a choice.

Rust doesn't do that. Rust expands the macros at compile-time. Integrating the whole compiler into the runtime wouldn't make much sense considering what area Rust is targeting.

It's also recommended to not link a crate that is used during runtime with the compiler or parser because they're fairly big and would bloat your final build by a large amount.

[timtadh]

yep. I never meant to imply that rust macros were expanded at runtime. I was trying to use rust as an example of a c-style langauge with a nice macro system.

[lmm]

Actually, to be a little more constructive about this: I'd be really interested to hear from anyone who's used Go after doing a serious project in any of Haskell, Scala, F# or OCaml. All the Go advocacy I read seems to ignore that this language segment exists, and all the Go programmers I speak to seem to take a very "blub" position on features like pattern matching, ADTs, and the various things I'd summarize as "good type systems". So it would be great to hear from someone who's used these things seriously, understands their advantages, but still thinks Go is making the correct tradeoff.

[timtadh]

I use Scala at work. I would rather write in Go than in Scala. While there are many things to like in Scala there are also many misfeatures such as the `implicit` key word which can create a lot of spooky action at a distance. Scala is an engineering tour de force and has many interesting ideas. However, I find that it has too many features and has a syntax with encourages obscure code. In contrast Go may be verbose at times but it is always very easy for me to read and follow.

I recently needed to dive into a legacy Scala code base which had not been worked on in a year. The engineer who had written it had moved on from the company and no one knew how it worked. The code was extremely difficult to read and reason about. Some of this was do to the programmer who wrote it but some of it was also do to language features. Is it possible write clear and concise Scala? Absolutely! But, the language does not necessarily encourage that style at this time.

Other functional languages I have used include: Scheme and SML. I want to check out OCaml next. I have also played around a bit with F* (not F#).

[lmm]

Languages without decent compile-time type systems are pg's own blub.

[vorg]

pg writes about macros as the top of the blub ladder whereas you mention compile-time type systems, but I'd say it isn't a ladder but a twin-peaked hill, i.e. strongly-typed lazy functional code (e.g. Haskell) and dynamically-typed variadic homoiconic code (Lisp). They have an "impedance mismatch" such that they don't inter-translate very well, unless they use clunky addons like Template Haskell macros or Typed Clojure annotations. The pure form of each language, however, is based on two mutually exclusive foundations, i.e. strongly typed auto-curried parameters vs variadic untyped macro parameters.

The strong typing and lazy evaluation of Haskell makes it easy for functions to take only one argument at a time. Although a function could take a tuple parameter, it is usually rewritten to take each component of the tuple as a separate parameter, which makes the strong typing and built-in currying simple, higher structures like monads possible, and a syntax to suit this style. Lisp functions and macros, on the other hand, must be variadic to enable the homoiconicity of the language. It's therefore much more difficult for parameters to be typed, or to curry them. The syntax requires explicit visual nesting.

The poster child of each style, monads and macros, are thus two peaks in language abstraction simply because of these different required foundations of each, and if you, lmm, have achieved Haskell-style enlightenment, then dynamic variadic homoiconic languages are your blub.

[lmm]

I use scala so I have both (somewhat clunky) macros and types. I am not unaware of the costs of clunkiness or the merits of the lisp approach, and I have not stopped looking for a language that can combine both advantages - in contrast to pg, who seems to dismiss the value of strong types without ever having used them seriously.

[AnimalMuppet]

You're right, but don't assume that there are only two peaks. That's making the same mistake you're arguing against.

[eudox]

>Macros are of course enormously useful but also very difficult to shoe horn into a c-family language properly since they need to be expanded at compile time (unless you just go ahead and embed you compiler backend into the runtime system of your language.

No, that's not necessary at all, with Rust-like macros which are simple pattern->template things. Macros have zero runtime cost.

[timtadh]

I totally agree I made this point badly.

[cbp]

Some people look at a new language and don't see anything that proves it was made after the 1970s.

[zzzcpan]

And I hope it stays that way. We don't need more features, we need to address psychological issue of mistake-making.

[wyager]

> We don't need more features

You may be a victim of the Blub paradox. There are many useful and powerful features missing from languages like Go, and many of them (like powerful type systems) exactly address human mistake-making.

[zzzcpan]

No need to get personal. I was talking about all the features in all the languages, not the ones in Go. And yes, we don't need more new features, we have plenty.

However, none of the languages I know of address psychological issues. Does type system reduce mistakes or introduce? Certainly both, don't know which one more though. But the question itself is wrong. It's not the type system who makes mistakes, humans do. And humans have brains. And brains are limited in their ability to do some thing while keeping other things in mind. And if among other things types happen to be present and mistake was made, than one could say types added to that mistake. And if types were not something programmer needed to think than type system certainly didn't add to that mistake. Things are not as simple as most programmers tend to think. Features don't matter how they think they matter. And research in language design was broken since the beginning of times and, sadly, still is.

(if you read "no silver bullet", "out of the tar pit" papers and couple of recent ones on bugs you should get the idea of how bad things are with mistake-making research)

[tomp]

How does a type system introduce mistakes? Unless it's unsound, of course (as is Java's and Dart's).

[f2f]

well, rust has all those powerful features. it's been out in the open for exactly as long as Go has.

[djur]

Rust isn't nearly as stable as Go. It still hasn't reached the state that Go was in when it was released outside Google. That's not a judgment of Rust, just a result of it being developed in the open instead of inside a company, and it being much more ambitious than Go.

[Dewie]

Rust 0.1 came out in the beginning of 2012, about 3 months before Go 1.0 game out (or go1). In the meantime, Rust has changed a lot and is only now close to a 1.0 release.

[ansible]

Designing a language is not about cramming every feature you can think of. It's about making good trade offs.

Indeed. And the hallmark of the really good design is to examine the interactions of those features and see how well they mesh together. And what they imply about how actual programs are designed and maintained.

[thirsteh]

While I agree with these arguments, the purpose of Go is to Get Stuff Done (TM), and the main purpose of Haskell is to foster PL research and semi-formal methods. It's not really fair to say Haskell is unpopular because it crammed a bunch of things inthere: It is very popular in the niche it was designed for. Go just has a wider appeal.

And remember not to equate popularity with quality. We're all using JavaScript because that's what you need to do in the browser, not because it's a particularly good language. (Not that Go doesn't deserve the adoption it's gotten. It's great to see people ditching clunky Python/Ruby/C++/JavaScript stuff for Go.)

[macu]

> I program in Go because when writing code, it irritates me less than other languages.

This is how I feel too. There are countless styles of prose, but some styles are restricted deliberately for aesthetics or practical reasons. I prefer to write prose in plain terms, and Go enables me to write code the same way. Some languages more than others have parts that stick out in odd ways, and add unwelcome personality to my code.

Yet sometimes I wish to put higher concepts into abstract terms, and Go is less expressive here. You can't always shape things the way you want, and you can't build reusable parts with the same flexibility as in other languages. But, when it comes to tinkering and giving form to ideas, I am more productive working with a basic set of LEGO than a box of all the specialized pieces someone may have thought I might ever find a use for.

[dragonwriter]

> You should ponder why Erlang or Haskell achieved a fraction of Go's adoption despite being on the market 20+ years longer.

Because Google.

In longer form, because Google is big and Go is well-enough-adapted for problems Google has (there may or may not be better solutions, and there may be some NIH factor going on in Google favoring it, but its at least good enough), and because the fact that Google is big and behind Go, that gets it lots of attention and interest and use even in places where it may not be as well suited as alternatives or what it is replacing.

[coldtea]

>You should ponder why Erlang or Haskell achieved a fraction of Go's adoption despite being on the market 20+ years longer.

Programmers liking confortable algol like syntax, and Google pushing it?

[tptacek]

That's a reductive summary of goroutines. I don't doubt other languages have competitive features, but let's be clear about what the feature is:

* Lightweight threads with a scheduling and state overhead low enough to run hundreds of thousands of threads at a time.

* Seamless integration with the language, without any rituals or incantations needed to invoke them; you can, for instance, trivially pass closures from goroutine to goroutine.

* A data sharing scheme that makes sense with promiscuous threading ("synchronized" data structures often don't, because they'll end up serializing threads)

Lots of languages have green threads, but not all these properties.

I'm guessing Haskell does? I don't write Haskell, but my impression is that it has everything.

[lobster_johnson]

Erlang has the first two concepts nailed down.

I don't know what "data sharing ... with promiscuous threading" is, but Erlang is functional and immutable, so data sharing only exists in the sense of passing immutable data structures around. Synchronization issues associatied with mutations don't exist for in-memory structures since it's all read-only access.

I don't know Haskell's concurrency tools very well, but I believe it can provide much of the same functionality as Erlang, but the whole OTP toolset is missing — just as it is in Go. (Certain aspects of OTP can't be implemented in Go at all without additional changes to language/runtime.)

[tptacek]

Neat. You can start an Erlang process (or whatever they're called) with an anonymous function, and pass it another anonymous function that closes over another lexical environment?

[jerf]

Yes, both in Haskell and Erlang.

For me, Go's big win is that I can finally bring this, the right way to do it, to work, because it's the first time this paradigm is present in a conventional imperative language, not that it is the first in general. Many other languages got it right in theory before Go, but there was always some practical stopper, involving some obscure programming paradigm that I stood no chance of getting buy-in on (from engineering or management) or an ecosystem that simply couldn't be reasonably be called production-ready across the set of tasks I needed to accomplish. Go finally gave me almost everything I wanted for work. If it isn't everything, well, that's life sometimes, you know?

[hyp0]

Like Java's strategy (http://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java....)

  Java is a blue collar language. It's not PhD thesis
  material but a language for a job.  Java feels very
  familiar to many different programmers because we
  preferred tried-and-tested things.

[lobster_johnson]

Absolutely:

    do_stuff() ->
      GetAnswer = fun() -> 42 end,
      spawn(fun() -> io:format("The answer is ~p\n", [GetAnswer()]) end).

Here, GetAnswer is a closure, as is the anonymous function given to spawn() function.

[jussij]

And here is why these functional langauges will never make main stream.

I've, been programming for 20+ years and I look at that code and say what the f*k?

Ooh, it's the functional stuff. Ok, move on.

[lobster_johnson]

Seriously? I mean, Erlang has some gnarly syntax, but this is really basic, and translates directly to anything you'll find in JavaScript, Go, Ruby, Scala, C++, even Java.

Let me take you through it:

    do_stuff() ->

This declares a function do_stuff(). It's exactly like:

    function do_stuff() { ... }

Everything after is the body. Unlike many languages, Erlang uses comma, not semicolons, as statement separators, function bodies end with a "." so a function follows the form:

    do_stuff() -> a, b, c.

Here, a, b and c are statements. The last statement provides the return value. This directly translates to:

    function do_stuff() { a; b; return c; }

Next line defines a variable:

    GetAnswer = fun() -> 42 end,

This just defines a variable which is an anonymous, inline function, sometimes called a closure or a lambda (all three are technically correct). In Erlang, anonymous functions end with "end", not ".". This is equivalent to JavaScript:

    var GetAnswer = function() { return 42; };

The next line is therefore easy to understand, as it uses the same inline function syntax; it calls spawn() with this function as an argument. So it's this:

    spawn(...)

The argument is this function:

    fun() -> io:format("The answer is ~p\n", [GetAnswer()]) end

JavaScript version:

    function() { return io.format(
      "The answer is ~p\n", [GetAnswer()]); }

(Of course, JS doesn't have spawn() or io.format(); this is just syntax.)

Complete version:

    function do_stuff() {
      var GetAnswer = function() { return 42; };     
      spawn(function() {
        io.format("The answer is ~p\n", [GetAnswer()]); });
    }

In some ways, the JavaScript version is actually gnarlier. Look at all those braces and semicolons.

The thing is, the syntax we found nice is usually nice because it's familiar. Many languages could seem like an incomprehensible mess if you're used to C-style brace syntax. But that's purely a question of familiarity. If you don't know what all the bits and pieces mean, you're going to be alienated by it. A developer who has grown up on COBOL and Forth will not find JavaScript syntax familiar any more than you find Erlang syntax familiar.

I suggest stepping out of your comfortable protective shell and trying it out. It's not rocket science. After 30-60 minutes reading this book you'll no longer find it alien, I bet:

http://learnyousomeerlang.com

[brickcap]

Also don't ets tables do that, #3 I mean? Where different processes can access the same data structure? You can even control what process read or write to it. It is pretty neat.

[thirsteh]

Yeah, you could have said the same about Haskell. 'forkIO' in Haskell and 'go' in Go are essentially identical. You could also argue that Haskell's STM is even safer than using CSP channels (which also exist in Haskell) since you greatly decrease your chance of data races (while sacrificing some performance in cases where a transaction is often retried.)

But in the end it doesn't really matter that much. Go and Haskell are completely different languages for different purposes (getting stuff done in regular companies vs. doing interesting PL research or more advanced development in companies with little turnover.)

[coolsunglasses]

>You could also argue that Haskell's STM is even safer than using CSP channels (which also exist in Haskell) since you greatly decrease your chance of data races

We actually have transactional and non-transactional channels as well, which is pretty cool.

Also the reason for using STM instead of channels is that they compose without the possibility of deadlock. You can have deadlocks with channels.

[tel]

I'll try to represent Haskell here.

1. Totally, definitely. The new Haskell IO manager in GHC 7.8 completely blows this out of the water. It's wonderful.

2. You fork or async IO procedures which can be considered immutable values in their own right and passed around without the slightest concern. There is a small difficulty in that Haskell's laziness makes it a small trick to ensure that work gets done in the right place, which is undoubtedly a mark against Haskell, though perhaps not a huge one.

3. Things like STM, MVars, and (now) LVish let this happen in all kinds of ways. The only problem might be picking the right option due to the wealth of choices. Fortunately, the right answer is almost always STM.

I'd be more than happy to translate a task to demonstrate these things.

[asdf1234]

> The new Haskell IO manager in GHC 7.8 completely blows this out of the water.

Go will still outperform Haskell by a huge margin and the typical Go process will have a much smaller memory footprint.

I don't even like Go, but nobody choosing Go is realistically considering Haskell as an alternative.

[samth]

I encourage you to look a the benchmarks published here: http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask03... which includes Haskell beating nginx and Haskell beating SDN controllers written in C++ and in Java.

[tel]

I'm not so sure that is true. I'd love to see some benchmarking, though.

[platz]

I don't like go either, but I won't believe that a ghc webserver is a fast as a go webserver until we can see it in the techempower benchmarks.

[coolsunglasses]

The Techempower benchmarks are using the old version of GHC, 7.6, and the Golang devs have been tuning Go's core libraries to win at this specific benchmark.

[jlouis]

Even then, it is only a factor of 2 slower. That is next to nothing.

[fjh]

> The Techempower benchmarks are using the old version of GHC, 7.6

7.4, last time I checked.

[Mikera]

Clojure has all of this in core.async - which is just a library, it doesn't need special support from the underlying language.

goroutines are certainly nice and CSP is a good mental model for solving many problems, but I don't think a feature like this should be used to justify switching to a whole new language.

[Blackthorn]

What? No. You could not be more wrong. core.async does not support the first point in the least.

Don't believe me? Make a go block in core.async and have it call another function, then have that function block. Do it 10,000 times. I'll wait. And wait. And wait. And wait...get the picture?

Clojure has this in Pulsar, which is a library...that happens to perform bytecode modification to support this (which I consider to be on the same level as special support from the underlying level). Pulsar is an absolutely amazing project and I'm not trying to take anything away from it with this comment, but merely trying to illustrate how far off you are.

[enneff]

This talk (mentioned in the article) captures a lot of the value that I see in Go: https://www.youtube.com/watch?v=dKGmK_Z1Zl0

[grey-area]

What do you think is worthwhile about Go?

Simplicity - the main feature is all the interesting things they left out.

[camgunz]

The difference is I can read Go code while having no experience with it. Erlang and Haskell are inscrutable to 90% of programmers.

If you think this isn't important, I will point out that Rust has been frantically trying to look more like Go and less like garbage in every release. Or, I will also point out that the Elixir project exists, which basically does the same thing for Erlang.

[pcwalton]

Rust is not "frantically trying to look more like Go". There are places where Rust's syntax deliberately differs from that of Go (for example, putting colons between values and types), and that will not change.