h8liu

Because only US can buy cheap goods and services from the world with printed paper called dollars.

and the spaceship tech owner can just use that money to build and implement clean energy solutions to revert climate change, and never really need to build the actual spaceships..

This is like asking if one would pay more taxes, where it is unclear how the tax will be used to improve common good.

I bet if you ask people if they are willing to pay $1000 dollars (financed as $40/m in 25 months) to secure a spaceship ticket to escape the failing earth climate (assuming the spaceship already exists), many people will happily pay it.

What the author calls "objects" (or "classes") is really often just "interfaces".

An Object is a set of functions that operate upon implied data elements

If this is replaced with:

An Interface is a set of functions, often operate upon implied some implied data elements (but not necessary).

Everything in the article will probably be less confusing.

his point is in the reverse for US..

In China, the companies are the puppies; in US, the government is the puppy. This is probably a very fundamental difference.

that is a classic textbook dynamic programming (or suffix tree, depends on the size of the set) problem. behind the puzzle, it is the thought about dividing one bigger problem into smaller ones, and hence solve them with code efficiently. maybe that does not sound too far from your day-to-day coding.

the site probably should have presented these puzzles from a different perspective, so that it is easier for people to recognize the message about what kind of programmer skills and mindset it is looking for.

True, and it is also a major issue for many Chinese companies..

And rather than going to the court for justice, the US place tariffs for a war..

Like which IP policy? Any specific policy document that you can point out?

China has been having IP laws and protection since around 1980, and China government never said once that stealing IP is okay. It is IP law execution and enforcement in China that is sub-par. Policing is sometimes hard.

Also, I believe the US really wants to treat IP as an "asset" rather than a "product".

hmm.. I was not aware that Russ used the word "showstopper" until recently in his tweets, and even if he literally used the word in the past, the word of the meaning was not delivered, reading from the post here.

That said, the dep people also made a similar mistake on not clearly confirming with Go core team that they had a chance to integrate dep into the official toolchain eventually. They wanted dep to be the thing, and they really thought that they were on the right track.. poor folks..

If Russ managed to influence the "problematic" group to do what he wants, rather than doing it by himself, he could give these people a meaningful place in the Go community. That is the gain. If that is worthy or not (comparing with discarding 2-month work on Russ's own time) depends on your own perspectives, and I am not sure what Russ thought or thinks. No matter how, it will affect how the community grows in the future.

So this goes back to the root issue about how the Go core team view its Google-external language community (or even more fundamentally, if they will be rewarded/recognized by Google if they did a good job on making the community happy). Specifically, do they want to carry the responsibility to deliver messages to the community clearly, at least to some certain extent? Opinionated is fine and firing users (e.g. users who think generics is a must) is fine, sometimes even preferred, but hurting people that were willing to follow and contribute might not be the best way to go.

I think the issue is that Russ should have clearly told the dep people that if the showstopper issues are not handled, then he will seek for some other solution, e.g. build one by himself.

However, what happened was that he told the dep people "I will build a dep tool myself to understand more on the problem details", which implies "after I understand more, I will come back to you and discuss more", but not "after I build the tool myself, I will just integrate my version into the official tool". For this part, Russ was not executing his own words, or at least delivered the wrong impressions. Maybe this result should be already well expected based on Russ's personality or how the golang team did stuff in the past, but many programmers are not that politically awareing..

It is not the technical result that the "vgo" solution kills "dep" saddens dep people. It is rather the form of communication: "vgo" stabs "dep" in the back, by emerging suddenly out of Russ's pocket, and essentially claims immediate victory using the power of the Go core team. When the vgo posts are out, and the vgo proposal is posted (and it is not really bad technically), there is really no effective way for the rest of the community to reject it.

Russ could have kept his words by going back to the dep people and told them about what he learned from writing "vgo", and then move forward with integrating "vgo" if a consensus cannot be reached. Eventually, Russ might just be able to get the same technical results as today anyways (but maybe with larger communication overhead).

What the dep people essentially says here is that, if Russ really wants, they can also implement exactly "vgo" from "dep", but they never got the chance.

Package list with dependency graph @smallrepo.com

https://smallrepo.com/repos/github.com/google/go-cloud

fwiw, I maintain a website called smallrepo (https://smallrepo.com). It builds go language code together, and maintains an always buildable commit set as a "super repo". If you sync to smallrepo (rather than using go get), it can shield you from many unexpected build breakages.

[1] says it is from Global Times (which is like a sidekick of People's Daily)

People's Daily [2]. Not sure if it has an English translation.

[2] https://mp.weixin.qq.com/s/DvQGVmHrgn_yfVCg-2xYAA

related discussion:

https://www.quora.com/What-is-your-opinion-on-the-recent-Chi...

e2e argument:

http://web.mit.edu/Saltzer/www/publications/rfc/csr-rfc-185....

Unix:

https://people.eecs.berkeley.edu/~brewer/cs262/unix.pdf

or pretty much everything here: http://cseweb.ucsd.edu/classes/fa17/cse221-a/readings.html

CS can be pretty broad.

You are justifying your fear of a rising power, as if you are threatened, and you have all your rights to fear. However, the truth is that the West is still arguably more powerful, where the Chinese people are the ones that have been living in this exact kind of fear that you stated for a very very long time. If your reasoning holds as a universal value for all human beings (but not just for you), then it is effectively justifying a historically less powered entity, China, now eventually becoming free from this threat, where the world becomes more equal and multi-tenant in power, and you should happily embrace it.

Maybe what you fear is not that you are threatened, but that your current way of threatening other people in the world is no more. What you fear is change.

And yes, you are stating the facts: one of the ugly parts of human nature.

Interesting...

Chinese people also feel threatened by the West, because they don't trust you. There's not much more to it. They fear that you might abuse your power or use it to destabilize China. There's a lot of hatred of China, and they don't want you to try and trample Chinese norms, culture, society... things which they care about and are deeply connected to.

That's not to say the West actually would do any of those things, the key point is the lack of trust, specifically trust that you would do anything to benefit Chinese people or protect Chinese or that you care about them at all. They don't trust you, and the specifics of what you could do to hurt them are not really something they consider (but as you, the West is already powerful, you have many more options... to the point where one day maybe be the Chinese are dwarfed again by the West, and have no ability to defend themselves should they have to.) The west is very scary to Chinese people.

See how this goes?

an army of "toddler" developers can overthrow a single hero in terms of productivity, and using a "toddler" programming language makes sure that newly joined "toddlers" can understand (and also maintain or upgrade) existing code, so that the army can just keep growing.

apple did not create llvm. llvm started as an academic project, and apple took advantage from its ecosystem -- same as many other companies did.

Created https://github.com/shanhuio/smlvm

A C like language with golang like syntax. Pure Go language implementation.

https://shanhu.io/smlvm - shows the dependency structure of the project.

https://github.com/shanhuio/smlhome - example code that we wrote in the language.

The layout engine is in this package:

https://godoc.org/e8vm.io/e8vm/dagvis

it is possible to layout any DAG (directed graph with no circles).

The dependency graph of golang programs are generated by this package:

https://godoc.org/e8vm.io/tools/godep

I have not very well packaged the drawing part (sorry), but the essentials are here:

https://github.com/e8vm/shanhu/blob/master/web/js/dag.js

it is using d3.

My hobby project, with dependency graph visualized:

https://e8vm.io/e8vm

Source code:

https://github.com/e8vm/e8vm

No dependency is often not the right dependency. For example, http depends on tcp, because an http stack cannot work or be reasonably tested without a working tcp stack. Yes, the tcp stack can be provided as an injection. Yes, the tcp stack can be defined as an interface and faked or mocked with a minimal implementation that barely supports the required execution, but still, without providing the depended tcp module, the http module does not work "independently". Sure that the http stack semantically only depends on the tcp "interface" to "compile" (if that was a thing in javascript), but as an http module that ideally should just work out of the box, it should always be shipped with a default tcp "implementation" that just works fine, rather than having the user of the module to "register" a tcp module.

Using centralized message passing/routing/registering is just being lazy on handling dependency, it is like abandoning structure programming and starts using "goto" for every branch, which makes the logic flow eventually untraceable. For a system of N modules, it ideally should have around O(N) dependency edges, but a centralized hub is essentially modeling a possibly O(N^2). It only makes sense to introduce a hub when everyone potentially wants to talk to everyone.

And worst of all, every module using the framework now depends on the "hub" now. While the actual logic-related dependencies are all converted to "dynamically" instantiated ones, this "static" dependency on the hub becomes extremely hard to remove in the long term. It's like a cancer. It is not a good "pattern".

interesting work. if I am understanding correctly, you are essentially using the randomness generated by the scheduler to produce art pieces. do you have a public link to your work?

and for the DCPU fans, e8vm also has its own small mips-like instruction set, which is currently the only target "platform" that my compiler supports.

(some shameless self advertising)

I built e8vm.io (https://github.com/e8vm/e8vm, https://e8vm.io), which is all written in go, and it has a full-blown compiler, with no optimizations though. The language has go-like syntax and C-like run time.

shanhu.io (https://shanhu.io) provides an online playground for the language, which runs the compiler right inside the browser, thanks to gopherjs.

shanhu.io is a programming playground powered by e8vm:

https://github.com/e8vm/e8vm

e8vm is an open-source self-contained simulated virtual machine that has its own simple mips-like instruction set, and its own system programming language (G language). G is a language that has a golang-like syntax but with a c-like runtime -- no runtime.

shanhu.io provides an online playground where you can develop G language programs and run it in a simulated e8vm virtual machine right in your browser. The website requires a github account to login to save the workspaces.

The entire project is written in Go language, with no circular dependencies among files and packages, with each file no more than 300 lines (maximum 80 chars each). As a result, the project can be visualized in a hierarchy of DAG's:

https://e8vm.io/e8vm

The G language compiler enforces the same dependency rules, so a small operating system in G (still in development) can also be visualized:

https://shanhu.io/~os8

It is a hobby project of mine. Questions and feedbacks are welcomed. :)

Thanks.

Here are my hand-made tools to generate those stuff: https://github.com/h8liu/e8tools

Javascript version (I actually wrote this first for go std lib): https://github.com/h8liu/dagvis

For golang std lib, since packages have no circular deps, it can be automatically drawn out like this:

http://lonnie.io/gostd/dagvis/

If you write your project that even has no circular deps among files and all files are small (like me in https://github.com/h8liu/e8vm), you can draw the similar graph but at a much finer granularity, like this:

http://8k.lonnie.io/

If the project does not have circular dependency, it can be automatically drawn from the code like this:

http://lonnie.io/gostd/dagvis/

or this:

http://8k.lonnie.io/