RBS, Ruby's new type signature language - <AUTHOR> https://developer.squareup.com/blog/the-state-of-ruby-3-typing <comment><USER3> Didn't realize Square was interested in Ruby type checking, just like their competitors over at Stripe. Lots of money riding on Ruby, I guess :)

It does seem useful to have a _standard_ for type definitions - RBS as the equivalent to a .d.ts file - as that allows for different type checking implementations to use the same system under the hood. This was a big problem for Flow, and why it lost the fight as soon as TypeScript's definitely-typed repository started gaining momentum - users wanted to use the type-checker that they knew had definitions for the libraries they used.

On the other hand, RBS as hand-written seems rather dangerous, to me. Nothing wrong with using them to define previously-untyped external code, as long as you know the caveats, but I think you really want to have definitions generated from your code. Sorbet cleverly (and unsurprisingly, given it's Ruby) used a DSL for definitions in code, which had the (excellent) additional boost of runtime checking, so you actually could know whether your types were accurate - by far the biggest pain-point of erased-type systems like TypeScript.

Given that Ruby 3 was supposed to "support type checking," I'm surprised that it does not seem to have syntax for type definitions in code, and instead will focus on external type checking. I might be missing a piece of the full puzzle not covered in the blog post, however.

<comment><USER4> > I'm surprised that it does not seem to have syntax for type definitions in > code

This is a big disappointment to me, one of the main advantages of static typing is that it can make code much easier to understand when types are added to non-obvious method parameters.

<comment><USER5> Surely a good IDE such as RubyMine would be able to display the type in reponse to, say, a mouseover?

<comment><USER6> RubyMine tries but it certainly works less well than PyCharm and GoLand.

<comment><USER7> RubyMine works great if you add yard type docs to your code.

<comment><USER8> Is it checking those types or just reporting then?

I've seen so many instances where yard doc has the wrong return type or misses a return type that I rarely trust it.

<comment><USER7> It doesn't do typechecks, no. You can use solargraph ([https://github.com/castwide/solargraph](https://github.com/castwide/solargraph)) for that.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> I'm really puzzled by the decision to use a separate file for this. The stated justification ("it doesn't require changing Ruby code") doesn't make sense, and my personal experience with languages with external type specifications is strongly negative. It's an unbelievable pain to keep multiple interface files in sync over time.

`.h` files are not something to emulate! External interfaces should be generated by tools where needed.

<comment><USER10> FWIW, you can use inline syntax with Sorbet[0], one of the two typecheckers that will work with the RBS format (the other being Steep, which does not have inline syntax).

Here's a full example, complete with a typo, based on the example in the blog post: [https://bit.ly/3hMEMSp](https://bit.ly/3hMEMSp)

Here's a truncated excerpt to get the basic idea across:

        # typed: true

        class Merchant
          extend T::Sig

          sig {returns(String)}
          attr_reader :name

          sig {returns(T::Array[Employee])}
          attr_reader :employees

          sig {params(token: String, name: String).void}
          def initialize(token, name)
            @token = token
            @name = name
          end

        end

Disclaimer, I used Sorbet while I was an employee at Stripe. I found it to be a terrific typechecker. It's also just absurdly fast (most of the time).

[0] [https://sorbet.org](https://sorbet.org)

<comment><USER11> This syntax is horrible. I'm surprised they didn't just copy Python's typing syntax.

<comment><USER12> I believe one of their guiding principles was that they wanted all the syntax to be valid Ruby, because they did not want it to become a separate Ruby interpreter. So they were pretty limited in the syntax available to them.

<comment><USER11> I'm not sure a separate interpreter is necessary but a preprocessor could remove the notations perhaps.

<comment><USER12> I believe they don't want to just strip out the annotations because Sorbet also does run time type checking. So to get all the features they wanted, they had to either write a new interpreter or use valid Ruby.

<comment><USER11> OK, take non-ugly syntax, translate to ugly syntax.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> It's worth noting that while the article is coming from Square, this is an official Ruby project and is "Ruby 3's new language for type signatures".

[https://github.com/ruby/rbs](https://github.com/ruby/rbs)

<comment><USER10> Yeah, I was wondering why this was being announced on Square's website. Seems it's because Square happens to employ Soutaro Matsumoto, who wrote the post and is also the creator of Steep[0] (an implementation of a typechecker for RBS files).

It's not clear to me whether Soutaro is a member of the Ruby core team, so it feels a bit odd that the post is written like an announcement from the Ruby maintainers.

[0] [https://github.com/soutaro/steep](https://github.com/soutaro/steep)

<comment><USER14> Soutaro is indeed a code member of the Ruby team, he also happens to work at Square. Soutaro is also one of the main contributors to RBS and helped define that standard.

He was going to keynote on this at RubyKaigi this year until it was cancelled, and had a talk at RubyConf as well on this.

<comment><USER10> Thanks for clarifying! It's great that Square is funding work like this.

<comment><USER14> Yep, and glad to see the work Stripe is doing on things as well. Always enjoy seeing where you all are going.

Soutaro has been great to work with over here (Square), and he has a ton of really amazing things coming soon that we're working on OSS'ing later.

<comment><USER10> > you all

Just to clarify, I left Stripe several months ago (and did not work on ruby infra), so we both get to cheer from the sidelines!

</comment></comment></comment></comment></comment></comment><comment><USER15> Can someone explain why the types cannot live in Ruby code itself (after an appropriate version bump)?

Python 3 incorporated types into the language itself, in a similar way (though non-reified) to PHP. This seems much easier to deal with than requiring two files (.rb and .rbs) to describe a single data structure.

<comment><USER16> Based on the relative smoothness of Ruby version transitions versus Python, I trust Matz's preference on this implicitly. One good thing about it being external is that you can optionally and experimentally annotate existing code without munging up your source files. At least so long as this is a bleeding edge feature, that separation makes a lot of sense to me. It'll be a while before anyone can be confident in a particular model for how this should work, until it's been in use for a good long while.

<comment><USER14> Pretty much. Matz is very sensitive to breaking the language in any way with the Ruby 3 upgrade, which brought up the true keyword argument hard-break and [likely got that pushed back]([https://discuss.rubyonrails.org/t/new-2-7-3-0-keyword- argume...](https://discuss.rubyonrails.org/t/new-2-7-3-0-keyword-argument- pain-point/74980)).

RBS and type files on the side were really hotly debated for a while and the core team settled on this as a way to not break the existing parser among other reasons.

While I don't 100% agree with them I have faith that Matz and the team make the decisions they do based on impact and what they see in the community.

<comment><USER17> His view is probably informed by the Python 2->3 experience.

<comment><USER18> Ruby 1.8 to 1.9 was very painful, I am not sure why it was more succesful than Python 2->3, I'm not sure it "deserved" to be or was any less painful on it's face. It easily _could_ have been just as disastrous. So also informed by that; ruby hasn't done anything nearly as painful since.

But that applies to making it so old code does not work in the new version of the language. Nobody expects all _new_ code to work in the _old_ version of the language. Ruby adds new features including syntax that won't properly parse in _old_ interpreters all the time. It's not clear to me why inline type definitions couldn't be such.

<comment><USER19> > I am not sure why it was more succesful than Python 2->3

Probably because Ruby had a much narrower area where it was heavily used, with fewer "finished" but critical libraries.

<comment><USER20> Matz often cited the "carrot" of much better performance on 1.9 as a reason for the successful transition.

Python3 didn't offer much over python2, so people just saw the downsides, while ruby pushed people to upgrade with the promise that their efforts would gain them better performance and/or save money.

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> I'm not thrilled about the separate files with the type information but I completely understand why they did it, and if it were my choice I might make the same one.

I don't like the comparison with TypeScript `.d.ts` files however, because TS still lets you do types inline in the code. I haven't seen it mentioned anywhere that this _won 't_ be supported by Ruby 3.

Does anybody know if Ruby 3 will also support inline type information or will the header RBS files be required?

<comment> amw-zero I much prefer separate files for type declarations. Or at least the ability to define them separately. Type annotation takes away from readability. I like keeping the types and code separate.

<comment><USER22> The upside of external files is pure incremental implementation that touches no other tooling and requires no buy-in.

I don't see how having to switch files to know that `input` is a `User` increases readability, though. It seems like straight-forward impl-simplicity trade-off, not one of user ergonomics.

<comment><USER23> That can be covered by the editor to give the user some hint by referencing the external file but for the user, having have to keep adding it on a separate file seems pretty annoying as you need to keep declarations synched in 2 files.

Also how do you type something in an inline function?

</comment></comment></comment></comment><comment><USER24> Cool. And glad to see this called out:

 _Better IDE integration: Parsing RBS files gives IDEs better understanding of the Ruby code. Method name completions run faster. On-the-fly error reporting detects more problems. Refactoring can be more reliable!_

IDE support (autocomplete, refactoring and quick documentation) is the most important reason to annotate argument and return types.

<comment><USER25> I've been using typescript for a few years now and to be honest I almost never rely on the compilation errors. I just use the built in Jetbrains IDE completion, autosuggestion, and navigation to make it work.

<comment><USER24> Yep. A good IDE to a first approximation doesn't allow compilation errors to occur because you are auto-completing everything, including symbol completion based on the type at cursor, etc.

Jetbrains is a wonderful company.

<comment><USER26> Since the advent of LSP, I think the value proposition of a full featured IDE has been greatly diminished.

For example, I used to use Intellij for Scala but recently switched to Emacs+Metals and haven't really missed anything. In fact, it's probably an even better editing experience.

Intellij still has better refactoring (though I don't use it much), and the integrated debugger and database viewer are really nice. I've found myself using Emacs and only switching to Intellij for the aforementioned specialized tasks.

5 years ago you would have been crazy not using an IDE for JVM work but this is no longer the case. LSP is such a wonderful technology and has empowered the creation of new programming languages like never before. It's truly remarkable.

If I was Intellij, I would be a little worried about my future market share. They simply can't provide the same value as before, and I'm not sure how they intend to change that.

<comment><USER27> I wish I had had your luck with language servers. They are fantastic when they work but in my experience configuring them is finicky and difficult, particularly with Emacs. I have also run into problems where the server crashes and does not restart itself, so the IDE functionality in my editor will just silently break and I have to go fix it. JetBrains still dominates the market for IDEs that work out of the box, and I still don't know of any LSPs that can even remotely compete with the sophistication of their static analysis tools and such.

</comment></comment></comment></comment></comment><comment><USER28> I haven't used Ruby in ages but this seems like a really odd way to incorporate type hints in the language.

I much prefer the Python 3+ approach of type annotations in source code.

I can't imagine having to look at a separate file just to figure out what the type of something is. You may say "tooling will fix this" but it's just far less overhead for everyone at the end of the day to just make annotations in source.

My more existential question is, is there really an advantage to doing static type checking in Ruby?

When I was doing Ruby, the way you can change objects on the fly, add methods on the fly, the vast amounts of metaprogramming, are types at "compile" (I know, not really) time really the same as types at runtime?

Like, it might be nice to get some autocomplete, but AFAIK tools already do that (RubyMine, others).

<comment><USER29> This is why I do not like mypy or types in Python other than dataclasses. If I'm going to type the damn thing I better be getting performance ala cython. Why on earth use a dynamic language like Ruby or Python and then try to bolt types on top. Ruby would do far better to fix the bloody `and` vs `&&` issue (it should just be `and` and it should work like `&&`) and strings should be immutable by default with a special syntax or method to make them immutable.

But you're absolutely right about the downsides of stuffing types into a different file. I get why Matz did it (he wants to keep Ruby beautiful and types are crufty) but I don't like them in the first place.

<comment><USER30> > Why on earth use a dynamic language like Ruby or Python and then try to bolt > types on top.

To answer this (as someone who basically only ever writes in Python):

There are a few cases where it's really nice to be able to add type annotations to methods or functions. The most obvious example is API calls; it's nice to be able to say "this needs to be a list, give me a list", and not have to do

if not isinstance(var, list): var = list(var)

or

if not isinstance(var, list): raise ValueError("I know I didn't tell you I needed specifically a list, but I need specifically a list in this case")

Over and over and over again all over your module. Look, give me a list, I need a list. I need the APIs that list has, I need the interface it uses. I don't want a generator that I'm going to be iterating over forever, I don't want a string that's going to get split into individual characters.

Duck typing is all well and good, but just because strings, lists, sets, and os.walk are iterable doesn't mean I'm able or willing to handle those.

It can also help a lot in IDEs; for example, if I type-annotate a method to accept "name" as a Str, then my editor can assume that "name" is a string, even without any other evidence to that being the case. Likewise for things like warning about return types.

Lastly, it lets you do automated testing as well. Hey, you're passing a FooNode to this function, but that function accepts a list. I know this because NodeCollection.find() returns a FooNode. Makes it easy for the dev to look at the report and think "Oh, I meant to use NodeCollection.findall(), oops!"

I certainly don't want a statically typed language, but there are a lot of cases where my internal logic is fixed and I don't _want_ my method to have to know how to deal with int, str, none, bytes, etc. Type annotations can solve this problem for me and for other people using my code.

<comment><USER31> I just worry it's going to be abused, though. E.g. I've worked with more than one Ruby code base where someone did a kind_of? check and threw exceptions if it didn't get what it wanted even though the actual type required was anything that implemented a given method in a reasonable way for no good reason.

I hope people keep the type annotations sparse, and allow the tools to infer it unless they're prepared to link long and hard about the minimal restrictions that are reasonable.

<comment><USER30> I think your own example proves that your concern is moot. If people are going to do stupid stuff, they're going to do it with whatever tools are available to them. Your kind_of misbehavior already happens _without_ type annotations, but now it can be clear to you beforehand what's going to happen.

<comment><USER31> I hope you're right. I just fear that making it external to the code will make it easier for people to ship overly restrictive type signatures without thinking. Though hopefully the tools like sorbet will make it easy to override, in which case it might well improve things (if I "only" need to override the type signatures instead of having to monkey patch or fork code)

</comment></comment></comment></comment></comment></comment><comment><USER32> I'm still trying to make sense of this announcement. With a lack of type annotation in the Ruby core, I chose to build off YARD to make gradual type safety work. Now I don't know if there will be a standard that supports type safety or if I should continue down the path I'm already following. Help me, Ruby core developers. You're my only hope.

(edit: I should have explained that I'm talking about the type checking features I'm developing in Solargraph: [https://solargraph.org/guides/type- checking](https://solargraph.org/guides/type-checking))

<comment><USER33> I hear you. It occurred to me that Ruby could have chosen to innovate with something like a Semantic TomDoc. To choose a separate file based approach seems like a step backward. At the very least it could have been module based. But Matz is a C coder -- not a Ruby coder. So it doesn't necessarily surprise me.

It's sad though. Since poor design of Refinements, C transpiling for 3x project, and now this, I am less and less inclined to continue using Ruby. I miss some of the dynamics but I find myself using Crystal instead.

(Honestly, if any one figured out a way to supplement Crystal with dynamic behavior for those features that a static language can't offer, Ruby would be done.)

<comment><USER7> As soon as I feel comfortable maintaining a Crystal server in production I think I'll switch to it. Last I tried it, things broke and shards required some effort to maintain every version update. I'm eagerly looking forward to their 1.0 and hoping they stabilize a lot more.

</comment></comment></comment><comment><USER31> The article's use of "typed vs untypes" instead of "statically vs dynamically typed" is really unfortunate, and doesn't exactly inspire confidence.

<comment><USER34> Indeed. To expand on your point: yep, it's incorrect. An untyped language is a language in which there is no concept of type. Assembly languages tend to be untyped. Forth is untyped.

The Ruby and Python languages do have the concept of type, it's just that they're dynamically typed, not statically typed. They check types at runtime.

<comment> iso8859-1 But when you have things like "duck typing", don't you think "they check types at runtime" becomes less meaningful? The majority of functions written in Python, even the ones that have type annotations, do not effectively have "assert isinstance(...)" in the program text below their signature, which is what I'd expect after reading "check types at runtime".

Also, Python now has (in its stdlib!) things like typing.Protocol, which is almost exclusively checked at type checking time. So if such a thing exists, and you still say "types are checked at runtime", isn't that confusing?

<comment><USER31> I don't really know what you're trying to say here.

Why would it be less meaningful to say types are checked at runtime with ducktyping? The nature of ducktyping is that the specific class of an object does not matter relative to behaviour, but a class is not entirely equivalent to a type.

If I need an object that implements method `foo`, and don't care about class, then "objects that implements foo" is in itself a type, that can potentially be inferred and checked be it at runtime or before.

> The majority of functions written in Python, even the ones that have type > annotations, do not effectively have "assert isinstance(...)" in the program > text below their signature, which is what I'd expect after reading "check > types at runtime".

You're thinking his "checks types" too narrowly. Every time I try to call a method on an object in a strongly typed language, typing is involved. It doesn't so much "check" it as _look up the method_ to see whether this method applies to this specific _object_ _at this point in time_ and decide whether or not to throw exceptions.

But the point remains that it is a typed. And _strongly_ so - in both Ruby and Python objects has a type associated with the object itself, unlike e.g. C or C++ which are weakly typed because it is the _variables_ that are typed, not the values.

<comment><USER34> Quibbles with your final paragraph: that's not what _strongly typed_ means. It refers to when a language has strict rules restricting implicit type conversions. [0] Also, C++ has RTTI.

[0] [https://learn.adacore.com/courses/intro-to- ada/chapters/stro...](https://learn.adacore.com/courses/intro-to- ada/chapters/strongly_typed_language.html)

<comment><USER31> It's not that simple. There's no uniform definition of strong. You're right strong typing is often used to refer to absence of (or restrictions to) implicit type conversions, but it has also since the beginning been used to reference languages that does not prevent obscuring the identity of the type of an object.

E.g. Liskov and Zilles [1] defined it this way for example:

"whenever an object is passed from a calling function to a called function, its type must be compatible with the type declared in the called function."

Under this definition C and C++ fails hard, since you can statically cast a pointer to an object and pass it to a function expecting a totally incompatible type.

Note that the system described relied at least partly on dynamic/runtime type checks (in case it reads as if the quote above suggests they used "strong" to refer to static typing):

"It is desirable to do compile-time type checking, since type errors are detected as early as possible. Because of the freedom with which types can be used in the language, however, it is not clear how complete the compile time type checking can be. Therefore, the design of the language is based on a runtime type checking mechanism which is augmented by as much compile-time checking as is possible. "

[1] [https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.13...](https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.136.3043&rep=rep1&type=pdf)

<comment> iso8859-1 If C++ fails when you do casts, why doesn't Haskell fail since it allows infinite recursion to build terms of whatever type you like? You can make the same argument: "don't do that". C++ compilers can warn when you cast. Haskell compilers can warn on incomplete pattern matches.

Is the definition you use not so broad as to admit all invariants being described as types?

If a method requires a dictionary arguments with a certain key, is that a type to you? If you extend the term "type" to cover all invariants, I don't think that is the way that the term is commonly used, even though many invariants can be proven in e.g. dependently typed languages.

All these terms are so wonky because a C++ type is not equal to a Haskell type. So I feel we can't ever have solid definitions of terms like "strong", since it depends what you compare it to, and it also depends what you compare from. So while X is strong in comparison to Y, that doesn't say much about X's relation to Z.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> I don't understand the benefits of forcing it to be in a separate file. I'd rather at least optionally you could include the types in the source file where you defining the methods.

Being able to define an interface instead of pure un-specified "duck type" is great.

</comment><comment><USER35> Separate ruby header files with type information? Seriously? What's the rational behind that? Is it just to make clear that the ruby interpreter doesn't really care about the type information and doesn't use it to improve the code's performance?

With all due respect, but IMHO this is too little and much too late.

<comment><USER36> Isn't this similar to how TypeScript allows annotations for JavaScript to live in separate files? My (possibly naive) assumption is that the goal is to make it easier for developers to write type annotations for projects they use without necessarily having to convince the maintainers to add them to the project itself. I've heard of people using TypeScript annotations from [https://definitelytyped.org/](https://definitelytyped.org/) for dependencies which don't have their own annotations.

<comment><USER37> .d.ts files are mostly compilation output, only if the original source is JavaScript you write the definitions by hand. TypeScript developers normally work with types inside their ordinary .ts (JS+types) module file, not in a separate source file.

</comment></comment></comment><comment><USER38> How does this compare to the sorbet project? Is it two different implementations for the same goal or is it adding support in ruby so sorbet can also benefit?

<comment><USER39> The sorbet project has an FAQ about that (I was curious too):

[https://sorbet.org/docs/faq](https://sorbet.org/docs/faq) search for "RBS" (on mobile, no deep links)

<comment><USER40> [https://sorbet.org/docs/faq#when-ruby-3-gets-types-what- will...](https://sorbet.org/docs/faq#when-ruby-3-gets-types-what-will-the- migration-plan-look-like)

</comment></comment></comment><comment><USER41> I likely am missing some context, but the comparison to TypeScript's ".d.ts" files seems misplaced. This is a type signature language, but it does not seem to be a type checker.

The comparison to .d.ts files then seems bizarre because that is helpful for language servers¹ to consume types, but there's no proof that say, the implementation matches the type specification.

TypeScript declaration files _declare_ what the types of module exports are. For the most part, a .d.ts file informs the typechecker "the type of module Foo export bar is the interface named Quux". This is not _checked_ , this is simply an assertion. The language server for TypeScript will pick these definitions up, assume they are correct, and provide code completions for those types as if they were correct.

On the other hand, a .ts file, combining types and codes, enables type _checking_. If the type declarations are incompatible with the code, an error is thrown by TypeScript. While .d.ts files _declare types_ , .ts files verify that the code and the types declare are compatible.

Since .rbs files simply describe the external interface of types and modules, and cannot describe internal variables, I'm not sure how it's doing any type _checking_.

For example, if I have this code:

        module Foo
          class Bar
            def trivial: () -> String
          end
        end

What prevents me from writing this:

        class Bar
          def trivial
            return 42
          end
        end

Or alternatively, this:

        class Bar
          def trivial
            x = some_function_that_might_not_be_declared_in_an_rbs_file()
            return x
          end
        end

Does x have a type? Can I gradually type "class Bar" via type inference, or do I have to declare _and keep in sync_ all my rbs files with my rb files? What happens when the rbs file is out of sync with the rb file?

¹ Language servers are implementations of an IDE protocol for code completion. The trend in programming language tooling is to use Microsoft's Language Server Protocol ([https://microsoft.github.io/language-server- protocol/](https://microsoft.github.io/language-server-protocol/)) to provide code completion, semantic navigation, refactoring, etc.

<comment><USER10> The type checker implementations (eg; Steep, Sorbet) should throw an error at `return 42`. If `some_function_that_might_not_be_declared_in_an_rbs_file` is not known, the behavior may be configurable – it could be assumed to be something like `any` or assumed to be unsafe, and error until you declare that function. I think Sorbet has this configurability today, and I'm not sure about Steep's behavior.

Steep: [https://github.com/soutaro/steep](https://github.com/soutaro/steep)

Sorbet: [https://sorbet.org](https://sorbet.org)

</comment></comment><comment><USER42> It's a separate RBS file for now, but if/when this gets integrated into Ruby itself how will it interact with the new Ruby 2.7/3.0 keyword argument syntax that also uses the colon? [https://bugs.ruby- lang.org/issues/14183](https://bugs.ruby-lang.org/issues/14183)

<comment><USER18> note that syntax isn't actually new in ruby 2.7 or 3.0 at all. It's been around since ruby 2.0 in fact (Feb 2013). (keyword arguments had to be declared with default values until ruby 2.1, Dec 2013).

What ruby 2.7/3.0 do is rationalize some really weird counter-intuitive and ambiguous edge cases related to passing a Hash arg expecting it to be invoked _as if_ it were keyword args. But it's a change in semantics, not syntax. The keyword argument _syntax_ , keyword arguments with colons, in both method definitions and invocations, has been around for years, unchanged.

</comment></comment><comment><USER43> I'm really loving how this is intended as a starting point, so that the community can continue to build and explore on top of it. Feels very Ruby Is Nice, So We Are Nice.

</comment><comment><USER44> Types help communicate information to the next developer. They're important, use them!

<comment><USER45> This isn't just about Types, _per se_. Ruby has types all over. You can't write Ruby without them.

This is about Static Typing and Type enforcement, in the context of a language that holds flexibility and meta-programming as high values.

</comment></comment><comment><USER46> Checking that something is a String is pretty weak and uninteresting.

How about checking that a given string is non-blank?

That tends to fully leverage Ruby's dynamic nature.

But then again people are overly fixated with compile-time, Java-like signatures.

See clojure.spec for a success story.

<comment><USER47> > How about checking that a given string is non-blank?

Because when you try to do this with some object that doesn't have a "length" or "empty?" method, your application crashes.

        irb(main):013:0> a = 1
            => 1
        irb(main):014:0> b = "1"
            => "1"
        irb(main):015:0> b.length
            => 1
        irb(main):016:0> a.length
            Traceback (most recent call last):
                4: from /usr/bin/irb:23:in `<main>'
                3: from /usr/bin/irb:23:in `load'
                2: from /Library/Ruby/Gems/2.6.0/gems/irb-1.0.0/exe/irb:11:in `<top (required)>'
                1: from (irb):16
            NoMethodError (undefined method `length' for 1:Integer)
        irb(main):017:0> b.empty?
            => false
        irb(main):018:0> a.empty?
            Traceback (most recent call last):
                4: from /usr/bin/irb:23:in `<main>'
                3: from /usr/bin/irb:23:in `load'
                2: from /Library/Ruby/Gems/2.6.0/gems/irb-1.0.0/exe/irb:11:in `<top (required)>'
                1: from (irb):18
            NoMethodError (undefined method `empty?' for 1:Integer)

This is why people want a way to know if something they think is a String is actually a String, without risking data loss and outages at runtime.

I think it's rude to dismiss people asking for this as "fixated," and furthermore it could be no less fairly used against people who show up to these debates beating their own drum against it.

<comment><USER46> One can check that something is a string _and_ not a blank one.

There are two _different_ libraries that do it:

[https://github.com/plumatic/schema/blob/ddb54c87dea6926c6d73...](https://github.com/plumatic/schema/blob/ddb54c87dea6926c6d73542e517b53685cc82a37/src/cljx/schema/core.cljx#L594)

[https://github.com/clojure/spec.alpha/blob/eb49d429e85b6878a...](https://github.com/clojure/spec.alpha/blob/eb49d429e85b6878a61443e853be26092ff6e249/src/main/clojure/clojure/spec/alpha.clj#L495)

Honestly I highly suspect that many, many "typing" solutions out there are plain ignorant of the whole spectrum of choices one can make, are tend to lean towards Java-like APIs out of that ignorance.

This is not limited to Ruby, I also see it in TypeScript which is very much a contrived system for real-world usages while making little use of JS's dynamism.

<comment><USER47> I'm glad we agree that adding type annotations to code is a good thing. You aren't arguing against that–you are just arguing implementation details. If I'm designing a 5 9s service tasked with processing gigabytes of data every unit time, I don't want to pay the runtime cost of checking the types for every mundane operation like measuring the length of a string.

<comment><USER46> Design by contract (which the mentioned libraries excel at) isn't a new thing, and the mentioned one is a solved problem. [https://en.wikipedia.org/wiki/Design_by_contract#Performance...](https://en.wikipedia.org/wiki/Design_by_contract#Performance_implications)

<comment><USER47> It is evidently not a solved problem. Why would large financial services companies be working on these things we're talking about if that were the case?

Do you know what solves the problem of checking every type of every thing you want to use before you use it, where the checks don't incur any performance penalty at runtime? Static type checkers!

Modern compilers usually don't even require any explicit type declarations, as they can infer at assignment. So they provide more safety for less code than your examples.

</comment></comment></comment></comment></comment></comment><comment><USER48> > Typed languages are suitable for larger projects but are often less > flexible. Untyped languages allow for rapid development, but scaling teams > and codebases with them can be difficult.

Well some of us disagree with the statement that untyped is not suitable for large teams. And that's why we use Ruby. There is a lot of very good typed languages out there if you do want typed. I feel Square and Stripe are pushing their own codebase issues onto general Ruby - as it's our problem to solve - which is not cool.

</comment><comment><USER49> Interesting. I'm surprised they didn't opt to do this inline with the rest of the ruby code, because now they can diverge from each other. It's a bit like a separate header file in C/C++/Obj-C, except in those cases the compiler will yell at you if the implementation doesn't match the header. Having it blow up at runtime instead doesn't feel like such a big change from the way it is now, other than helping out IDEs.

<comment><USER50> > I'm surprised they didn't opt to do this inline with the rest of the ruby > code,

As they mention in the post, they followed typescript's approach, here. The benefit is it allows you to layer in typing into an existing codebase in a non-disruptive way.

<comment><USER49> But as I mentioned the downside of this is that any mistakes don't become evident until at runtime. While the python way has the same problem (they're not compiled languages after all), by inlining to the existing source there's less changes for divergence to happen.

<comment><USER51> Remember this is designed by companies that already have existing, large, ruby codebases. For them, it makes a lot of sense to be able to incrementally add typing without having to make changes to the underlying code itself.

<comment><USER52> You can do both. Python allows for external .pyi files, for situations where you can't modify the underlying library (for example: it's written in C). There are tons of them: [https://github.com/python/typeshed](https://github.com/python/typeshed), but you can still add types to new code inline.

<comment><USER51> You can, but clearly the people designing this system have weighed the pros and cons and found that there would be more benefits to them to leave the source code unchanged.

<comment><USER14> Yeah, there was a ton of discussion on this in the Ruby bugtracker and at core meetings. Matz is very sensitive to breaking the language with Ruby 3 and the core team is doing their best to ensure an easy transition.

</comment></comment></comment></comment></comment></comment></comment><comment><USER53> > Typed versus untyped is a 30-year-old issue for programming languages.

I'm pretty sure the merits of typed vs untyped has been going on since the 1950s at least. 30 years is such a specific period of time that it makes me wonder what happened in the early 90s that the author is referring to.

<comment><USER54> Ruby was invented? :)

<comment><USER55> And JavaScript and Python, and a whole host of languages that didn't care about strong typing

<comment><USER53> None of these were the first untyped languages, or even the first widely used untyped languages.

<comment><USER31> In fact none of them are "untyped". They are strongly typed.

BCPL could conceivably be described as untyped.

</comment></comment></comment></comment></comment><comment><USER56> At some point it makes more sense to switch to Crystal.

<comment><USER57> Crystal is pretty unstable at the moment (in that it changes often). I have a very small project in crystal (discord bot with only a couple of commands that CRUDs a database). Every time I deploy to heroku, if heroku updated crystal, the bot breaks. I have to spend an hour determining what broke. The language changes _so often_ that either I update with heroku or I can't use any newer libraries for development.

And then you get stuck in very opaque error loops with the typing where it's expecting eg. a Number. no, not that number, a different type of number. no, not that type either. no, not that type. Most the code i've written has been typecasting.

Crystal does have some significant benefits over Ruby (which is why i'm using it - better memory use, better for scaling for my purpose) but I just spent time rewriting the non-user facing, non-scaling part of the bot in Ruby so I could actually get stuff done instead of fighting the language.

Of course a lot of this might be my inexperience with Crystal, but as a Ruby dev for 13 years, it's not as easy as just switching over from Ruby to Crystal. I've had this bot running 4 years and it hasn't got any easier for me.

<comment><USER58> > Every time I deploy to heroku, if heroku updated crystal, the bot breaks

Have you tried adding a `.crystal-version` file as described in the buildpack's README? [https://github.com/crystal-lang/heroku-buildpack- crystal#cry...](https://github.com/crystal-lang/heroku-buildpack- crystal#crystal-heroku-buildpack)

<comment><USER57> Yeah, the issue is more that I can either keep Crystal updated and use all libraries, or keep it frozen and be restricted in what I use. It's not mature enough yet to be able to lock it down and have more or less Crystal's entire shard collection available to me, like I can do in Ruby. Reminds me more of Ruby a decade ago with 1.8.7 and 1.9.2 and 2.0 (which is fine for it to be at, esp for an evolving language, but it's not "there yet" to be a replacement for Ruby)

One incident that stands out is that certain Postgres support was only available in the latest version of a shard, which required the latest version of Crystal, which wasn't compatible with 3 of the other shards I was using.

</comment></comment></comment></comment><comment><USER59> I guess this is just the foundation. A way to check types before runtime. I can see a lot gems making this experience better so I'm not too worried about that. It will become better, and it is optional.

For the time being I think this kind of type checking is only worthwhile in big projects, for smaller projects I have found Sorbet never finds an error, so it's just extra work to generate the files on a big change.

</comment><comment><USER8> I use unit tests as a design and documentation tool.

Since we already have a specification tool (MiniTest) in the StdLib it would interesting if we could combine the rbs files with spec unit tests.

I already have my matching test file open anyway. Having the typing information in the same place would encourage the use of types, tests and documentation.

</comment><comment><USER60> Anyone know, or have a guess, what RBS stands for? I'm not finding it in the article or library.

<comment><USER61> I'm seeing the type annotations being referred to as "signatures" in a couple of places. (R)u(B)y (S)ignatures seems like a reasonable guess.

<comment><USER14> That would be correct.

</comment></comment></comment><comment><USER62> I wonder if this type information can be used by the vm to improve performance?

<comment><USER14> Matz had mentioned this as a key reason he was interested in working on this, as well as a "language server" with a lot of really interesting features like what JS/TS has with VS Code.

I had the good fortune to hear him talk about it at length at a conference a while ago and there's all types of fun stuff on the way.

</comment></comment><comment><USER63> As an avid Rubyist I have no interest in introducing types into a dynamic language. I would just rather use C# or Java. I never understood why people are trying to make a round peg fit in a square hole.

<comment><USER64> It's insane to me that people are still arguing against static types. TypeScript has proven that you can add the safety of static types without taking away any of the flexibility of dynamic typing. Every time you dive deep into source code to figure out what a field is called or what a function expects, remember that you could have eliminated that completely with static types.

<comment><USER23> Perhaps if people have not used JS and TS, they would think that typings are in their brain memory but typings are a lot more than scalar and return value typings like defining a structure of a hash and apply that dynamically depending on parameter value or give string an enum like behavior limiting what could be assigned.

</comment></comment></comment><comment><USER65> > Untyped languages allow for rapid development

Citation needed. In my experience this is a fallacy; types take no time at all to write and significantly reduces bugs (Typescript).

</comment><comment><USER25> I just want typescript for ruby. That simple

<comment><USER23> With all the prior arts, I'm not sure how ruby didn't pick up the good parts and made it better than others.

</comment></comment><comment><USER11> I prefer Python's typing module to this.

</comment><comment><USER66> Really exciting!

</comment><comment><USER67> best type-checking system in my experience has been F#. You don't even have to declare types.

</comment><comment><USER33> No multimethods for you!

</comment><comment><USER68> How does this interact with method_missing, the soul of rails? Obviously much of the rails api is defined dynamically, not statically. I could see runtime checks having some value but I'm not sure how an IDE could take advantage of this, period. I'd imagine you'd at least need to generate methods (rather than parse and route messages at runtime) to make this remotely viable.

I'm not super familiar with ruby outside of my work so I'm not sure if this reliance on method_missing is more widespread than rails.

<comment><USER3> You're correct in your assumption you'd need to generate methods, from my quick investigation into how Sorbet handles it - <USER2> [https://github.com/chanzuckerberg/sorbet- rails](https://github.com/chanzuckerberg/sorbet-rails) for some details.

</comment></comment><comment><USER69> They would do better contributing to Crystal, but what do I know.

</comment><comment><USER70> RBSup dawg. I heard you like type signatures, so I created a file format called .rbs, so you can alt-tab while you code.

<comment><USER23> More like ctrl-tab in the same editor.

</comment></comment><comment><USER71> It has been so long since I last heard activities on Ruby. I had assume people moved on to Go or Rust for high traffic work by now.

<comment><USER51> > for high traffic work

Considering how prevalent Rails is for Ruby, we can assume that the majority of Ruby codebases are web apps. There are tons of way to scale Ruby web apps for high traffic, and a tiny minority of companies end up reaching a scale (like Twitter) where Ruby becomes infeasible.

</comment></comment><comment><USER72> I absolutely hate this.

Separate files for types with no inline annotations possible? What an embarrassing compromise. This is all because Matz explicitly won't allow type signatures in .rb files. I wonder how long it'll be until a hostile fork if he doesn't change his mind.

<comment> amw-zero I wouldn't call it "embarrassing." What is the actual benefit of having inline type annotations? What is the actual downside of having them in a separate file?

<comment><USER23> How hard is it to imagine that you need to keep 2 files in sync, and that you can't type anything inside a method.

I was even hoping to use ruby as a main language having used it before but I'm about to lose any interest in the language when its reality is a bit decoupled from the rest of the world.

<comment> amw-zero Have you ever worked with a language that has header files (C/C++) or a language that can use them optionally (Ocaml)? In practice, keeping the files in sync isn't difficult. In fact, it ends up being better (for me) in terms of readability, because I can look up the type definitions in one place, store them as context, and then read code that isn't littered with type annotations. Type annotations add quite a bit of noise to code. I think that's what Matz is going for here. You need to be able to keep the readability of Ruby, which he's dedicated his life to.

<comment><USER73> Not to anecdote too hard, but the practice of doing type signatures out-of- line that you are describing is my absolute least favorite part of OCaml, which is otherwise a very lovely language. As for C++, it has enough other stuff going on that I probably can't say the header files are my _least_ favorite feature, but they certainly don't make life easy. I think it makes sense to challenge that decision from an ergonomics standpoint, even if it makes sense within the constraints the Ruby core team has decided upon.

<comment> amw-zero I very much like Ocaml signature files. Jane street recommends using them, as an example. There's no other way to communicate the high level contract of a module. With type signatures that are in line with the code, the high level contract gets lost.</comment></comment></comment></comment></comment></comment>


Swift |The perfect wallet to access your money with a quick swipe - <AUTHOR> https://www.kickstarter.com/projects/vincolife/swift-the-worlds-first-rapid-access-wallet?ref=ez1u13 <comment><AUTHOR> Hey Hackers,

We made the Swift Wallet. It was based on our previous design, the Vinco Wallet, which was so minimal it was basically a card holder.

We designed this wallet to bring about a new kind of wallet. Too many wallets are either small pouches, like our old wallet, where you have to fold you notes or overly bulky traditional wallets where everything gets lost inside them.

With this new type of wallet, we're bringing about a change in the way people see their wallets. They're no longer a nuisance that gives you back pain, they're a slim, modern piece that has more utility than their old wallet ever did.

The Swift lets them get to their items as fast as possible and in the most graceful way. You can see all your notes, you can pick the exact card you want and never stop at contactless terminals with the outer unshielded pocket.

The best thing about the wallet is that it looks amazing, let us know what you think in the comments. We'll be here all day to take questions!

Cheers,

Ibbe @ Vincoe</comment>


Ask YC: Visiting Seattle week of Feb 25th, who should I meet? - <AUTHOR>

(For a quick background, here's my bio: http://en.oreilly.com/gspwest2008/public/schedule/speaker/2605)
I'm originally from Seattle and recently moved to San Francisco last year to join Mohr Davidow Ventures as an Entrepreneur-in-Residence. I've since left, and am working on a new project.
There's a ton of great hackers in the Seattle area, but it's not as easy to reach them - who are some interesting people I should meet when I'm out there? I'd like to set up a lunch or two while I'm in town, and get everyone together.
Any ideas?
intros and recommendations can go to voodoo[at]gmail. <comment><USER2> meet tony wright! i wish i can meet him for lunch

<comment><USER3> Heh-- Tony Wright is down in CA for YCombinator... I'll have to grab Andrew sometime in SanFran.

Where the heck are you? Alaska?!

<comment><USER2> i'm in the south bay, let's grab lunch sometimes!</comment></comment></comment>


Boiling point: redesigning the kettle for the 21st century - <AUTHOR> http://www.theguardian.com/business/2015/feb/08/innovators-boiling-point-redesigning-kettle-miito <comment><USER2> I'm not seeing the point here, especially for $120.

If it's fast, you'll end up with an extremely hot metal rod at the end of the cooking process, which you have to wash if you're heating anything other than water, and which will burn milk, soup, etc. Plus, you can't use it with metal containers, so a stainless-steel insulated travel mug is right out, unless you want to drink your tea with an oven mitt.

Plus, there's no mention of how much of a household's energy budget is spent heating water. I'm guessing "not very much," so energy savings are a red herring. $120 spent on LED lights or insulation around your hot water heater will probably save a lot more.

To make a single cup of hot water, it's much easier to: (1) microwave it; (2) stick in an immersion heater; or (3) pour a cup's worth into your kettle, turn it on, then pour the result back into your cup.

EDIT: Relevant, more detailed analysis: [http://physics.ucsd.edu/do-the- math/2012/05/burning-desire-f...](http://physics.ucsd.edu/do-the- math/2012/05/burning-desire-for-efficiency/)

<comment><USER3> Kettles are only for water. Ever.

<comment><USER4> Right but the article mentions how this invention will allow you to heat other liquids:

> The design's capability of heating soup and food for babies as well as a > coffee in a cup means the invention has left the kettle far behind, said > Grase, 26.

</comment></comment></comment><comment><USER5> Well you can get a cup size immersion heater:

[http://www.amazon.com/Instant-Immersion-Heater-Portable- Beve...](http://www.amazon.com/Instant-Immersion-Heater-Portable- Beverage/dp/B000VK0DRY)

For about $9. We used to have those growing up.

But those can be very unsafe. (Or at least those designed and built by the Soviet industry were...).

<comment><USER6> I used to use these. Convenient on the go, always amazed my fellow travelers. But then I read an Amazon review where the guy used a multimeter to demonstrate that his model conducted electricity into his cup... and I decided to stick to normal kettles from then on!

<comment><USER7> If you pass an electric current through a metal coil you will create a magnetic field. A magnetic field will create an electric field. So it isn't surprising a heating coil produces an electricity into the cup. What is important is how much and where.

Most people, I assume, are smart enough not to put there finger into a cup of hotwater to find where the electric current runs through.

<comment><USER6> I had the additional problem of using a metal Klean Kantern to boil my water, so it was easy to forget to not touch the outside. (Mine never shocked me, but I get the feeling that these things aren't exactly made with care...)

</comment></comment></comment></comment><comment><USER8> Electric heating elements that can be used with a mug are nothing new. This is recycled 1970's tech, if not older. The only difference is that this is IH, which just makes it a more complicated mouse trap than the following compact (and cheap!) design:

[http://ak.picdn.net/shutterstock/videos/1497616/preview/stoc...](http://ak.picdn.net/shutterstock/videos/1497616/preview/stock- footage-accelerated-heating-water-in-a-mug-with-a-compact-boiler.jpg)

That's something you can slip into your backpack for traveling.

Google image saerch for "immersion travel water heater":

[https://www.google.com/search?q=immersion+travel+water+heate...](https://www.google.com/search?q=immersion+travel+water+heater&tbm=isch)

This IH-driven metal stick is not going revolutionize the way we heat liquids. If the market was eager for immersion heating, the existing immersion heaters would be everywhere. You don't see them much, though, and they have had decades to take off.

</comment><comment><USER9> Brilliant, revolutionary, fresh, lets make a kickstarter and pour millions of dollars into this, after all its standing vertically!

[http://termos.com.pl/p/2013/09/turystyczna-grzalka-do- gotowa...](http://termos.com.pl/p/2013/09/turystyczna-grzalka-do-gotowania- wody-okazja-2-3473815171.jpg)

</comment><comment><USER10> In our office we have this

[http://www.billi.com.au/](http://www.billi.com.au/)

Spits out near-boiling water heated on-demand basically instantly.

<comment><USER11> Looks cool, but not sure it's something I'll ever be able to motivate a buy for.

(I went to the site and did a first scan with the words 'Spits out near- boiling water heated on-demand' and the first image i saw was this [http://www.billi.com.au/cms_images/17_29-09-2012_2608.png](http://www.billi.com.au/cms_images/17_29-09-2012_2608.png) which made me chuckle.)

</comment></comment><comment><USER12> Would be interesting to see some specs/measurements to substantiate their proposed energy savings -- without an insulated heating vessel it's hard to believe this is more energy efficient than existing technology.

<comment><USER13> Even using an insulated kettle, the water ends up in the same uninsulated cup.

It seems the biggest efficiency comes form heating much less water in the first place. Given that a typical cup of tea will stay hot for several times longer than the time spent heating it, the lack of insulation should be more than made up for by heating less water.

But, yes. Specs and measurements are required to substantiate specific claims.

<comment><USER14> A lot of teas need the water to be a specific temperature before they are put into cups/have the tea leaves inserted. Even if "the water ends up in the same uninsulated cup", the process of getting the water to the correct temperature will be more efficient in an insulated container.

Also, it's hard to believe that this would substantially decrease the amount of water heated. If you were super anal about only heating the water needed, then that's do-able with a tea kettle. If you're not, then even under the new model you would probably just use a kettle or pot most of the time.

</comment></comment></comment><comment><USER15> Really?

We had those for at least 50 years:

[http://www.img.chh.pl/large_size/cdeeb903fbbd7e9488757bb92fc...](http://www.img.chh.pl/large_size/cdeeb903fbbd7e9488757bb92fcbe97f.jpg)

I don't see how it's any different?

</comment><comment><USER16> I'm not a tea drinker but I've always wondered why people don't just use the microwave.

<comment><USER17> So I don't have any real proof but there's a common belief that I also share that microwaved water tastes different from kettle-boiled water. I realize many people will dismiss this, but most of them probably aren't tea drinkers. And that all said, I'm sure there are a lot of people who use microwaved water for tea and are very happy with it.

Also, if you're making a pot of tea a kettle generally works better. Not sure if I'd want to put a whole teapot in my microwave.

Anyway, the real solution is to own one of these: [http://www.zojirushi.com/app/category/water- boilers](http://www.zojirushi.com/app/category/water-boilers)

<comment><USER18> Can confirm, just microwaved my tea water this morning. Still yum.

</comment></comment></comment><comment><USER19> Big-ass induction coil... bet it would do a quick number on a credit card. Or a thumb-drive... or a phone... "Oh, is that one of those induction battery chargers?" fzzzzt!

</comment><comment><USER20> $120 is expensive.It would take 16 years to make 2 cents on your investment. You don't believe me, here is my calculation:

Regarding energy usage: 1 cup of water is 28 grams t0=25s t1=100s C=4.18 _10^3J /kg.s Q=mc(t1-t0) for boiling Q=.028_4.18 _10^3_ 75=8778J 8778J correspond to 0.00243833333 kilowatt hours so if you pay .11$ per Kw hour we are talking about 2 cents per cup! If we are wasteful and 2 cups of water and drink 1 we have wasted 2 cents. How much time I have wait to make profit on my 120 investment. 120/0.02=6000 And if you drink 1 cup of tea a day. You have wait 6000/365=16 years. You have to wait 16 years to make money on your investment.

<comment><USER21> Uh, no, a typical cup is way more than 28 grams of water.

A standard metric cup is 250 ml, so you're off almost by a factor of 10 on that value, at least. I didn't check your calculations, perhaps that was just a typo though.

</comment></comment><comment><USER22> I wonder if there's any technical reason they wouldn't be able to have a thermometer at or near the end of the rod. It would be interesting to see it heat the rod rapidly and then fluctuate the induction base when an ideal temperature is reached in order to maintain that temperature. Ideally wirelessly, but I suppose the top of the rod could have a tether back to the base.

Different substances have different temperature restrictions, but it seems like for rapid heating, you could target 100C at the end of the rod but reduce power as the liquid (perhaps monitored by a second thermometer higher up the rod) approaches 70C, or whatever your preferred temperature is.

<comment><USER23> I think it'd be pretty difficult to do for arbitrary liquids, because i imagine there would be some non-trivial temperature gradients. You'd probably have to account for the heat capacity and thermal conductivity of your soup to get it close to right. Simpler and cheaper to just use an old-fashioned thermocouple that clips onto the mug wall or something.

<comment><USER22> That's a good point. Perhaps an infrared sensor pointed down from the handle would give you meaningful data.

</comment></comment></comment><comment><USER24> OT: I've always wondered, why aren't pots (edit: all pots, not just water kettles) insulated? And to take it step further, why aren't the stove burner and its interface with the pot also insulated?

To test the energy loss yourself: Put a pot on the stove, turn on the stove, and hold your hand over the pot, next to the pot, and also touching the side of the pot. (DO NOT DO THIS. It's dangerous. Do it as a thought experiment instead.)

<comment><USER25> The nice ones are (and solve this wasted energy problem, and eliminate time spent waiting for water to boil, and any rain dance to get non-100C water)

[https://zojirushi.com/app/category/water- boilers](https://zojirushi.com/app/category/water-boilers)

<comment><USER24> Thank you. For people who want to know more about Zojirushi's tech:

[http://www.zojirushi.com/product/product_wb_01.html](http://www.zojirushi.com/product/product_wb_01.html)

Do you know of insulated products for other types of pots, besides kettles?

</comment></comment></comment><comment><USER26> It should come with a set of tea spoons with insulated handles, then you could put instant coffee in your cup, stir and heat with the same object!

<comment><USER27> It should also come in a 'kettle' so that it can be used conventionally in a receptacle with pouring spout. This would make migration easier. A kettle with a removable element that you can put straight in your cup.

</comment></comment><comment><USER28> This is a great place to ask 2 questions:

1) Anybody using single serve electric kettles that have variable temp heating? Some teas need lower temps and I'm usually drinking 1-2 cups at a time.

2) I've always imagined building some kind of adjustable mechanical whistle into a kettle to accomplish this. Is that possible to make a kettle whistle with "low" steam?

<comment><USER29> Chinese tea shops often use little electric kettles (maybe two cups worth) that sit on a base, and are kept at a constant (adjustable) temperature, usually just below boiling. The constant heating is good for lengthy tea sessions -- if you just want a cup or two you could probably just switch it off when it reaches the right temperature.

</comment></comment><comment><USER30> ~ 1 in 1000 children in the UK suffer from scalding accidents every year involving kettles, so anything to reduce the quantity of boiling water around is good, I've got one of these, works just fine [http://www.onecupkettle.co.uk/](http://www.onecupkettle.co.uk/)

</comment><comment><USER31> I have a small and cheap kettle (1L), which I just fill with the amount of water that the cup has. Problem solved.

</comment><comment><USER32> My grandparents use this little boiling device. May not be fancy looking but it's does the job, it's cheap and portable. [http://imgur.com/gallery/Yk23aAl/new](http://imgur.com/gallery/Yk23aAl/new)

</comment><comment><USER33> How fast is it? It would have to compete with the speed of an electric kettle or microwave.

Also, other than the fact that it uses induction, there are many single cup liquid boilers on the market. Their design seems really clean and efficient, though.

</comment><comment><USER34> So it works with glass, ceramics, anything non-ferrous.

What if I had a ferrous mug with say a wooden handle, would I still need the iron rod, or would the system not work at all?

<comment><USER26> Your cup would be insanely hot near the rim, so don't drink from it!

</comment></comment><comment><USER35> Why not just measure the water in your cup first, then pour it into the kettle? Seems to solve the problem for me...

<comment><USER21> That's in the article: most kettles have a minimum-fill line, which is often way above the volume required for a single cup.

</comment></comment><comment><USER20> Brilliant is an understatement for this innovative design! But it takes probably much longer time for the water to boil.</comment>


USB 3.2 is going to make the current USB branding even worse - <AUTHOR> https://arstechnica.com/gadgets/2019/02/usb-3-2-is-going-to-make-the-current-usb-branding-even-worse/ <comment><USER4> USB-IF has to be doing this to deliberately confuse end users, right? I get that it's a specification number, not a product name, but they have to know that this will only cause problems for customers trying to find the appropriate cable.

Incredibly, their language usage specifications doc [https://www.usb.org/sites/default/files/usb_3_2_language_pro...](https://www.usb.org/sites/default/files/usb_3_2_language_product_and_packaging_guidelines_final.pdf) begins with this:

> USB-IF emphasizes the importance and value of consistent messaging on USB > product packaging, marketing materials, and advertising. Inconsistent use of > terminology creates confusion in the marketplace, can be misleading to > consumers and potentially diminishes USB-IF's trademark rights.

I simply don't understand USB-IF's motivation to make this so confusing for everyone. Their board consists of Apple, HP, Intel, Microsoft, TI, Renesas, and STMicroelectronics, so it isn't like it's controlled by low end trashy cable manufacturers trying to make a quick buck from confused customers.

<comment><USER5> When quoting, please prefix lines with > instead of using preformatted text: preformatted text for blocks of prose is horribly unusable, everywhere.

<comment><USER6> Unfortunately, HN is so bad at publicizing and making this easy. I spent years assuming others knew some magical tool I didn't, before realizing people just do everything manually and stick to the same unwritten style guide.

<comment><USER7> ...it felt pretty obvious to me? ">" is pretty commonly used, in email for instance.

<comment><USER6> agreed, I just thought I was missing some hidden feature. Like, I have to do the line breaks myself? I guess?

</comment></comment></comment></comment></comment><comment><USER8> Who the heck came up with USB 3.2 Gen 2×2? That has got to be the dumbest idea. No one cares how it works, we just have to go through the utter crap of buying a cable. Does the low end manufactures pull the most weight in this org because that's the only way this makes any sense.

<comment><USER9> Why not enumerate it based entirely on features, also toss in what power delivery it's rated at in watts and volts.

USB 3 20Gbit PD 100W 20V

<comment><USER10> What's "3" for?

<comment><USER11> socket format?

<comment><USER12> you've got A, B, C, Micro, and Mini connectors all that conform to 3.0 and 3.1 spec...

Alas the standard needs standardised....

<comment><USER13> And A is always the same socket regardless of version while B is not. It's a mess.

<comment><USER14> > And A is always the same socket regardless of version

Even this is technically incorrect: USB-3 A-type sockets, though backwards compatible for f/m and m/f connecting with USB-2, have 5 more contacts compared to USB-2 type A sockets.

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> USB 3.X / USB-C / Thunderbolt 3, all of it together is confusing enough for those technical, add marketing speak to the mix and it's just going to end up with a mish mosh of different words that mean absolutely nothing and tell the end user very little.

Add to the fact that everyone is skimping on the actual USB 3 standards and a large amount of shitty products on the market that don't do what they say they do (due to poor quality control, making wires longer than spec expecting them to work to spec), we have to rely on guys like Benson to crowdsource working and non working products.

[https://bensonapprovedcom.wordpress.com/](https://bensonapprovedcom.wordpress.com/)

<comment><USER16> For real. Why not just call it USB 4.0 and divorce the branding from the technical specification? You can put a thing on the back of the box that says "implements USB specification 3.2.16a-rfc#4619" or whatever.

<comment><USER17> > Why not just call it USB 4.0 and divorce the branding from the technical > specification?

That is exactly what the "SuperSpeed USB" branding is all about. The technical spec is USB 3.whatever and the brand name is " SuperSpeed USB". But neither the press nor vendors seem to be able to stay in the line and actually consistently use only the branding, so here we are

<comment><USER18> But SuperSpeed was 5Gbps. Then it was SuperSpeed+.

This was the nice aspect of Firewire - once 1394B was out - <USER2> referred to them as Firewire 400 and Firewire 800. No ambiguity.

Heck even Thunderbolt does this better - 1 and 2 are interchangeable device/cable-wise, and just support higher speeds, but it's just a new 'version' and it just doubles the bandwidth.

With USB you have to read all the fine print to make sure you get what you want/need.

<comment><USER17> SuperSpeed+ was never supposed to be exposed to consumers:

> NOTE: SuperSpeed Plus, Enhanced SuperSpeed and SuperSpeed+ are defined in > the USB specifications however these terms are not intended to be used in > product names, messaging, packaging or any other consumer-facing content.

<comment><USER18> Oh great so it's all just meant to be "SuperSpeed".. "How super?" "Guess".

<comment><USER17> > USB-IF's recommended nomenclature for consumers is "SuperSpeed USB" for > 5Gbps products, "SuperSpeed USB 10Gbps" for 10Gbps products and "SuperSpeed > USB 20Gbps" for 20Gbps products

Yes, _guess_ how super "SuperSpeed USB 20Gbps" is

<comment><USER18> But the lowest speed _doesn 't_ specify the speed - so unless a user happens to have read the USB-IF _recommendations_ for naming, they won't know that there is a difference, if the manufacturers even follow said _recommendations_

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> Here is a helpful chart of USB versions and their connectors: [https://preview.redd.it/s9dun6a1xmpz.png?width=960&crop=smar...](https://preview.redd.it/s9dun6a1xmpz.png?width=960&crop=smart&auto=webp&s=fc8b58328a64e841d1ef62d5f90fe843617c9413)

e.g. USB 3.2 has the same connector as USB-C

edit: I personally care far more about the connector than exact specs of each version

<comment><USER20> > USB 3.2 has the same connector as USB-C

USB-C _is_ a connector, so you cannot say "has the same connector as USB-C".

It is the only connector for USB 3.2, and a connector that is compatible with USB 3.1 Gen 2.

Edit: I meant it is the only connector for USB 3.2 "Gen 2x2", and compatible with 3.1 Gen 2 (now called 3.2 Gen 2)

<comment><USER21> > It is the only connector for USB 3.2, and a connector that is compatible > with USB 3.1 Gen 2.

From what I've been able to find, not even that is reliably true. Looks like the older connectors can be labeled USB 3.2 as long as they use the "x1" scheme in the label and are capable of reaching the speed of that scheme.

</comment></comment></comment><comment><USER22> People confused with the branding don't realize that USB is by manufacturers for manufacturers, so anything that lets them claim on the box they support USB 420.69 while doing the least amount of work and spend is a-OK.

This is what happens when standards bodies have perverse incentives to confuse. See the SD Association for even worse branding.

<comment><USER23> This isn't entirely true. The point of the manufacturers together agreeing on a standard is to remove some of these perverse incentives; here's how it works in theory:

Without the standards group:

If manufacturer A is confusing, then they can sell more than manufacturers B and C. So in turn manufacturers B and C will be confusing as well in order to keep up. This is bad for consumers and generates ill will against USB in general (globally bad for A B and C)

With the standards group:

Manufacturers A B & C all agree on something non-confusing, and in order to use the USB trademark, they can't deviate from what they agreed upon. USB is now sunshine and rainbows so USB customers are happy in general (globally good for A B & C).

Something has broken down in the system if they make names that are confusing since USB being confusing is bad for everybody, and none of the manufacturers get a leg up on the others if they all use the same confusing language.

</comment></comment><comment><USER24> I really loved USB-C then they screwed it up so badly. Can we have 1 cable that is required to have every exact feature available, no exceptions? Works on any device, supports everything from storage to video transfer (Monitors) and whatever else Apple would add to it.

<comment><USER25> Look at Thunderbolt, where a cheap-ass cable still costs $20, for an idea of how that would turn out.

<comment><USER26> And USB-C 10 Gbps cables aren't much cheaper, especially if they do 100W power delivery. Both probably could be cheaper if there were more demand for them, but siren song of cheap slow cables seems to have made it impossible to scale production up.

<comment><USER27> Well, realistically, you don't need 100 watt power delivery for a keyboard, so you might want a less robust cable.

The big mistake IMO was a lack of obvious keying. Very little stops me from using that 2w-capacity keyboard cable to try to charge my laptop. If we're lucky, there's signaling at the device to tell me what's wrong, but if they had made a different plug on the 100W cable, it would eliminate a lot of cockpit errors.

Having one cable for everything is a huge red herring. If you need a keyboard and a power brick and an external hard drive, you need three cables. It doesn't matter if they're different, as long as the OEM isn't pulling some Apple-style "one single port is enough" BS.

<comment><USER26> So you'd want a low speed connector, a high speed connector, a high wattage connector and also a high speed + high wattage connector? So 4 plugs, or more if you want to add even faster speeds in the future. And then you need cables which have one of each of those connectors on each end, so we're talking about dozens of variants.

No thank you. The drama around USB-C is insanely overblown; the vast majority of use cases are fine with the 60 watt + 480 mbps required minimum configuration for USB-C cables. In the few rare exceptions where you need >60 watts or higher speed, you're generally going to have purpose-built hardware anyway, so just devoting a special cable to that isn't such a big deal.

<comment><USER28> I think the drama is mostly about the fact that there is no way to tell what a cable (or a port) "supports" by looking at it.

</comment></comment></comment></comment></comment></comment><comment><USER29> > _For reasons that remain hard to understand, the decision was made to > retroactively rebrand USB 3.0: 5Gb /s 3.0 connections became "USB 3.1 Gen > 1," ..._

> _USB 3.2 doubles down on this confusion. 5Gb /s devices are now "USB 3.2 Gen > 1."_

So when they eventually release USB 3.3, my rusty old memory stick will be auto-upgraded to USB 3.3 Gen 1? I like it!

(/s)

</comment><comment><USER17> Honestly, the USB-IF guidance is pretty sane here. The "USB 3.0" or "USB 3.1 gen 1" or whatever simply should not appear anywhere in the consumer space. Everything should be labeled and using "SuperSpeed USB _X_ Gbps".

I'd go as far to say that articles like this exactly help keep the confusion up because the way they keep bringing up the term "USB 3.2" etc as something that consumers should care about, when it is something that should be avoided.

> What this branding meant is that many manufacturers say that a device > supports "USB 3.1" even if it's only a "USB 3.1 Gen 1" device running at > 5Gb/s. Meanwhile, other manufacturers do the sensible thing: they use "USB > 3.0" to denote 5Gb/s devices and reserve "USB 3.1" for 10Gb/s parts.

Both manufacturers are doing the wrong thing: referring to the USB standard version at all. Devices should not say that they support "USB 3.0" or "USB 3.1 gen 1". They should say they support "Superspeed USB" or "Superspeed USB 10 Gbps".

Superspeed might be a silly name, but the branding there is almost perfectly unambiguous, and nicely explicit about the data rate in a way that "USB 3.2 gen 2x2" is not.

What is the most surprising is that USB-IF isn't able to keep the vendors in line despite being industry consortium and owning all the relevant trademarks and other IP. They really should start enforcing their policies more aggressively.

<comment><USER30> That's really no excuse for USB-IF's terrible versioning scheme.

"SuperSpeed" is useless in terms of branding because even technical users, much less your average consumer, have no idea what that means. Is "SuperSpeed" faster than "High Speed" or "Full Speed"? (Answer: "Full Speed" < "High Speed" < "SuperSpeed".)

"20 Gbps USB" is better than "USB 3.2 Gen 2x2", sure, but that's not exactly a high bar. It just means USB has failed so badly with version numbers that people would rather just quote a spec figure.

Wishing for everyone to switch over to "SuperSpeed" and "SuperSpeed+" will not make it so. Fact is, both users and manufacturers are accustomed to "USB 3.0", "USB 3.1", etc. And it's not hard to see why people prefer simple version numbers as opposed to meaningless labels.

USB-IF should have simply released USB 3.1 and USB 3.2 without this ridiculous business of retroactively renaming older versions.

<comment><USER17> The USB versioning makes perfect sense when you think it as the version of the standard, literally the document itself, which encompasses all the modes. And it does make sense to have single standard instead of having the information scattered across dozen historical standards that have been partially superceded.

I would point out that this is not a new thing. The situation was exactly the same with USB 2.0, technically it was perfectly correct to call compliant full speed device "USB 2.0", because 2.0 did indeed include full speed mode (as does presumably all the USB 3.x standards)

</comment></comment></comment><comment><USER31> Is it USB 2 or USB 3? Is it 3.0, 3.1, or 3.2? Gen 1, Gen 2, or Gen 2x2? Do I need USB-A or Micro USB or USB-C? Do I need USB-A on one end of this cable and USB-C on the other, or some other combination? Does it support Quick Charge or Power Delivery? If it's Power Delivery, how many Watts?

Those are just some of the questions non-technical consumers are expected to know the answers to when they are buying USB products.

This is absurd.

</comment><comment><USER32> Lightning, although proprietary, is an amazing port compared to the mess that is USB. I am going to miss it once Apple phases it out.

<comment><USER33> It's easy to make a universal port when your universe is a small handful of your own devices with no numbers to live up to.

<comment><USER34> The "small handful" adds up to about a billion devices, but it's true that they were made by a single manufacturer.

<comment><USER33> A billion devices, but just 24 different ones, over 3 product lines, plus a couple of trivial, slow ones like keyboards.

</comment></comment></comment></comment><comment><USER35> Something has to be done to stop these people.

What, I don't know. But their Joker-like approach to USB standards and practices is costing us all dearly.

<comment><USER36> I just had a thought USB is now more of a clusterf^H^H^H^H^H^H^H complicated than the mess of cables interfaces it was meant to replace back in the mid 90's.

<comment><USER37> It's amazing how much that mess of cables either wasn't solved or wasn't solved by USB. My power, network, sound and display cables weren't replaced by USB, my printer was replaced by a phone/tablet. It replaced the PS2 ports for keyboard and mouse, saving about 2 seconds of setup time at the cost of more latency.

It his (or has been) handy for connecting gadgets and drives over the years, but maybe we should go back to PS2 and just use it USB for "front of the machine" ports.

<comment><USER38> Counterpoint: A mix of USB-C, Bluetooth and Wifi have replaced my power, network, sound, microphone, printer, keyboard, mouse, phone charging, and display cables.

</comment></comment></comment></comment><comment><USER39> Shameless plug: if you want to become less confused about USB-C my primer is at [https://superuser.com/a/1200112/41259](https://superuser.com/a/1200112/41259) and also [https://www.reddit.com/r/thinkpad/wiki/newdocks](https://www.reddit.com/r/thinkpad/wiki/newdocks) contains some helpful intro.

</comment><comment><USER40> So they decided to put some maths behind the new Spec to _simplifies_ the branding.

USB 3.2 Gen 1 = (3 + 2) x Gen 1 = 5Gbps

USB 3.2 Gen 2 = (3 + 2) x Gen 2 = 10Gbps

USB 3.2 Gen 2x2 = (3 + 2) x Gen 2 x 2 = 20Gbps

Pretty Clever ( Or Dumb ).

To make matter worst they still have not make USB-C mandatory for USB 3.2. So you could have a USB 3.2 Gen 2 Host with a USB-A Cable that didn't not support the previous USB 3.0 SuperSpeed ( 5Gbps ) so it will fall back to USB 2.0 Speed ( 480Mbps ) , Or a USB-A Cable that did not support the USB 3.1 SuperSeed+ ( 10Gbps ) which is also called USB 3.1 Gen 2 and is now called USB 3.2 Gen 2 so it will fall back to USB 3.0 SuperSpeed ( 5Gbps ) and was called USB 3.1 Gen 1 and now called USB 3.2 Gen 1.

You also have crappy USB-C cables that does not confirm to the USB-C spec. And the consequences depends on the quality of the cable. [1] And in some extreme cases, you could have a USB-C cable that do not support USB 3.2 Gen 2 x 2, because some how only pins on one side are working as intended.

Although things has gotten better since his post and Google has been putting some pressure into fixing it. USB-C is still a bloody bag of hurt. So in case anyone is still rooting for iPhone using USB-C _without_ MFi. I seriously hope people will reconsider. Using MFi will defeat the purpose of USB-C since you will need a MFi Cable, which is one way to say current lightning to USB-C cable spec and cable are fine. And in case you are wondering about iPad Pro, you should take a look at the controller size, it is roughly 5 times bigger.

Or we make USB 4.0 that standardise on USB-C and force a much more stringent specification on Power Delivery, Speed and Quality. But as we all should be able to tell this isn't a technical problem, more like political, design by committees, marketing problem.

[1] [https://bensonapprovedcom.wordpress.com](https://bensonapprovedcom.wordpress.com)

</comment><comment><USER41> At least WiFi figured out how to improve.

Would love to see "USB 4" .

No ".0" afterwards, just the simpler numeral.

And if you need a bigger connector, then buy the "USB 4 XL connector" cable.

<comment><USER42> "Would love to see "USB 4" ."

I'd rather go for a (possibly faster) Ethernet with a redesigned smaller connector supporting POE. Smaller devices such as mice and keyboards could talk at PHY level while smarter ones with beefier microcontrollers could employ more and more layers of the network stack so that routing/tunneling data over the network when needed would become trivial. Security wise, there would be no physical difference between an external local disk and a NAS, but software could be used to filter devices from the network. The upside is that there would be a single stack for everything: from storage to security cameras, audio systems, data acquisition gear, sensors and actuators etc. All ports would be electrically insulated, the stack is already open and wonderfully documented, the hardware is already near realtime and there are no royalties to be paid to use that.

<comment><USER43> That was one of the original goals of Zeroconf. In 2002, Stuart Cheshire said [1]:

> My hope is that in the future — distant future perhaps — your computer will > only need one wired communication technology. It will provide power on the > connector like USB and FireWire, so it can power small peripheral devices. > It will use IP packets like Ethernet, so it provides your wide-area > communications for things like email and Web browsing, but it will also use > Zeroconf IP so that connecting local devices is as easy as USB or FireWire > is today. People ask me if I'm seriously suggesting that your keyboard and > mouse should use the same connector as your Internet connection, and I am. > There's no fundamental reason why a 10Mb/s Ethernet chip costs more than a > USB chip. The problem is not cost, it is lack of power on the Ethernet > connector, and (until now) lack of autoconfiguration to make it work. I > would much rather have a computer with a row of identical universal IP > communications ports, where I can connect anything I want to any port, > instead of today's situation where the computer has a row of different > sockets, each dedicated to its own specialized function.

[1]: [http://www.stuartcheshire.org/TheIdeaBasket.html](http://www.stuartcheshire.org/TheIdeaBasket.html)

Sadly, instead of using existing successful networking systems and automating the configuration, we've created a new union-of-all-possible-protocols with a new connector (or 5) and made understanding the compatibility matrix a nightmare.

<comment><USER42> I didn't know about that interview, thanks for sharing. It seems so natural to me to go for the one technology that fits all needs (Ethernet+POE and possibly a smaller connector). All it would need is a big player to implement that, then release the changes for free with no strings attached, but probably most parties involved can't squeeze the same profits out of open technologies.

Here's an idea to push for this technology. I have no way to develop this, neither the technical knowledge nor the money required, but comments welcome anyway. Essentially I would:

      1- design a smaller connector that could host all Ethernet pairs plus power supply,

say a smaller RJ45 with contacts on both sides, no need to reinvent the wheel here.

      2- for testing purposes, build a small bridge board (a matchbox sized black box) between the socket and the
     original Ethernet plug and a nearby USB port for power alone. Ethernet pairs would pass untouched (or possibly
     replicated through a switch chipset+magnetics) while the bridge board would contain any necessary circuit to power

any load connected to the updated Ethernet port(s). Remember we're aiming at ditching USB for that purpose, that's why I wouldn't map Ethernet on an USB- Eth chip even for testing; and all power would be taken by the device supply asap.

      3- Now we have some cheap hardware which is easy to replicate to use on every platform, including SBCs where the

USB connector could be spared because we take all power from the board. Let's move to software.

Some proof of concept would be needed to demonstrate that, so here's my question: how hard would be to satisfy point [1] and build some hardware (mice, keyboards, audio etc) that can use the new network standard to show its benefits to the industry?

</comment></comment></comment></comment><comment><USER44> Don't know if it's my dyslexic brain, but did anyone else have a hard time reading that article due to trying to keep sense of the different standards names?

<comment><USER4> It's not just you — it's virtually everyone who will be purchasing a "USB 3.2" cable in the future!

</comment></comment><comment><USER45> I feel USB workgroup is having its Winamp moment. Skip USB4 and bring us version 5: as lean as the v2 but with the good bits of v3.

</comment><comment><USER10> Wouldn't make sense to just use the speed as version ? i.e USB 5GB, USB 10GB-C, USB 20GB etc

<comment><USER46> They do that, in the "consumer branding". This is an odd case where the marketing is better-thought-out than the spec.

You have to live with calling it a "SuperSpeed" cable instead of a USB cable, though. :p

</comment></comment><comment><USER38> Where the USB-IF messed up - they should have used their trademark to standardize these cables.

They should have visibly differentiated charging and data cables, and required all cables with USB connectors at both ends to be rated 100W, and this new 20 gbps (2x2) speed if also supporting data.

Cables with USB-C and another USB port at the end should be required to meet both the power and data requirements of that connector. (so no charging compatibility connectors). USB-C to USB-A should have been restricted to 3.0 only.

Alt modes can use a plain USB-C cable (like Thunderbolt 3 does), but cannot place additional restrictions on the cable if they want USB connectors on both ends.

If the cable has any other connector on the end (such as DisplayPort), it would be up to the creator of the DisplayPort alt mode to indicate if there are any differing requirements.

Likewise if the cable is integrated into a device, it can meet its needs - <USER3> charging only, only use USB 2,etc.

This imho would solve nearly all the problems - the problem is that I can pick up a USB-C to USB-C cable and it could literally be one of (at least) six things internally - with no markings to differentiate.

</comment><comment><USER47> BTW, here is the actual guidance/press release from USB-IF

[https://www.usb.org/sites/default/files/usb_3_2_language_pro...](https://www.usb.org/sites/default/files/usb_3_2_language_product_and_packaging_guidelines_final.pdf)

To me it seems the "press" is distorting this press release.

Excerpt :

USB 3.2 Gen 1

o Product capability: product signals at 5Gbps

o Marketing name: SuperSpeed USB

USB 3.2 Gen 2

o Product capability: product signals at 10Gbps

o Marketing name: SuperSpeed USB 10Gbps

USB 3.2 Gen 2x2 o Product capability: product signals at 20Gbps

o Marketing name: SuperSpeed USB 20Gbps

USB 3.2 Key Messages

• Defines multi-lane operation for new USB 3.2 hosts and devices, allowing for up to two lanes of 10Gbps operation to realize a 20Gbps data transfer rate, without sacrificing cable length.

• Delivers compelling performance boosts to meet requirements for demanding USB storage, display, and docking applications.

• Enables end-users to move content across devices quickly, conveniently and without worrying about compatibility.

• Backwards compatible with all existing USB products; will operate at lowest common speed capability.

</comment><comment><USER48> Why don't they simply change usb-c cable identification into a couple numbers, a bit like trousers?

One for power, one for data. It could be any scale, as long as products like monitors would need data > x, phones will charge faster up to power y, laptops need power z, etc. Two numbers are easy enough to emboss, engrave, print into a connector, cable or device...

</comment><comment><USER49> > For reasons that remain hard to understand, the decision was made to > retroactively rebrand USB 3.0: 5Gb/s 3.0 connections became "USB 3.1 Gen 1," > with the 10Gb/s connections being "USB 3.1 Gen 2." The consumer branding is > "SuperSpeed USB 10Gbps."

Does anyone care about Gbps for USB? I've never hit the bandwith limitation on USB and see USB type-C as just an annoyance making me buy new cables.

> And 20Gb/s devices will be... "USB 3.2 Gen 2×2.

Pretty straight forward: USB 3.x supports 5 * 2^x Gbps. What we really need is MORE retrobranding!

\- USB 2.0 becomes USB 3-3.4

\- USB 1.0 full speed becomes USB 3-8.7

\- USB low speed becomes USB 3-11.7

<comment><USER50> > Does anyone care about Gbps for USB? I've never hit the bandwith limitation > on USB

You have if you've tried to used multiple external monitors over USB (a la macbooks).

<comment><USER49> HDMI over USB sound like hardware abuse to me. All systems I've only ever owned had write_mostly interfaces for video display.

Really, USB speed limits are mostly bound by flash memory limits so manufacturers struggle to justify a replacement. I guess faster charging is nice?

</comment></comment></comment><comment><USER51> So the very same device can be accurately labelled "USB 3.0", "USB 3.1 Gen 1" and "USB 3.2 Gen 1". Those are all actually the same thing? Do I have this right?

<comment><USER17> No, it shouldn't be labeled any of those. Instead it should be labeled "SuperSpeed USB" and nothing else. And that hasn't changed over the different USB revisions.

<comment><USER52> Except the list of speeds is ridiculously arcane. People can easily figure out that 3.1 beats 3 beats 2. Good luck getting them to guess whether "full speed" beats "high speed", or why there are three different things all called "Superspeed+"

<comment><USER17> There is not supposed to be any superspeed+ branding. From USB-IF guidelines:

> NOTE: SuperSpeed Plus, Enhanced SuperSpeed and SuperSpeed+ are defined in > the USB specifications however these terms are not intended to be used in > product names, messaging, packaging or any other consumer-facing content.

> USB-IF's recommended nomenclature for consumers is "SuperSpeed USB" for > 5Gbps products, "SuperSpeed USB 10Gbps" for 10Gbps products and "SuperSpeed > USB 20Gbps" for 20Gbps products

Those are hardly "ridiculously arcane". Full speed is not really relevant, so only thing consumers need to know is that superspeed > high speed, which I don't think as very high bar.

<comment><USER52> Did they delete the 1x2 mode? If not, the answer to "Does this cable support SuperSpeed USB 10Gbps?" becomes significantly more complicated than it should be.

But fine, if we actually see everything branded as "SuperSpeed USB XXGbps" then it's overly long but it's understandable.

I am not convinced we won't see a hideous hodgepodge of different branding guides, though. Some saying "SuperSpeed USB __Gbps", some saying "USB 3.2", some saying "gen __", some saying "SuperSpeed+"

</comment></comment></comment></comment></comment><comment><USER53> USB with and without thunderbolt was already confusing enough for your normal joe. Now you have 3 version of USB 3.2 with require you to do a detail specsheet lookup before plugging in?

</comment><comment><USER37> They should just rebrand it as SB and be done with it, there's nothing universal about it anymore.

</comment><comment><USER54> Probably the same person who made decisions for Java branding back in Sun Micro days.

</comment><comment><USER55> One of the really bad branding issues / borderline scams I have dealt with is devices saying USB 3 compatible when what they mean is usb 2 but it happens to work with usb 3 ports using usb 2.

</comment><comment><USER56> * USB 3.2 Gen 2 10 Gbps * USB 3.2 Gen 2x2 20 Gbps

Therefore, If a motherboard has two USB 3.2 Gen 2 10 Gbps port, can it be labeled as USB 3.2 Gen 2x2?

</comment><comment><USER57> It's like they're marketing pain relief, all new formula, super rapid fast action, targets pain directly....

</comment><comment><USER58> Ok, guess I'll go back to RS-485

</comment><comment><USER59> And then there's USB-C, which is an attempt to cram all the ports on the back of a desktop into one tiny connector. It has USB! It has HDMI! It sometimes has DisplayPort! Maybe audio, too! It has power! In both directions, even! Sometimes it even has JTAG, but we don't talk about that.

How does all this interact with UCB 3.2?

<comment><USER60> Good luck finding a cable that supports what you want. It might only be a matter of time before we have to have chips in the cable to indicate what it can and cannot do!

</comment></comment><comment><USER61> You thought USB-C was going to solve all your problems?

But they need a new reason to sell you more cables, dongles, and adapters.

Maybe they can call the next one USB 5G! That not only helps confuse the branding even more, but . . . It worked for AT&T.</comment>


Opa Gangnam Style - <AUTHOR> http://opa.io/gangnam.style.html

<comment><USER2> That's cute, but your loop stutters. If you're going to loop a sample, make sure you understand musical time first.

</comment><comment><USER3> Here is the actual home page when you've gotten the joke: <http://opalang.org/index.html>

</comment><comment><USER4> Why is this news? What's funny about this? Seems like marketing bullshit to me...

</comment><comment><USER5> Somehow our viral marketing campaign went beyond expectations :-)

</comment><comment><USER6> I wonder if they have the appropriate licence to do this kind of things... Especially in France...

</comment><comment><USER7> "Opa" is the german word for grandpa, this makes reading about The Opa Framework somewhat funny..

</comment><comment><USER8> That's cute and everything, but it's "Oppan."

Not "Oppa" nor "Opa."

<comment><USER9> Do you think it's worth to rename the framework?

</comment></comment><comment><USER10> *Oppa

</comment><comment><USER11> Would someone care to explain why Gangnam Style has become such a meme that tech startups are tempted to reuse it for marketing purposes? I mean I listened to the original song on Youtube and it didn't strike me as particularly worthy of listening to again and again, let alone bringing it up in conversations with other people.

<comment><USER12> Because it's popular, so it gets clicks. It's popular because it's the fad of the moment. It's a fad because it snowballed. It snowballed because something has to be snowballing, as people want to pay attention to _something_ , and they want to do that as part of a group. _This_ is that something because it's cute, nicely produced, vaguely edgy but not threatening to anyone, and it got lucky.

<comment><USER13> >> because it's cute, nicely produced, vaguely edgy but not threatening to anyone, and it got lucky.

Are we talking about iOS games now?</comment></comment></comment>