vorg

You might need to wait for Flutter to mature. I presume they'll use a custom build tool instead of Gradle, and Dart as their build language instead of Apache Groovy.

You can use Kotlin instead of Apache Groovy as the build language for Gradle, but virtually no-one uses it there.

This would be the banks moving into the cellphone market -- a good way for them to counter phone-based intrusion into their business model by WeChat/Alipay.

If Go 2 is bringing us generics, then couldn't that `builtin` package provide real type signatures for the builtin functions instead of fake ones? Instead of

  func delete(m map[Type]Type1, key Type)

it could have

  func Delete(type Type, Type1 somecontract) (m map[Type]Type1, key Type)

in there, and a program compiled with Go 2 would have an implied instance of

  func delete = builtin.Delete(T, U)

in its global namespace for every map with a `delete` used somewhere in the code.

You can't just use the docs at Apache Groovy's website because Jenkins pipeline uses a crippled version of Groovy -- none of the functional collections-based methods work.

Depending on what it's made of, a break in the cable wouldn't be instantaneous, but happen in stages. Perhaps cut the earth end at the red alert stage up top.

The missing "and" is a tiny grammatical error, whereas the missing "," Someone mentioned is a large grammatical error. Tiny grammatical errors are OK -- language grammars change over time because many people start making the same tiny grammatical error until it becomes part of the accepted grammar of the language.

I agree. The real problem is they're trying to add generics to Go and make Go 2 backwards-compatible with Go 1. Doing both generates the complexity, just like with Java 5. Generics in a language are good, but Go will cross the line from simple to bloated as soon as these generics are added. To remain a simple language with generics, Go 2 would need to give up backwards compatibility with Go 1, something which the suits at Google would veto if any techies there actually tried it.

Bullshit jobs also 4) keep a country's population occupied so they don't self-organize and revolt against the country's entrenched power structures.

> I would much rather have powerful hygienic compile-time macros to generate code

There's still a place for this, even in a Go with the proposed generics.

There's 3 main styles of generics, each with different speed/space trade-offs:

* use interface{}, which runs slower and has no compile-time checking, but can be faster to code

* use the proposed type-safe generics compilation, which generates compact code, but which require more detailed coding

* use the hygienic compile-time macros, which run fast, but can generate lots of bloat when compiling

There's a place for all three being available. So perhaps Go 2 will get macros one day !

> English has an astonishing ability to replace vowels with schwas

That only works with the unstressed vowels [1], so we have "phətogrəphy" because "to" is a full stress and "phy" is a half stress.

[1] Except in NZ English, where the ɪ-sound ("i" as in "if") and schwa (ə) are pronounced the same.

> Use JavaScript as "glue for Java" like it was originally intended.

Then we would have come full circle. JavaScript was originally intended as glue for Java applets, but applets never became popular. Instead, Java was used for standalone and server-side codebases, and Beanshell came along as glue code for those. Later, James Strachan added closures to Beanshell's basic functionality, and Apache Groovy was born. Afterwards, Scala became popular and showed that a statically-compiled language could be used dynamically as well, and Strachan said if he'd known about Scala at the time, he'd never have created Groovy. Later, Kotlin showed you could even have builders in statically-compiled code. Now Graal is finally enabling Javascript on the JVM, perhaps selling the idea to developers better than Rhino or Nashorn did.

If you need to use the JVM ...

> walk and modify the AST at compile time

Clojure is best for this. A macro only a few lines long in Clojure will do the same as what a few hundred lines in Apache Groovy are required for. It's possible to walk the AST in Groovy but it's verbose and messy.

> CompileStatic that go a long way

Both Kotlin and Scala are both statically typed from the ground up, instead of having a @CompileStatic annotation tacked on later.

> the brevity and expressiveness of Groovy

Groovy started off in 2003 as a functionally similar clone of Beanshell, which had already existed since 1999, but with closures added. Someone then translated all the standard functional methods from Ruby into Groovy's codebase. Of course, Jython, a JVM version of Python, has been around since 1997. So Groovy is a relative late comer to the JVM in this regard.

Groovy tried to be a bit of everything for everyone on the JVM, but has ended up being used only for 20-line build scripts in Gradle.

> there are only 50 states

Many people refer to Australia as "the 52nd state".

The unintuitive part is the choice of operator `<<` instead of `>>`. in your example `f << g` means do `g` first (i.e. 2 + 4 = 6) then do `f` on the result (i.e. 6 * 3 = 18). I would have expected `f >> g` for this behavior.

The dividing line between what's a language and what's the IDE is fairly arbitrary. E.g. a language could conceivably come with a tool chain that includes CLI-driven refactoring, and an "IDE" would only need to be a graphical interface calling it.

None of those Apache Groovy examples you gave work when scripting Jenkins pipelines, because the all the functional methods (e.g. each, collect, findAll) are crippled so they don't work. Groovy is more like Bash for Java, rather than Perl.

> "where's Gerald? this module only builds on his laptop"

Of course, "Gerald" is an anagram for "Gradle".

Look beyond arbitrary administrative divisions at what actually exists on the ground. Of course, many cities are spirals rather than circles so it can be difficult decide where to draw the line. Oakland and Silicon Valley, and even San Jose are also part of "Greater San Francisco", which is a very spread out city because of the geographical imposition of the bay.

Proxy purchases would be common via the informal financing system in places like Wenzhou. It's hard to imagine how the NZ government could possibly enforce such proxy purchases, especially since Australians and Singaporeans are exempt from the foreign buyer restrictions. Australia, New Zealand, and Singapore all have high immigration from China, and such immigrants can easily act as the proxies of anyone with an informal business relationship with a lender in Zhejiang.

> Easy way of mocking components is a huge advantage

Any language that enables dependency injection (e.g. all OOPL's) would help with this.

> YC has been very successful in the world by believing that hackers – not businesspeople – can build the biggest companies.

Virtually every non-technologist businessperson who becomes a manager in the IT industry will present themselves as a technologist. They will usually have some real technical people at their beck and call to help with the stuff they can't fake.

> Unicode characters are limited to the range U+0000..U+10FFFF, so they fit in 21 bits and require no more than four bytes (in the UTF-8 encoding form) or two 16-bit code units (in UTF-16)

The private use planes U+F8000..U+FFFFF and U+100000..U+10FFFF can be used as the high and low surrogate ranges in a surrogate-pair encoding scheme similar to that of UTF-16. That would give a range of U+00000000..U+7FFFFFFF, which is in 2^31 space. If the Unicode Consortium removed their arbitrary upper limit of U+10FFFF for codepoints, the UTF-8 and UTF-32 schemes as presently defined would naturally fit into this space without needing to use any surrogation. Only UTF-16 would require any surrogation -- its present scheme and those private use planes for a 2nd tier -- but hopefully the use of UTF-16 would be well on its way out by then.

"all" and "no" are easily extended from boolean logic to unspecified numbers of items for everyday speech, without resorting to unification:

  all not == not A and not B == not (A or B)

  not all == not (A and B) == not A or not B

Seems to work in other natural languages besides English, e.g. 都不 vs 不都 have same variation in meaning as in English where 都="all" and 不="not".

> “Would you like the red shirt or the blue shirt?”

You're writing it wrong -- it should have a comma in there to denote the pause: “Would you like the red shirt, or the blue shirt?”

Are you also speaking it wrong? The part before the pause should be spoken with tone going up, and the part after with tone going down. If you're not pausing and changing tone, then the correct answer is either "yes" or "no", or repeating the whole thing back to mean "yes".

I'm in Wuhan. I don't use Ofo but I keep an eye out and have only noticed a single Ofo bike in a hundred over the last few months with an auto-unlock.

Obviously, the bikeshare companies roll out their newest stock in Beijing and Shanghai. I'd guess most Ofo bikes in all of China still use the manual unlock, and will do so for a while yet.

... and Android Studio could be the only thing keeping Gradle alive, beyond 20-liner build scripts. When Google finally releases Fuchsia, it will virtually replace Android's market share within 2-3 yrs. Because Flutter uses Dart for building apps, it'll probably go with Dart for specifying build scripts as well. Although one of the Apache Groovy PMC is probably busy politicking inside Google to get them to use Gradle for Flutter, hopefully that team won't repeat Android's mistake. Otherwise the 3rd-party app market for Fuchsia will be stillborn.

Mobike is a lot more user-friendly because the bike unlocks itself when you scan the code or trigger the bluetooth signal, whereas the Ofo app sends you a numeric code which you must punch yourself to unlock the bike. Ofo is like the half-generation of bikeshare between 1st-gen docked bikes and 2nd-gen dockless auto-unlocking ones.

> You just can't break backwards compatibility. This was a big mistake Python 3 made.

At least Python's backers had the guts to release a breaking version 3, unlike some other dynamic languages, specifically Ruby and Apache Groovy. Ruby's backers have tentatively slated 2020 for a (MRI) Ruby 3 release after two more Ruby 2.x versions. As for Groovy, 2 months ago its backers canceled its version 2.6 release which was to backport the planned features of Groovy 3 into a JDK 7 compatible release. Looks like we won't be seeing version 3 of either language anytime soon.

Different countries and cities have different practices concerning what you get. Across the border in mainland China, the toilets will often be cordoned off for months at a time, and they skimp on providing decent air-con. In Tokyo, they throw everyone out from 2am to 5am for "cleaning".