The patches to the Kernel are in review and can be seen here: https://patchwork.kernel.org/project/linux-input/patch/20201...

Good to see they are still using GOTO. Straight-forward and performant.

I spent to some time to check and analyze the code.

The author uses it in a clear pattern, specifically, as a sibiling post mentions, in order to achieve error handling (additionally, with fall-through); the labels are indeed neatly placed at the end of the function, after the `ret` exit.

The problem is consistency - the upper half of that function performs error handling without goto, and the lower half with it.

I personally prefer all-or-none solutions, since I highly value consistency, but on the other hand, I do consider this solution acceptable, since it still has a tidy (enough) structure.

Goto doesn't have a performance benefit over other control flow structures with a modern compiler.

In C GOTO is often by far the cleanest solution for error handling.

Everything else turns into an ugly, unreadable mess in functions that need to free resources or do some kind of cleanup.

I've seen the goto error-handling approach used now in SDKs written by developers from companies like Microsoft, Nvidia, and Nordic Semiconductor. It really does seem to be the best way to do it. And it's simple. Mess something up... goto cleanup... Seems fine to me!

My comment has nothing to do with error handling. I was addressing a false claim about performance.

Yes, but it does reduce the level of indentation required in most functions that use it. That consideration is part of the kernel style guidelines.

In system C code its usually used for error and retry logic to make the code more readable. It's rarely ever used for performance.

that's definitely not categorically true

Can you think of a counterexample? I wouldn't be surprised if you could trick a compiler with a goto but optimizing control flow is very much the type of optimization that Knuth was referring to. Now that almost all compilers use SSA I'd be surprised if it was the case outside of fairly deep control flow

The question was about performance, not necessarily other aspects.

If you’re criticizing goto in kernel source, you don’t know what you’re talking about. It’s incredible how many people just regurgitate this anti-goto meme without any experience writing system C code. There are various highly structured uses of goto used for systems programming in C, most prominently for error handling but also for things like retry logic.

You built a strawman and burnt it down!

Yes, you're right.

Congrats on launching!

Are you able to share further technical details on what you've had to do to get the speed gains you're describing?

The specifics of the speed gains are our secret sauce, I’m afraid! But at a high level, we reduced the time taken in every step of the pipeline between capture > encode > send > receive > decode > render that we could, while still remaining WebRTC compliant.

For other mitigations to climate change, see Project Drawdown: https://www.drawdown.org/

It doesn't look like olivine is mentioned in that. Is it under some other name / concept?

This process is typically referred to in the scientific literature as "enhanced" weathering but we think that "accelerated" weathering is easier for lay people to understand.

Drawdown is mostly focused on things we can change in our current activity to lower emissions and less about methods for Carbon Dioxide Removal (CDR). Their top solution for becoming carbon neutral is "Refrigerant Management"...

I like the concept of the project and know some people working in the org, but in my opinion, they do not give enhanced/accelerated weathering enough credit as a potential solution, even though it can scale all the way up to global CO2 level emission removal. Many of the other solutions they suggest are limited in potential, yet featured prominently... I am working to communicate this to them.

https://www.drawdown.org/solutions/coming-attractions/enhanc...

https://www.drawdown.org/solutions-summary-by-rank

It's called Enhanced Weathering of Minerals.

They mention olivine in its description page:

https://www.drawdown.org/solutions/coming-attractions/enhanc...

They don't try to quantify the potential, though.

As a client I've been happily using https://www.irccloud.com/ for the last few years. Does what I need: decent mobile and web client.

I've played with Teller and it's nothing short of incredible. The developer on boarding is super slick.

There's also webbit-rest: https://github.com/webbit/webbit-rest

Here's the previous submission: http://news.ycombinator.com/item?id=2446316

There are a number of people I know who have never touched Java and are being exposed to the eco-system through languages like Clojure and Scala and this kind of overview may be useful to them.

However, I agree that it's not worthy to be on the front-page of HN.

These are not Java-specific data structures. If you already know these concepts -- and I don't see how you could write code without inevitably bumping into them -- the Java implementations should be intuitive and trivial to learn. Not to mention clearly documented.

The only reason I feel this is out of place here is because the very first thing the author says is "if you google[...]" which I would hope most hackers do before they start asking questions of others.

As of Java 1.5, generics were added. Before generics you had to cast every object you read from a collection. If someone accidentally inserted an object of the wrong type — possible in the OP's example code — casts could fail at runtime.

With generics, you tell the compiler what types of objects are permitted in each collection. The compiler inserts casts for you automatically and tells you at compile time if you try to insert an object of the wrong type. This results in programs that are both safer and clearer. So please use generics when using the collections framework.

I'm now going to briefly run through the examples provided in OP's post and update them accordingly.

  List<String> myList = new ArrayList<String>();
  myList.add("Second Thing");
  myList.add("Second Thing");
  myList.add("First Thing");

Note that I've used the interface form of List over a specialised type. This is so that any caller of a method which returns a collection can use the interface provided and they don't need to worry about the specific data structures you've used. This also means that you can update the underlying data structure without having to update any calling code. E.g. changing the above case from ArrayList to LinkedList.

  Set<String> mySet = new HashSet<String>();
  mySet.add("Second Thing");
  mySet.add("Second Thing");
  mySet.add("First Thing");

It is worth noting that Hashtable was not originally part of the Collections framework. It was retrofitted to conform to the Map interface in 1.2. You should instead use HashMap, which is the non-synchronized (sic) version of Hashtable. Although you can just as easily use Hashtable, the below example is just me being a little OCD.

  Map<String, String> myMap = new HashMap<String, String>();
  myMap.put("a", "Second Thing");
  myMap.put("b", "Second Thing");
  myMap.put("c", "First Thing");

EDIT: Updated some sections to read clearer.

> It is worth noting that Hashtable was not originally part of the Collections framework.

An other class in that case being Vector, and that's the reason why they have a lot of duplication in their methods: they have the original ones, and they have the new ones coming from the Collections framework interface (this is also the source of having both Iterator[0] and Enumerable[1] in the JDK: Iterator is the Collections framework iterator interface, Enumerable is the pre-Collections one)

An other big difference, which you hinted at, is that Hashtable and Vector are both synchronized collections (method calls will take the collection lock and behave "atomically"), whereas Collections framework classes are not, instead the Collections framework has compositional wrappers[2] which provide this behavior independently of the underlying collection implementation.

finally, a little trick for more fluent Collections initialization: you can abuse anonymous subclasses and instance initializers to get something much less imperative:

    List<String> myList = new ArrayList<String>() {{
        add("Second Thing");
        add("Second Thing");
        add("First Thing");
    }};

[0] http://docs.oracle.com/javase/6/docs/api/java/util/Iterator....

[1] http://docs.oracle.com/javase/6/docs/api/java/util/Enumerati...

[2] http://docs.oracle.com/javase/6/docs/api/java/util/Collectio...

For those looking for something more like Sinatra in Java, check out webbit: https://github.com/joewalnes/webbit

Here's an example of a simple Websocket chat server: https://gist.github.com/1421652

Disclaimer: It's an open source project that I have some commits to

Webbit looks much more like embedded Jetty and plain servlets than Sinatra. If you really want something like Sinatra in you Java project, wire in Scala and try Scalatra.

>Disclaimer: It's an open source project that I have some commits to

Is that like a 'full disclosure' notice or are we supposed to be terrified of your code?