The Next Step for Generics - ainar-g https://blog.golang.org/generics-next-step <comment><USER2> Looks like a big step in the right direction. The biggest pain is that methods cannot contain additional types, which prevents the definition of generic containers with a map method like

        func (c Container(T)) Map(transform(type V)(T) V) Container(V)

if you want to see what `Result(T)` and `Option(T)` look like under this proposal, check out a very stupid implementation here [https://go2goplay.golang.org/p/dYth- AQ0Fru](https://go2goplay.golang.org/p/dYth-AQ0Fru) It's definitely more annoying.

But, as per [https://go.googlesource.com/proposal/+/refs/heads/master/des...](https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft- type-parameters.md#methods-may-not-take-additional-type-arguments) it looks like maybe they will allow additional type parameters in methods, which would be REALLY nice.

<comment><USER3> There's no need to use the pointer in there; you could just use an ok bool instead (saving the indirection): [https://go2goplay.golang.org/p/4hr8zINfRym](https://go2goplay.golang.org/p/4hr8zINfRym)

I think it's interesting to observe that using the Result type is really not that much different from using a multiple return value - it's actually worse in some ways because you end up using "Unwrap" which can panic.

<comment><USER2> I like your solution, although it's a tradeoff when the value type is some kind of nested struct whose zero value could be expensive to create.

Agreed that multiple return is actually quite nice in many situations, although `Unwrap()` is generally only called after checking `OK()` and the real benefit is in using `Map()`.

        a, err := DoCalculation()
        if err != nil {
          return err;
        }
        b, err := Transform(a)
        if err != nil {
          return err;
        }

is a lot more verbose and harder to read than

        a := DoCalculation()
        b := ResultMap(a, Transform)

<comment><USER4> I happened upon this comment a bit late, and caveat I'm not really a software engineer, but this comment made me think of something...

I've written a decent amount of code professionally in the first and second styles.

I sincerely prefer the second style, for reasons that are hard to articulate, maybe the aesthetic, the space, or something that I assume is equally as questionable.

After I stopped writing a lot of code, when I got pulled back in to debug or provide context long after the fact, in both cases, it was way easier in "real" code bases, to catch myself back up on things in the case that the code was of style 1, than when it was of style 2!

I may be alone in this sentiment, and I even regret that I have it.

I think there is also a bit of satisfaction in writing the code in the second example, especially when the example is a lot more complex than the one provided here.

Maybe it comes down to how much re-reading/maintenance your codebase actually needs. I wonder if coding convention/style has been mapped to the types of problems that code creates and the subsequent repair of those problems being dependent on the code style... I'm sure if I google it I'll find something :)

</comment></comment></comment></comment><comment><USER5> I like generics for collections but that is about it. I've seen "gifted" programmers turn everything into generic classes and functions which then makes it very difficult for anyone else to figure out what is going on.

One reason I like go is it doesn't have all the bells and whistles that give too many choices.

<comment><USER6> What's wrong with this?

      class Result<T>
      {
        bool IsSuccess {get; set;}
        string Message {get; set;}
        T Data {get; set;}
      }

On many occasions, I like using result types for defining a standard response for calls. It's typed and success / fail can be handled as a cross-cutting concern.

<comment><USER7> That's a generic container of 0 or 1 elements ;)

It's also incredibly unsafe and why generics aren't enough. C++, Java, and so on have had generics for ages and with types like the one above, null pointer exceptions are incredibly common. Nothing prevents the user from attempting to retrieve the data without first retrieving the success status.

On the other hand, this improves on it dramatically:

        enum Result<T, E> {
          Success(T),
          Failure(E)
        }

<comment><USER8> > It's also incredibly unsafe and why generics aren't enough. C++, Java, and > so on have had generics for ages and with types like the one above, null > pointer exceptions are incredibly common.

uh, you'd never get a null-pointer exception in C++ given the type that OP mentioned. Value types in C++ cannot be null (and most things are value types by a large margin).

<comment><USER7> Then you can't construct it unless it's successful, no?

A Result<T> that can only contain successful values doesn't seem very useful

<comment><USER9> No, you just are forced to use methods like foo.UnwrapOr(default_value) to get the Result. Or depending on the language, you get a compile error if you don't handle both possible values of the Result enum in a switch statement or if/else clause.

See for example [https://doc.rust- lang.org/std/result/enum.Result.html#method...](https://doc.rust- lang.org/std/result/enum.Result.html#method.unwrap_or_default) in rust, [https://docs.oracle.com/javase/8/docs/api/java/util/Optional...](https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html#orElse-T-) in Java, and [https://en.cppreference.com/w/cpp/utility/optional/value_or](https://en.cppreference.com/w/cpp/utility/optional/value_or) in C++.

<comment><USER7> Who are you replying to? Is any of your elaboration related to this result type?

        class Result<T>
        {
          bool IsSuccess {get; set;}
          string Message {get; set;}
          T Data {get; set;}
        }

<comment><USER9> Ah you're quite correct.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> I cant help feeling it is a missed opportunity to add generics to Go this late. A mistake that is copied from earlier languages (C++, Java), a mistake similar to other mistakes Go chose not to solve at it's inception, like: having implicit nulls (C, C++, Java, JS, C#), lack of proper sum types (C, C++, Java, JS) and only one blessed concurrency model (JS).

While I think I get the reasons for these decision in theory, make a simple- to-fully-understand language that compiles blazingly fast, I still feel it's a pity (most) these issues where not addressed.

<comment><USER11> > having implicit nulls (C, C++, Java, JS, C#),

> lack of proper sum types (C, C++, Java, JS)

Incidentally, Java and C# have addressed (or are in the process of addressing) both issues. Both languages/platforms are superior to golang in almost every conceivable way.

<comment><USER12> I'm not aware of any current Java project on Sum types. There is multi-catch for exceptions but no immediate plans I know to use elsewhere.

<comment><USER13> Java aren't fixing nulls, IMHO. They are making it worse.

<comment><USER11> How are they making it worse?

In any case, there already exist solutions in place:

[https://checkerframework.org/manual/#example- use](https://checkerframework.org/manual/#example-use)

[https://github.com/uber/NullAway](https://github.com/uber/NullAway)

<comment><USER13> The code ends up looking like:

      Optional<Integer> foo;

      //....

      if (foo != null) {
          foo.and_then(new Consumer () {
                function accept(Integer foo) {

                }
          });
      }

<comment><USER12> I would never assign null to an Optional nor use a library that returned one.

To ensure assignment before use make it final.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> This looks like a good, minimal implementation of generics. It's mostly parameterized types. Go already had parameterized types, but only the built- ins - maps and channels. Like this.

        var v chan int

Somewhat surprisingly, the new generic types use a different syntax:

        var v Vector(int)

Do you now write

        v := Vector(int)

or

        v := make(Vector(int))

Not sure. The built-in generics now seem more special than they need to be. This is how languages acquire cruft.

The solution to parameterized types which reference built-in operators is similarly minimal. You can't define the built in operators for new types. That's probably a good thing. Operator overloading for non-mathematical purposes seldom ends well.

They stopped before the template system became Turing-complete (I think) which prevents people from getting carried away and trying to write programs that run at compile time.

Overall, code written with this should be readable. C++ templates have reached the "you are not supposed to understand this" point. Don't need to go there again.

<comment><USER15> Presumably you write

        v := Vector(int){}

Or

        v := make(Vector(int))

Just like with unparameterized types.

</comment></comment><comment><USER16> Maybe it's because I'm a newcomer to Go, but I'm surprised by all of the shade being thrown in the comments here. I think the design doc presents a clean and simple way to implement generics in Go -- and therefore it's very much in keeping with the spirit Go. I especially like the constraints system. Constraining generic types via interfaces just feels "right" for the language. It leans on a familiar mechanism with just enough leverage.

I'm not without concerns, but I'm struck by conflicting thoughts: I share the worry that implementing generics will negatively affect Go program readability which Go developers (rightfully) covet; when you have a hammer, everything looks like a nail. And yet, I also worry that the Go community is at risk of analysis paralysis on iterating the language in meaningful ways; the novel and innovative spirit that created Go must be harnessed to propel it into the future, lest it dies on the vine.

</comment><comment><USER17> Finally. Better late than never. I have to write a lot of Go code at $BIGCORP and keep reaching for generic helper functions like Keys or Map or Filter or Contains. This is going to make my code much more readable.

<comment><USER18> Will it really?

Old:

      sum := 0
      for _, x := range xs {
          sum += xs
      }

New:

      slices.Reduce(xs, 0, func(i, j int) int {
          return i + j
      })

<comment><USER19> That's the most compelling example you could come up with as someone who presumably writes Go?

Reversing a slice of T. Copy and pasting this:

        for i := len(a)/2 - 1; i >= 0; i-- {
            opp := len(a) - 1 - <AUTHOR>
            a[i], a[opp] = a[opp], a[i]
        }

New:

        reverse(a)

Or generic versions of these: [https://gobyexample.com/collection- functions](https://gobyexample.com/collection-functions)

<comment><USER17> Yep, this is exactly the use case I was talking about.

</comment></comment></comment></comment><comment><USER20> Here's a four-line replacement for the various `sql.Null*` types in the standard library.

        type Null(type T) struct {
            Val   T
            Valid bool // Valid is true if Val is not NULL
        }

Here's what it looks like in practice: [https://go2goplay.golang.org/p/Qj8MqYWWAc3](https://go2goplay.golang.org/p/Qj8MqYWWAc3)

<comment><USER21> Nice. But I need to retrain myself to read Go code again, because

      func Make(type T)(v T) Null(T) {
      }

looks really confusing and unreadable to me - too many brackets...

<comment><USER22> I agree. I assume they avoided the standard <> brackets to keep things simple, but really it just makes it harder to parse visually.

<comment><USER23> I consider the parens () syntax much more readable than the brackets < >

<comment><USER21> Well, you can try to craft a generic function that returns a function that takes T and returns something of type T, and see how many () you gotta get...

</comment></comment></comment></comment></comment><comment><USER24> I am glad contracts are being dropped. It was very confusing indeed. Thanks for listening to the community.

<comment><USER25> Just the concept name is dropped, the concept itself is still there.

</comment></comment><comment><USER26> Unlike other commenters, I don't think it's too late to add generics to Go. I'm looking forward to this.

My only negative reaction is that throughout these proposals, I've not been a fan of the additional parentheses needed for this syntax. I can think of several syntaxes that would be more readable, potentially at the expense of verbosity.

<comment><USER27> You just can't please everyone.

I think that there are benefits when taking the time to gather feedback from people who actually use the language and make educated decisions with regards to language features instead of shoving them down in v1.

</comment></comment><comment> ainar-g Link to the current draft:

[https://go.googlesource.com/proposal/+/refs/heads/master/des...](https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft- type-parameters.md)

<comment><USER28> _"A type parameter with the comparable constraint accepts as a type argument any comparable type. It permits the use of == and != with values of that type parameter"_

I think that's an unfortunate choice. Quite a few other languages use the term _equatable_ for that, and have _comparable_ for types that have =, ≤ and similar defined. Using _comparable_ here closes the door for adding that later.

I also find it unfortunate that they chose

      type SignedInteger interface {
        type int, int8, int16, int32, int64
      }

as that means other libraries cannot extend the set of types satisfying the constraint.

One couldn't, for example, have one's biginteger class reuse a generic _gcd_ or _lcm_ function.

<comment><USER29> Languages have been known to use "Ordered", "Orderable", or "Ord" for what you're calling "comparable". Rust and Haskell are both languages that fit this criteria.

The design draft refers to "constraints.Ordered", so they're definitely thinking about having both "comparable" and "constraints.Ordered". Although, for consistency with "comparable", I think it should be called "constraints.Orderable".

<comment><USER28> That's true, but both rust ([https://doc.rust- lang.org/beta/std/cmp/trait.Eq.html](https://doc.rust- lang.org/beta/std/cmp/trait.Eq.html)) and Haskell ([https://hackage.haskell.org/package/base-126.96.36.199/docs/Data-...](https://hackage.haskell.org/package/base-220.127.116.11/docs/Data- Eq.html#t:Eq)) use _eq_ or similar for what this proposal calls _comparable_ , as do C# ( _IEquatable_ ), java (through _Object.equals_ ), and Swift ( _Equatable_ )

<comment><USER29> Sure, but as someone else already pointed out, "comparable" is an established Go term that refers to "==" and "!=" only, and "ordered" refers to the other comparison operators.

My point was that "comparable" is _not_ universally used in place of the "Ordered" term that the Go team is using, as you were seemingly implying. Ordered is a perfectly fine term for it.

You said:

> Using comparable here closes the door for adding that later.

But the door is not closed in any way. It's just called "constraints.Ordered", which is perfectly reasonable.

</comment></comment></comment></comment></comment><comment><USER30> In my mind, this generics flip-flop will do no good for the long term survival of Golang. One way to view it is as "listening to the community and changing" but I think a change this big signals a fracture more than an evolution.

Think about how much planning and foresight goes into making a programming language, especially one that comes out of a massive top-tier tech company like Google. They deliberately chose not to include generics and (from what I remember when I wrote Go code) spent time + effort explaining away the need for them. Now the decision is being reversed, and it signals to me that they don't know what they're doing with the language, long term. As a developer, why do I want to hitch my carts to a language whose core visions are very clearly not correct or what people want?

<comment><USER31> Or alternatively, they took forever to do it not because they don't like generics, but because they are super conservative with design and wanted to do it right.

<comment><USER32> Is there anything about this proposal that would have been surprising to someone 5 years ago? Anything to show for waiting most of the decade other than a decade lost?

<comment><USER33> Judging past work by the "obviousness" of the final solution is shallow, juvenile, and dismissive. Every problem is easy when viewed through the lens of of a nearly-complete solution. There have been a wide variety of _published_ proposals for generics in Go [1], each of which seemed plausible but had some insufficiency. Who knows how many proposals were conceived but never left the developer's machine.

If it's so damn obvious/you're so brilliant where's _your_ proposal dated Jun 2010 (your 'decade lost') that "solves" generics?

[1]: [https://github.com/golang/go/issues/15292](https://github.com/golang/go/issues/15292)

</comment></comment></comment></comment><comment><USER34> There's a tension in languages between making it easier to write many layers of libraries versus making it easier to write applications.

Languages that want libraries that go ten layers deep need to carefully manage things with sophisticated type systems and compilers that can cut through and inline all the abstractions so it still runs fast. Think rust, C++, haskell (all of which, not by coincidence, have long compile times).

Languages for writing applications and solving problems tend to have a flatter dependency tree and wider standard library (often including practical functionality like JSON parsers). Think erlang, Perl, PHP.

I used to think Go was in the latter category, but it seems to be getting pulled into the former category. Perhaps that's a reflection of Go developers using more layers of abstraction than they have in the past?

<comment><USER35> Go benefits from a continuous flattening phenomenon due to how interfaces and types interact. The determination of whether a type implements an interface is done at the interface use site rather than the type declaration site (as in C#, Java, etc.)

I don't think Go developers are using more layers of abstraction than they have in the past; they aren't smarter or more sophisticated than they were before -- RAFT was written in Go, for example.

Your observation is a good one, however; are there other ways that Go idiomatically flattens type hierarchies?

<comment><USER34> "they aren't smarter or more sophisticated than they were before"

To be clear, I was not suggesting that more layers of abstraction reflect more sophisticated _developers_. Just that more layers require something in the language to help developers manage those layers without going insane.

There's a lot of wisdom in choosing a flatter approach when it makes sense.

<comment><USER35> In your opinion, what languages do have effective tools for managing high towers of abstraction? I'm genuinely curious, having spent many nights building ontologies.

<comment><USER34> C++ and Rust come to mind. C++ can certainly go awry, but it does seem to have the tools available, even if they might be hard to use. Rust still has a few things to prove, but things are looking fairly good. Both languages can express constraints (e.g. type constraints) so that you don't have to make too many assumptions, and you know when APIs change in subtle ways. And both languages use inlining heavily to get "zero cost abstractions".

I'll include ruby as well. It doesn't have a lot of "tools" per se, but if you're working on a nice codebase, it works out well even if using a lot of gems. Part of this is probably the unit testing/mocking, and part of it is that the code is just smaller. It does _nothing_ to help you with performance though, so it can get really bad.

My experience with Java has not been great. I'm unconvinced that inheritance hierarchies are a good idea at all, or much of the other ceremony around Java- style OOP. Java uses JIT compilation, which can help with performance a lot.

If by "ontology" you mean "hierarchy", I'd caution you against that approach. Hierarchies enforce an order that is just not there in many cases. For instance, if you have an iPhone, would that be Hardware/Apple/iPhone or Apple/Hardware/iPhone? An iPhone is both Apple and Hardware, but there is no real order to those two -- yet if you try to put them in a hierarchy, then you must choose (and the choice _will_ matter). I think interfaces/traits are much better. Both Go and Rust got this right.

<comment><USER35> Good insights. Sorry, when I said "ontology", I was referring to the Web Ontology Language (OWL).

</comment></comment></comment></comment></comment></comment><comment><USER36> Neat, thrown together Set implementation [https://go2goplay.golang.org/p/FffAhV8aLyN](https://go2goplay.golang.org/p/FffAhV8aLyN)

<comment><USER29> Might as well use the zero-size struct{} instead of bool, given that you're not currently using the bool values for anything: [https://go2goplay.golang.org/p/9iegVQ2VQCr](https://go2goplay.golang.org/p/9iegVQ2VQCr)

Alternatively, use the bool values and rely on the zero value for missing elements: [https://go2goplay.golang.org/p/E7yHQqAPseG](https://go2goplay.golang.org/p/E7yHQqAPseG)

<comment><USER37> And variadic args to NewSet looks a bit nicer yet at the call site: [https://go2goplay.golang.org/p/fTp3W9IwuVP](https://go2goplay.golang.org/p/fTp3W9IwuVP)

<comment><USER38> Is there a way to do this without losing range?

<comment><USER29> The proposal is, for better or worse, quite clear about not providing operator overloading or anything similar in the near future.

You could always offer a method that returns a slice of unique elements, which could then be ranged over.

<comment><USER39> I don't think there's nearly as much of an appetite for operator overloading as there is for an iterator protocol for range. That isn't to say that the latter wouldn't have a lot to argue over (internal vs. external, etc.) but I think the general usefulness of such a thing would be widely accepted by the community once generics are a settled matter, while I doubt that will ever happen for operator overloading.

</comment></comment></comment></comment></comment></comment><comment><USER40> Currently I just want some form of genericity, regardless which one, but I fear we will go through yet another cycle of community feedback and by August 2021 still not there.

However not to be just negative, I will certainly take the opportunity to provide my positive feedback as well, so looking forward to play with go2go.

<comment><USER41> I'm sympathetic to being somewhat impatient; I'd really like to have generics in Go years ago too. But I'm also glad they didn't just plow ahead with the first draft of the proposal that came out; the way contracts worked was horrible, and the slow deliberative process means that we don't actually have to deal with those mistakes. Unfortunately, good design takes time.

<comment><USER15> Me too. A bad generics implementation is profoundly worse than no implementation at all. This angers people who have minimal experience with Go and it certainly seems counterintuitive until you understand that the way the community writes their code affects your experience whether it's just a different paradigm or a conflagration of paradigms, whether it's a little abstraction or gratuitous abstraction, etc.

</comment></comment></comment><comment><USER42> Prefer no generics in Go. Like Go simplicity. Don't want all languages to merge into single grey good form. Want strong trade-offs made.

<comment><USER43> Why use many words when few do?

<comment><USER44> For one, everyone isn't fluent in English. I guess it could also be a low bandwidth input situation.

<comment><USER45> I'm pretty sure shpongled is just quoting Kevin from The Office: [https://www.youtube.com/watch?v=VvPaEsuz- tY](https://www.youtube.com/watch?v=VvPaEsuz-tY)

<comment><USER46> longer version: [https://www.youtube.com/watch?v=_K-L9uhsBLM](https://www.youtube.com/watch?v=_K-L9uhsBLM)

</comment></comment></comment></comment></comment><comment><USER47> It looks like this will make Go a significantly more complex language.

Despite Go's success over the last 10+ years, have its designers concluded that the language is _too simple_? Is there no place for a simple statically- typed language like current versions of Go?

If not, then for those of us who particularly want a simple language, is dynamic typing the only option?

<comment><USER39> This is a very conservative, simple implementation of generics. The vast majority of its impact will be to make the code devs deal with on a day-to-day basis simpler to use. It will reduce the necessity for parts of Go that are already complicated, like go gen and reflection.

</comment></comment><comment><USER48> The only time I get frustrated by the lack of generics in go in trying to get keys from a map... I can't have a single `keys(map[string]T) []string` function.

<comment><USER49> Well, you can :) [https://play.golang.org/p/sum21uSy1Ae](https://play.golang.org/p/sum21uSy1Ae)

<comment> grey-area For certain values of can.

<comment><USER49> Never said it was a good idea. It's inefficient, unsafe and hard to read but, as far as I can tell any generic function with concrete return types can be written using reflect (and any generic function with generic return types can be written also, it just requires the caller to manually cast from an interface{} to the correct type).

So, that's an interesting thing.

</comment></comment></comment></comment><comment><USER50> Ada language had generics since the first 1983 standard. When C++ came about it introduced OOP features that Ada lacked and didn't get for another 12 years when 1995 standard was introduced. C++ users never missed generics for many years and the language became ubiquitous while Ada remained marginalized. What's interesting is that all strongly typed languages have now jumped on the generics bandwagon, which to me shows that being ahead of its time doesn't pay off.

<comment><USER51> The first edition of Stroustrup is the only version without templates (and exceptions). I remember awful macro workarounds for C++ compilers with broken template support, so I think everyone knew that some kind of generics were obviously needed. Ada got this and a few other things right, but it was painfully verbose and the first compilers were so expensive that few seriously evaluated it.

<comment><USER51> If I had to pick a language that got nearly everything right and shouldn't have failed, it'd be Eiffel. But it was also priced more like a truck than a tool until too late (at a time when programmers didn't generally cost six figures!)

</comment></comment></comment><comment><USER52> Typical to Go verbose style, but even that is better than nothing (example from the doc)

        s := []int{1, 2, 3}
        floats := slices.Map(s, func(i int) float64 { return float64(i) })

        Type inference for generic function arguments
        This is a feature we are not suggesting now, but could consider for later versions of the language.

</comment><comment><USER46> This is really sad, generics add a ton of complexity and get abused over and over in many codebases. Sure if you have a competent team then you can stop the bleeding, but it'll be all over the place in your dependencies.

Every developer who discovers generics has this urge to be clever and write things that are hard to read and maintain.

Reading a Go codebase on the other hand is really a pleasure, this is due to the simplicity and straight-to-the-point aspect of the language, as well as the compile times. I really think Go had found a no-bullshit niche that it catered really well to, and I'm scared of what Go post-generics will look like.

Are there any other languages like Go that have no plans to move to generics?

PS: beautiful quote from rob pike: [https://news.ycombinator.com/item?id=6821389](https://news.ycombinator.com/item?id=6821389)

<comment><USER53> "My late friend Alain Fournier once told me that he considered the lowest form of academic work to be taxonomy"

That's really unfortunate. I think a lot of the point of science (maybe even the entire point?) is to model the world and create taxonomies. Instead of being considered "busy work" or tedious, it should be held in the highest regard. Similar reasoning is why I think Rob Pike's opinion on generics is exactly wrong.

<comment><USER39> I actually had never read that Rob Pike quote and it's really baffling to me. It's not about generics at all! It's hard not to read it as saying "generics are recommended to me by the same weirdos who like inheritance, and I don't like inheritance, so generics are BS too".

</comment></comment></comment><comment><USER54> This saddens me :( as a reviewer of code I found Golang to be extremely easy to read due to the lack of expressiveness. The most secure codebases I've seen are all in Golang (or are written by strong engineers).

</comment><comment><USER55> While I've learned to work without generics, this is a welcome proposal. Many cases where we've been forced to use interface{} + cast could be genercized.

</comment><comment><USER56> Is there a reason Go is not using <> instead of ()?

So instead of

func Print(type T)(s []T) { for _, v := range s { fmt.Print(v) } }

we would get

func Print<T>(s []T) { for _, v := range s { fmt.Print(v) } }

?

<comment><USER57> The angle brackets increase parsing complexity because `>` is a valid standalone operator (which neither ] nor ) is, usually) making the grammar ambiguous: given

        Foo<Bar>

You still don't know whether this is a bunch of comparisons or a parametric type, meaning you need either feedback from the type checker into the parser or possibly unbounded lookahead before you can even generate a parse tree.

</comment></comment><comment><USER58> The anti-generics folks in the Go community are pretty prevalent still-- meanwhile the Go community frequently lauds Go's strong type system. I suppose it's _possible_ that these aren't the same people, but it seems more likely to me that many Go users don't know the difference between strong types and static types, and think that all static types are strong types.

Without generics, Go _does not_ have a strong type system. It has a type system that verifies just enough to force you to work around it to do things that require generics, meaning that you don't get the benefits of verification because you've worked around it. You get the development speed of a statically-typed language with the type guarantees of a weakly-typed language: the worst of both worlds.

</comment><comment><USER59> A litmus test I'm excited about is writing a less clunky linear algebra / numerical optimisation package.

Gonum is good, but it can feel like a lot of the powerful abstractions in numpy and Eigen are difficult to replicate.

Whilst numpy and Eigen do "turn the magic up to 11" just a bit too much for my liking, I do like the idea of things like this:

        interface Scalar() {
            type float float32 int int32 int64
        }

        type DenseMatrix(type T Scalar) [][]T

        func Identity(type T Scalar)(int size) DenseMatrix(T)

etc.

</comment><comment><USER60> > Second, we know that many people have said that Go needs generics, but we > don't necessarily know exactly what that means.

Seems like the go authors are still bent on the idea that generics are really not necessarily and that there is no such problem that can only be solved by generics. Then is the generic drafting only a thing because they have been pressured into it by the community? I wonder why Rob Pike one day decided that it's okay to change a language he almost vowed to never change after the initial release.

<comment><USER61> What's funny is that the stdlib makes extensive use of generics

<comment><USER62> "For me and not for thee"

</comment></comment></comment><comment><USER63> This is going to give rise to a utility-belt of sorts, which is what I'm really looking forward to. There are many collections and common utilities that we've all been hand-writing for a while (e.g. waiting for Set(string) instead of map[string]struct{}, or a TreeMap(string, Thing) instead of maintaining sort order separate or using reflection for an existing lib).

> Methods may not take additional type arguments

While I can fathom the complications that arise, I'm hoping they can work past this restriction by launch.

</comment><comment><USER64> I wish they would just add macros instead and then you can effectively code generate at compile time any specific generic-ness that is needed.

<comment><USER41> Macros are not a substitute for parametric polymorphism ("generics"). With lisp-style macros you could easily implement something like C++ templates, but that's different in at least one critical way: with C++ templates, the templates are expanded _before_ typechecking, whereas with proper generics, typechecking happens while the type parameters are still opaque. The former has several disadvantages:

\- It gets you really garbage error messages, because the type errors are usually about something in the body of the template, wherever it tries to do something that the type you substituted doesn't support, rather at the offending call site.

\- It hurts compile times (above and beyond proper generics), since you need to type check the generic function at every call site, rather than just once.

\- It makes it easy to break interfaces, because exactly what is required of a type parameter isn't written down anywhere -- it's just whatever the body tries to do with it.

(Though it is also true that generics are certainly not a full substitute for macros. I would welcome some mechanism for doing codegen that didn't complicate the build system and was a bit lighter weight than what we have now).

<comment><USER65> C++ templates are not expanded before type checking. Template instantiation is type driven. In fact you can even conditionally expand a template on whether an arbitrary expression typechecks. You wouldn't be able to do it if templates were a different phase.

Only early extremely non conforming compilers had macro-like template expansion.

Edit: although calling templates type level macros wouldn't be completely wrong.

Edit2: a better definition is that templates are type level functions: they take compile time values, types and other type functions and return values, types and type level functions.

<comment><USER41> Fair enough; I suppose I was oversimplifying. I think the broader point I was trying to make (in addition to the specific downsides I mentioned) still holds though.

The Template Haskell paper has some interesting things to say on the nature of C++ templates:

[https://www.microsoft.com/en-us/research/wp- content/uploads/...](https://www.microsoft.com/en-us/research/wp- content/uploads/2016/02/meta-haskell.pdf)

</comment></comment></comment></comment><comment><USER66> Rob Pike is not mentioned in the blogpost or in the sources the authors acknowledge as contributors to this project.

What is he up to nowadays?

<comment> ainar-g He still commits code and responds to Github issues occasionally, and I think it's safe to assume that he's still participating in the internal discussions about the design. But most decisions about language changes these days are made by Russ Cox, Ian Lance Taylor, and Robert Griesemer. At least, that's the impression I'm getting.

<comment><USER66> That jives with this article I found:

[https://evrone.com/rob-pike-interview](https://evrone.com/rob-pike-interview)

> Rob: Although it's far from certain, after over a decade of work it looks > like a design for parametric polymorphism, what is colloquially but > misleadingly called generics, is coming in the next year or two. It was a > very hard problem to find a design that works within the existing language > and feels as if it belongs, but Ian Taylor invested a phenomenal amount of > energy into the problem and it looks like the answer is now in reach.

Sounds like he took a welcomed step back. Hopefully the new leaders can deliver.

<comment> grey-area Ian Lance Taylor has been involved in the language for a long time, since 2008. Here he is talking about the built-in function append and why it shouldn't really exist in 2017

[https://www.airs.com/blog/archives/559](https://www.airs.com/blog/archives/559)

</comment></comment></comment></comment><comment><USER67> The draft design document is very readable too: [https://go.googlesource.com/proposal/+/refs/heads/master/des...](https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft- type-parameters.md)

I'm rather excited..

</comment><comment><USER68> I like this, here's a Sum function that supports all number types:

[https://go2goplay.golang.org/p/hPDnvRa- Bif](https://go2goplay.golang.org/p/hPDnvRa-Bif)

</comment><comment><USER69> Now the abstract sequence type of "LINQ in Go" [https://github.com/nukata/linq-in-go](https://github.com/nukata/linq-in-go) can be written as

      type Enumerator(type T) func(yield func(element T))

and the "Select" method can be written as

      func (loop Enumerator(T)) Select(f func(T) T) Enumerator(T) {
            return func(yield func(T)) {
                    loop(func(element T) {
                            value := f(element)
                            yield(value)
                    })
            }
      }

You can call this method with type-safety as follows. Yay!

      func main() {
            squares := Range(1, 3).Select(func(x int) int { return x * x })
            squares(func(num int) {
                    fmt.Println(num)
            })
      }
      // Output:
      // 1
      // 4
      // 9

See [https://go2goplay.golang.org/p/b0ugT68QAy2](https://go2goplay.golang.org/p/b0ugT68QAy2) for the complete code.

And, for generality, you should write the method actually as follows.

      func (loop Enumerator(T)) Select(type R)(f func(T) R) Enumerator(R) {
            return func(yield func(R)) {
                    loop(func(element T) {
                            value := f(element)
                            yield(value)
                    })
            }
      }

However, you will get the error message then:

      type checking failed for main
      prog.go2:17:33: methods cannot have type parameters

According to [https://go.googlesource.com/proposal/+/refs/heads/master/des...](https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft- type-parameters.md#methods-may-not-take-additional-type-arguments) this seems an intended restriction:

> Although methods of a generic type may use the type's parameters, methods > may not themselves have additional type parameters. Where it would be useful > to add type arguments to a method, people will have to write a suitably > parameterized top-level function.

> This is not a fundamental restriction but it complicates the language > specification and the implementation.

For now, we have to write it as [https://go2goplay.golang.org/p/mGOx3SWiFXq](https://go2goplay.golang.org/p/mGOx3SWiFXq) and I feel it rather inelegant. _Good grief_

</comment><comment><USER70> The "we still can't abstract over zero values" section is only really solvable with ad hoc polymorphism (type classes)

</comment><comment><USER56> Can `Option(type Value)` and some sort of `option.Unwrap` now totally replace `(value, error)` and `err != nil` checks? :D

</comment><comment><USER71> What a joke. Go devs spent a decade telling people they were waiting for the right design for Generics to emerge. Finally after a decade they deliver to us... Java-lite generics which are going to require the community to do a massive library ecosystem retooling for next five to ten years similar to how Java felt going from pre 1.5 to 1.5 and beyond.

This language is such a frustrating mess at times.

<comment><USER26> I'm not sure what you expected. With the exception of Ian Lance Taylor, the Go team has expressed skepticism (and, in the case of Rob Pike, outright disdain) about generics since day one.

To anyone who has followed the Go development process at all, this proposal will not be a surprise. The previous proposal was also extremely conservative. Personally, I don't see any other way. Going full-blown generics in the style of Rust/Haskell/OCaml, for example, would drastically alter the language.

This is closer in scope to, say, Modula-3.

<comment><USER71> I'm more frustrated that it took a decade to get to this point. Not that it is not more powerful.

</comment></comment></comment><comment><USER72> I've been writing a lot of Rust lately after writing Go for 7 years now (unrelated, but that is incredibly odd for me to write out. It still feels like that funny new language that came out of Google). I've always said that generics is overhyped (in Go), but I find that I write a lot of generic stuff in Rust that is somewhat surprising. For example we have a JSON API that returns data in the format '{"ok": bool, "data":...}'. In Go I might do something with json.RawMessage and pay for decoding twice, or annotate every struct with Ok/Data. But in Rust I can just have a type ApiResponse<T>. Then I can have functions that operate just on ApiResponse, or ApiResponse<T=Users>. This problem is solvable in Go, but in a different way and with less guarantees. However that power comes at a mental cost, that creeps in C++ as well. I spent more time playing type system golf trying to come up with the optimal type for whatever usecase. In Go I might just "do the work", but in Rust I've turned 5 minute functions into 30 minute api design thought exercises. The jury is out if thats is a good thing or a bad thing.

That said, the only feature I'd steal from Rust is sum types and getting rid of null. `nil` interfaces are the only language feature to actually cost me money and Option<T> is just better in every aspect, and Result<T> is much better than err == nil. I'd be perfectly happy with compiler blessed Option and Result types even if the larger language didn't support generics.

<comment><USER73> Do we have a name yet for the internet phenomenon where every time Go is discussed, Rust must be immediately brought into the conversation, and vice versa?

<comment><USER74> It shouldn't be that surprising. Both are "low-level" languages that came onto the scene around the same time, are highly opinionated, but stake out very different points on the design space.

If you start talking about changing the recipe for Coca-Cola, surely Pepsi is going to enter the discussion at some point, right?

<comment><USER75> This doesn't explain the obsession with Rust.

Fitting analogy: If there's an article about McDonald's, people would always talk about Wendy's instead. No one would mention BurgerKing (C++), Subway (D), KFC, ...

<comment><USER76> I wouldn't say that I'm obsessed with Rust. However, it's the sort of language I've wanted essentially since I started programming: a Haskell/OCaml-like language with the sheer performance and practicality of C++.

I've been a long-time user of Haskell, but I can safely say Rust has supplanted it almost entirely for me at this point. I never would have felt comfortable betting on Haskell in a commercial environment. Rust? Absolutely.

<comment><USER77> Can you expand on why you would not bet on Haskell for commercial work? What are those things that make Rust suitable for it but not Haskell in your opinion?

</comment></comment></comment></comment></comment></comment><comment><USER78> I won't use GO until they add generics. Hopefully they'll add them someday. I can wait as long as it takes.

</comment><comment><USER79> I feel like Go lost its chance by being way too slow to innovate. From my circle of people who I remember were extremely excited about Go when it first came out - no one really uses it anymore. In our circle it has become a "meh" language. Heck Apple Swift on server is way more exciting than Go these days.

<comment><USER80> It isn't supposed to be an exciting language. It specifically not fancy. Great for teams. Forced style consistency. Clear expectations. Difficult to mis-read compared to most others. Terse, almost rude.

<comment> enahs-sf There is a lot of beauty in go's simplicity. Very straightforward to reason about what's going on.

I find it much easier on the eyes than java.</comment></comment></comment>


AnyWall: an iOS geolocation app powered by Parse complete with tutorial - <AUTHOR> https://parse.com/anywall <comment><USER2> Facebook makes a trademark claim on the word "Wall". While I personally think that's ridiculous, I'm betting they're not going to be happy with that name.

</comment><comment><USER3> Congrats, the app is cool and is a great example of how cool the Parse platform is. You can build really nice Apps very fast with a great backend.

</comment><comment><USER4> Nice. I've been impressed with the tutorials that Parse has been putting out - keep 'em coming!

<comment><USER5> thanks!

</comment></comment><comment><USER6> I was planning on creating the same thing in the near future. Looking at the comments now, it seems my idea was certainly not the first of its kind :)

Glad to see the different things Parse can do. I'll be using it sooner or later!

<comment><USER7> Same, this has been a side project of mine too. It must be a good idea!

</comment></comment><comment><USER5> we actually coded this up before Caterina Fake's Pinwheel launched, but the idea is similar. see <https://pinwheel.com/>

<comment><USER8> Or you could use Stashpix, and post pictures too:

<http://stashpix.com>

<comment><USER5> also cool, but anywall is open-source and we built it for the sake of making a fun iOS tutorial

<comment><USER9> Kudos for open sourcing it!</comment></comment></comment></comment>


Europe's Philosophy of Failure (what schools teach about economics) - <AUTHOR> http://www.foreignpolicy.com/story/cms.php?story_id=4095

<comment><USER2> That's a very silly article, and it smacks of envy. How dare socialist Europe have countries much wealthier than the United States? How dare its socialised healthcare provide better healthcare? If that's failure, then give me more of it. The dirty little secret is that capitalism is wonderful only in a limited dose. If not tempered, it runs amok and causes more sickness than it cures. Europe recognizes that, and that's what is taught in schools: the truth.

<comment><AUTHOR> Europe really isn't socialist, at least not the wealthy countries here. Just because there is a law for public health insurance, doesn't make a country socialist.

Also, the "socialist health care system" is currently falling apart, at least in Germany. I think the democrats have a new scheme for such a system in the US, if they win? I say good luck getting it right. I am no specialist for it, but as an amateur I keep thinking about it, and I see no way: if the state pays for health treatments, people will get as many health treatments as they can, until the system breaks up. Our system here was put in action when Germany had lots of spare money. If times get harder, suddenly it doesn't seem so viable anymore.

Actually in Germany it is not completely socialist, the system is run by insurances, but most people are legally obliged to be insured. And the insurance companies are obliged to insure those people, which causes the problems (so I have to pay for people who smoke or have accidents in high risk sports activities and so on). What can they do? Somehow try to make a catalog of useful health treatments, but that also is doomed. More and more useful treatments get excluded.

The other extreme is what I experienced in england, where it really is the state directly who pays the bills. So you might have to wait a couple of days if you break your arm before you get treatment - whatever, right? Oh, and if you need dialysis, the machines will just be switched off when you reach a certain age. Whatever, right?

So welcome to the socialist health system, have fun!

<comment><USER2> > Europe really isn't socialist, at least not the wealthy countries here.

Norway and Sweden are tremendously socialist, and Norway is the wealthiest country in the world.

> Just because there is a law for public health insurance, doesn't make a > country socialist.

Of course, it's always a mix and calling something socialist is maybe over the top, as is calling America capitalistic even though it has social programs such as Medicare, Welfare and Social Security. But please look at Sweden, for example, and tell me that I'm wrong in calling it socialist. It's a wonderful example of how socialism can work.

You mention Germany and England; both have superior healthcare (measure on many different scales) to the United States. The facts seem to disagree with you. As for what makes it socialist: While people are supposed to have insurance, everyone is by default insured and no one can lose their house, for example, from medical bills.

> I keep thinking about it, and I see no way

Germany has had the same healthcare system for over a hundred years, through hyperinflation and two world wars. Again, the facts disagree with you.</comment></comment></comment>


Ask HN: Bored at my dev job. Don't know what to do - <AUTHOR>

I've been working at this company as a developer for a few months right after graduating. Company is great, it has many perks, and people there are great. But I am just bored doing stuff that I do. At the end of the day I just come home and realize that I did absolutely nothing useful. I just want to feel alive or something when I am trying to solve something interesting and important, like applying some algorithm to solve some problem (like in uni assignments), or just believing in something that could make an impact on the world (like developing my hobby projects, but I haven't had any new ideas in months). I can't really quit, because I have no social skills to find a new job, especially something really good and interesting. I have no ideas on my own (if I had something I believed in, I would quit the next day). I am in UK now. And I believe I am a quite good developer, been developing since 13 years old. What should I do? Days just seem to pass so fast because of this boredom and monotony and it seems I am wasting my time doing nothing... I am 23. I don't care about money, I don't even care that much about working overtime, I have so much energy, I want to help change the world or make an impact on it, or at least have a slight chance doing that. <comment><USER2> I think when you're a developer across a product, it can seem like you're just building features / fixing bugs with no real human connection to the "why" of your actions.

I don't know if you can ask your management, but as a total outlier solution, you could try to spend some time listening to CS calls that come in. You didn't even have to participate on the call, just listen.

Ive found this greatly increases motivation as you actually start to see the need of why you're doing what you're doing. Most products / businesses are not really going to change the world that much, but hearing how something you built is actually helping someone's life can be very rewarding.

</comment><comment><USER3> Your are in a great position. You have a stable source of income and a prestigious job title for the modern times.

You already kind of seem to know the solution: Work on your social skills.

Read this [http://www.amazon.com/How-Win-Friends-Influence- People/dp/06...](http://www.amazon.com/How-Win-Friends-Influence- People/dp/0671027034)

Sign up for internet dating and go on dates with strangers. You will soon discover everyone is awkward and it is all okay.

Or go to tech meetups. Ask people about themselves and just listen to what people have to say. People love to talk about themselves and you can learn a lot about them and yourself.

It will be hard It will be awkward It will feel really strange at first

But being really good at connecting with other people is vital to getting the jobs you want. Having hard skills is important too, but you seem to already have those.

Good luck.

</comment><comment><USER4> Quoting verbatim from jlcfly's excellent advice from another AskHN:

"Teach them to be better than you. That may seem counterproductive. I have a type A personality, and I have decent coding skills. I've been in your situation a number of times. I also know there's these mythical expert developers out there that I can't seem to find (or afford). So, what to do? A few years ago I realized that if I continue down this path, I'll end up with some serious health issues due to the stresses that come along with having a reputation for being a really good developer. So, I decided that instead of searching for developers better than me, I would teach developers I work with how to BE better. It's taken a lot of patience. And it's taken me quite a bit to LET GO of my way of doing things. I had to take my ego out of the picture. (VERY hard to do.) Nowadays, I realize that developers don't have to BE better than me. I simply have to ALLOW them to do what they do without being so obsessive about it. Turns out, even junior developers really CAN do good work. They just need a little guidance that only comes with experience, and then they need me to get out of their way."

Specifically, I would suggest volunteering to teach those who traditionally don't get the opportunities to learn coding.

[https://news.ycombinator.com/item?id=8649415](https://news.ycombinator.com/item?id=8649415)

</comment><comment><USER5> You're describing nearly every job I've ever had. Here's how I coped with various instances.

1\. Left the job. 2\. Got involved in other teams' projects. 3\. Colluded with other employees to break off and form our own company. 4\. Accepted it and collected the paychecks (that dwarfed the combined amount of what my parents made at their peak salaries).

You're not going to get what you want out of your job unless you ask for it. If it isn't feasible or possible for your workplace to accommodate you, then that leads you to finding it outside of work. Like mentioned in other comments - there's open source and charity organizations that might need something. If you don't have ideas of your own, you might want to find a business type person and help solve his problems. However, that will likely be quite similar to what you're doing now.

Consider doing something other than programming as well, or something where the programming is secondary. I, frankly, have lost a lot of interest in programming itself because I've been programming since I was 6 (>30 years) and I've learned over a dozen programming languages since then. It's lost its lustre for me. Changing the focus to the non-programming part helped.

The last thing to consider is getting involved in a university project. Those generally have enough difficult programs without the time crunch involved in industry.

</comment><comment> Warewolf-ESB A lot of people feel this way, especially when they are developing on legacy systems or doing standard line of business apps.

I would suggest finding an open source project you are passionate about. There are some really cool open source software applications popping up that need passionate developers like you to get involved.

That's how you make an impact - get involved and do something that benefits the community, and that you can be proud to have put your name on!

It might not help so much with your day job, but it will certainly open up new opportunities for you, improve your skills and look great on your CV. Plus it's a lot of fun!

Do a search in GitHub, or if you program in C# come take a look at what we're doing (yes, you can change the world!): [https://github.com/Warewolf- ESB/Warewolf-ESB](https://github.com/Warewolf-ESB/Warewolf-ESB)

<comment><USER6> I'll add to that; if you program in C# and functional reactive programming on a single codebase across all native mobile phone platforms sounds of interest then take a look at [https://github.com/reactiveui/ReactiveUI](https://github.com/reactiveui/ReactiveUI) and send me an email. I'll get you up to speed / invited into Slack. Contact details are on my HN profile.

</comment></comment><comment><USER7> Your claims as I understand them:

1\. Lack of social skills.

2\. Lack of ideas what to do with your spare time (at least I see it this way).

3\. Lack of challenges and meaningful tasks in your current work.

The 1. is only a problem if you pay close attention to it and refuse to go out because of it.

The solution I see is to find a hackerspace (or similar association) nearby and just drop in to hang out with others. You'll get socialized, you'll find new areas you can look at and most probably it will give you an inspiration and new ideas, all at the same time.

This could solve your 1. and 2. problems pretty quickly, and in the long run, either 3. will become unimportant or you'll find a better job.

</comment><comment><USER8> Have you felt like this for long? If it's been months, then maybe a big change could be needed. Sometimes I get these lows for a few weeks, and it's almost more about _me_ than my job/surroundings. You may find your enthusiasm just gets reignited all on it's own.

In the meantime, start trying to think up ideas and write them down, even half baked ones. Idea generation is a muscle. At my peak I write down a new idea every few days. Sometimes that slips to once a month. Regardless, you'll find that if you start doing this, you start getting excited about those ideas which leads to....

...moving forward. Either to a new job, an open source project, learning a new skill set, approaching your boss with an idea, or a new geekup meeting or whatever.

</comment><comment><USER9> My advice would be as follows:

1) Take a deep breath and relax. What you are going through is normal. Your whole life up to a few months ago has basically been spent working towards this ultimate goal of getting a college degree. It is normal to feel a bit of a let down coming off this achievement high.

2) Realize that developing an elite skill set is the key to finding exciting and meaningful work. For more on this check out this book: [http://www.amazon.com/Good-They-Cant-Ignore- You/dp/145550912...](http://www.amazon.com/Good-They-Cant-Ignore- You/dp/1455509124)

3) Get to work honing your craft.

</comment><comment><USER10> I can understand you. If I were in your position, I would think I'm lucky to have a job, get a paycheck, buy things I want and get bored as well. There are many people who don't know whether they're gonna have a meal today, they don't know if they can get a job to pay their kids school fees and the list goes on .... enjoy being one of the lucky people on earth. Take your job as an opportunity to learn (good or bad things). If you don't like it, quit. Life is too short to waste ... make your decisions fast, Fail Early !!!

</comment><comment><USER11> Companies devote so much time, money, and energy to recruiting good engineers; but then dump them on projects which slowly suck their will to live. Ideally, a company should have as a mantra, "We will not bore you." If you have a lot of excess energy and time, why not enter a competition? For example, OpenCV is sponsoring a contest to improve the library in one of ten or so major areas. If you succeed, you could win a little cash, plus gain some cred for finding a more interesting job.

</comment><comment><USER12> Do something different.

What would you do if you knew you only had a year left to live, a month, week, day?

Get a remote job, travel the world. Join an exciting startup or start your own. Take a step back and think about the bigger picture, break the mundane system, you're in a unique space and time to do so. Do what makes you feel alive, if you don't know, experiment. Whatever you choose to do don't settle, you only get one chance...

<comment><USER13> I don't feel like the "what would you do if you had a year/week/day left to live" is a very useful question. If I had a day left to live, I'd try LSD, heroin and probably pick a fight with someone I didn't like, not try to learn a new technology.

<comment><USER14> You're sure you'd spend your last days being completely unlike you? Then maybe you aren't living that honest a life.

<comment><USER13> I'd spend my life as a person who re-evaluates priorities given new data.

I don't do heroin now because I would (likely) be trading decades of health and happiness for a temporary bliss, followed by crippling addiction and the loss of my family, friends, and job.

(Also, I beg HN not to let this thread turn into an argument about drug policy, responsible drug use, etc., etc. There are probably people out there who can use heroin responsibly; I almost certainly would not be one of them.)

</comment></comment></comment></comment><comment><USER15> Possible the best advice I can give for your current position is to get into the habit of starting and FINISHING personal projects. Doesn't matter if they're unique, or whether you think it can profitable, or whether you think anybody but yourself would use it. Do it anyway and make it a habit to finish. Then, when a good idea comes along that can change the world, you'll have practiced persistence.

</comment><comment><USER16> Your salary is now seed funding for your next startup ;)

<comment><USER17> This... 1000 times this. Use the opportunity to work on your social skills too but most importantly save money and figure out what's next. In the future it will let you take risks you otherwise could not like, for instance, trying changing the world for the better. If I had a time machine this is the number one piece of advice I would try to convince 23 year old me to follow. And sure, get involved in some open source thing perhaps too - it could help get you into a more interesting job down the road and expand your network.

</comment></comment><comment><USER18> Find someone who is doing something that interests you. Find them at meeting of an interest group, or at a school, or by reading about them, or by learning the name of a person who works at company, club, or non-profit that interests you.

Send them an email introducing yourself. Explain why you are interested in what they are doing. Explain what your skills are. Offer to help.

</comment><comment><USER19> If you are bored of your job first figure out what interests and motivates you. Maybe you are in the wrong profession? Zubair, NemCV.com

</comment><comment><USER20> get involved in some interesting open source community, and more specifically in a popular project.

this will do two things - one, it will let you write code that keeps you engaged, without needing to come up with ideas for something to write from scratch, and two, working on a large and active project with multiple contributors, mailing list, irc channel, etc. will be helpful with social skills (at least as far as interacting with other developers goes) and might even act as a form of networking (i've seen several job posts made directly to community mailing lists, especially if the job is for a non-mainstream language or framework).

if you can list some of the things you've found fun or exciting to work with in the past, we can help make more specific suggestions of areas to explore.

</comment><comment><USER21> Learn new skills, both technical and biz. On the biz side, learn product management, project management, Agile, scrum, etc. Play with new tools and try out new things. And yeah, welcome to the real world kid :-)

</comment><comment><USER22> Let me know if you want to work for our team in Dublin! We build distributed databases - pretty much as high tech as it can get :)</comment>


Warning: RoR is slow - <AUTHOR>

<comment><USER2> How can you so blindly proclaim something like this? In a world of systems programming I got used to people posting stack traces with milliseconds attached to each function call, complaining about something _specific_. A good example would be GNU glibc's printf() function checking system locale on every call.

Have you ever done any programming before?

Your claim _Active Record is slow_ sounds almost like _my computer is slow_. How do you know it was ActiveRecord? How did you benchmark? Was it even RoR? Maybe you had another process spinning in an endless loop in the background eating your CPU.

<comment><AUTHOR> maybe because i've time-profiled it? maybe because i've calculated the time it took to instantiate a new AR object for every new db record? maybe because the results show that the AR component took the largest portion of the page loading time?

<comment><USER3> Your original post doesn't mention any of this. I think it would help everyone understand your point a lot better if you posted a few specifics...

</comment></comment></comment><comment><AUTHOR> First of all, i don't wish to try to start a flame war. Just want to share some of my experience with RoR.

RoR, to me, is the pinnacle of web programming orgasm. It's fun, it's fast, it's super productive. Hell, i never enjoyed web programming till i tried RoR.

Unfortunately, RoR is slow, or specifically ActiveRecord is slow. No matter how many machines you throw at your app, there is still a noticeable page loading time lag compared to a straightforward PHP script. People hate it. Yes. They do. Users will complain and the only way you can improve the loading time drastically is if you stop using ActiveRecord. But heck, half of the joy in using RoR is with ActiveRecord. Either that or you cache page fragments. But trust me, caching page fragments is not fun. You need to keep track of which fragments to invalidate based on which model actions. Multiply that with many models and you get the same PHP messiness.

So what's my point? My point is that i'm looking for a new FAST mini-framework to replace RoR. Any recommendations :)?

<comment><USER4> What name are you submitting patches for AR under (I'm not finding any under your username here, [http://dev.rubyonrails.org/search?q=keiretsu&wiki;=on&changeset;=on&ticket;=on)](http://dev.rubyonrails.org/search?q=keiretsu&wiki=on&changeset=on&ticket=on\)) ? I'd like to check some of them out to see what your doing. I'm assuming your not just complaining about a free open source project and that your actually doing something about it, since just complaining is pretty bad for your karma.

<comment><USER5> It's no longer okay to complain? If I didn't like something, I'd prefer to complain and not use it than waste my time fixing something I find fundamentally flawed.

<comment><USER4> No, It's not ok to just go around complaining. If you don't like it, that's fine, don't use it, but to just go around posting completely unproven slander about a completely free project is another matter completely.

I love that there are some people here that seem to think they are entitled to something or that 37s or DHH owes you something. It's open source, you have 3 options: 1\. Fix it and get kudos. 2\. Don't fix it (because your either too dumb or too lazy) and work around it. 3\. Don't use it.

But coming on here and making some generalized proclamation that RoR is slow is irresponsible and unacceptable, IMO.

</comment></comment></comment></comment><comment><USER6> Unless you've really got a Ruby fetish, there's just not much of a reason to use it.

If you want a similar language with similar productivity, Python gives you that and speed, Unicode support at the language level, and lots of libraries.

And in web frameworks alone you've got Django, Pylons, Turbogears, web.py, etc. Django has the community and 'push' that Rails does in the Ruby world, and Pylons feels a lot like Rails. So what are you waiting for? Checking them out can't hurt anything.

<comment><USER7> I tried Python; didn't care for it. Something just didn't click.

Later on I tried Ruby, and it was a better fit for my head.

There are differences in the underlying design principles of Ruby and Python, and they can make a big difference in how well you internalize the language.

I also took a look at Django, and it struck me as astonishingly clunky compared to Rails and Nitro.

There are issues of aesthetics at play; I can't argue that my taste is right or wrong, but it certainly matters that I use a tool that aligns with it.

<comment><AUTHOR> yeah. i agree. tried python. the language is really _ugly_ compared to ruby. django just doesn't fit into my brain like RoR does.

<comment><USER8> I think that once you get past the whitespace dependence, python is an incredibly elegant language. No strange variable prefixes, functions as primary data, readable syntax, etc etc. And, if you come from the land of C/Java/C++, it has quicker transition than ruby (IMHO)

</comment></comment></comment></comment><comment><USER9> Hrm most of the posts here show little understanding of Rails. Rendering, not AR is behind most complaints of "slowness". If you want to speed up rendering, limit the amount of redundant Javascript that gets generated, statically generate links, don't generate SQL (eager load) and cache where needed.

<comment><USER10> No. As someone who runs a site w/ more than half a million hits a day at times, rails is butt slow. We memcache up the wazoo as well as make other optimizations.

Not only is it slow but there are memory leaks too.

I hope they fix alot of this. We went w/ rails b/c of the elegance, but paid for being on the bleeding edge.

<comment><USER11> Can you share the URL of your site?

Just curious - what are your plans going forward?

i.e. continue what you've been doing, rewrite in another language, or what?

Not that this is your scenario, but whenever I'm in a crunch situation, it always feels like the grass is always greener. When you get to the other side... well, you know how it goes.

<comment><USER10> Unfortunately I can't b/c of some reasons I'd be happy to share later. I know it sounds like a copout, but really, I'd be in trouble if I mentioned it now.

Upper mgmt is making us rewrite it in java. (shoot self). It has more to do with what they are comfortable with long term and what the company runs and has the know-how to support.

If I had to do it over again, I'd look at Python more carefully. Django was barely out when we started so we were a bit leery of it. In addition, I didn't have a great impression of Python from doing some toy programs in it. I really liked Ruby's elegance.

Overall, I don't think we would've chosen Java above what we have, warts and all. Java is too verbose and RoR let us be extremely flexible and fast when it mattered.

Outside of upper management intervention, we'd probably have continued down the ruby path and gambled on the fact that things would be fixed/better in a few years.

I feel for twitter, but they're really doing a service for the rest of the RoR community by being the pioneer for extreme scaling issues.

</comment></comment></comment></comment><comment><USER12> I've moved to Django, huge performance difference. Also a simpler stack, apache + mod_python vs the nginx + mongrel or apache/lighttpd + fcgi or etc....

</comment><comment><USER13> To be fair, the current implement of Ruby (1.8x) is slow because it does not compile source code to byte code and run in vm, which will be available in next version (2.0?). Python, on other hand, already use this for a long time.

So, just stick to it and wait if you like the beauty keyword "end" and dislike white space vs tab war.

</comment><comment><USER14> Ruby and RoR, slow? This is a no-brainer. Ruby is slow as molasses and RoR is built upon Ruby. Hmmmmm....

<comment><USER15> The implementation of JRuby should fix this concern.

</comment></comment><comment><USER16> Something to look into: I don't know if any of you guys went to RailsConf, but one of the goals of Rails 2.0 is to improve AR through the caching of repeated queries at the AR object level.

<comment><AUTHOR> I've already done this. Got a minor speed bump. You have to understand that the majority of the page loading time is in the instantiation of the AR object, not from fetching the db result. At least that's my experience in my app.

</comment></comment><comment><USER17> There are a lot of valuable comments here.

If I had to summarize what I think is the likely problem, I would say: look into pre-fetching where it makes sense. Databases are often troublesome beasts, and you have to do more management of the data than you would like.</comment>


Job Search Mastery in 9 Steps - <AUTHOR> https://medium.com/@lumen/job-search-mastery-in-9-steps-a4cc6f296be9 <comment><USER2> [https://hn.algolia.com/?query=Job%20Search%20Mastery%20in%20...](https://hn.algolia.com/?query=Job%20Search%20Mastery%20in%209%20Steps&sort=byDate&dateRange=all&type=story&storyText=false&prefix&page=0)</comment>


Ask HN: What happened to older submissions on HN (only about 500 are visible)? - <AUTHOR> Since last week I noticed that I can only view about 500 last submissions on HN.  From front page pressing "More" at the bottom, right now, the last page I can access is page 17 [1].  The viewable submissions list is growing a little: few days ago the last page I could access was page 14.  Few months ago I could easily access page 30 or further (I have never encountered a "last page" where there would be no "More" link).<p>So, is HN experiencing some technical difficulties, and once they are resolved everything will be back as before?  Or this is a permanent thing from now on?<p>[1] https://news.ycombinator.com/news?p=17 <comment><USER2> We have been making several changes that affect this, with more to come. Keep in mind that /news represents _ranked_ stories, and that the ranking algorithm loses precision over time, so later pages become less meaningful. If you would like to see all recent story submissions, /newest currently displays at least 3000 (around 4 days).</comment>


Tips for launching a startup while holding a day job - <AUTHOR> http://entrepreneur.venturebeat.com/2010/03/24/6-critical-tips-for-launching-a-startup-while-holding-a-day-job

<comment><USER2> The point about not using your day job's resources is important. Not only could you lose you day job, but your side project as well. Many times when you start working at an organization, they have you sign an agreement saying something like "We own everything that is produced on our machines, network, etc."

<comment><USER3> I lock my MacBook that I use to work on several side projects on my train commute to my work desk and plug it in to recharge it. I don't open up the lid. Is it ok to use the electricity (it's not the network)?

<comment><USER4> Buy a second battery and you'll never have to find out.

<comment><USER3> Doing that. Thanks.

</comment></comment></comment></comment><comment><USER5> I agree with everything beside the point "You can't afford to hire three developers to add features and bugs.". You actual can, it just require a little of a financial sacrifice for you. Hiring my first employee was the best thing I ever done, especially when he can work during hours you normally can't.

<comment><USER6> I would think that depends on that employee's autonomy. They could hit a roadblock that they need you to clear, but you're unavailable.

</comment></comment><comment><USER7> I have found that the easiest way to keep my day job and startup separate is to have a separate laptop for both so that I'm not tempted to work on startup tasks on the company's computer while on the clock or off. Not too difficult to do during the day but it can be during the off hours when the company's laptop is better than your own.

I think the harder issue is trying to avoid answering emails that are startup related while on the clock. Even if it's webmail they still own the internet at work.

<comment><USER3> The grey area is using 3G and a smartphone for side project email.

<comment><USER8> I don't think there's a grey area at all. You're still on the company's time whether you write support emails or are on the phone doing a deal.

I wonder if there's any grey area with regard to working during a lunch break.

<comment><USER9> Could you just track the time deducted from the company's time, and put in the extra half hour or so?

</comment></comment></comment></comment><comment><USER10> On a related note, is it okay to pick up skills related to your side project at work? For example, if my side project is building a application in Clojure, is it okay to learn about Clojure at work? Of course, not at the expense of getting actual work work done, but there's always time between builds, etc. So instead of playing Foosball or surfing the internet, can one actually do something more productive, even though it's unrelated to the current work you are doing?

<comment><USER11> IANAL, but I think there's pretty strong precedent that the employer can't assume ownership over any non-proprietary information you learn (languages, design patterns) at work.

Of course, we live in a proto-fascist state where legal combat is often won by those with the most money, so it'd be dangerous to assume that past sane decisions will carry into the future.

<comment><USER9> I don't think companies can own knowledge, mainly because it is physically impossible. Once they figure out how to remove knowledge from the mind, then maybe they can.

</comment></comment></comment><comment><USER12> From a legal point of view, this is actually really good advice. It adequately stresses the importance of making really, really sure that you are not bound by any anti-compete or IP clauses or what have you, or get released from them by your employer. To non-legal people, the advised measures may seem ridiculous; let me assure you, they are not. They are well within the minimum you need to do.

For your startup, it's not about if the courts will, after several months or even years, uphold your IP rights. It's about ever getting sued and game over.

<comment><USER11> Stupid question: if your startup gets sued over something like this, why not have the company declare bankruptcy, dissolve it, and start a new company in the same idea with some of the same employees? (If you have investors who'd get burned in this process, tell them that they can avoid this fate if they commit sufficient resources to win the lawsuit; if they do, then this is the best possibility.)

It seems like it wouldn't be that hard to hide enough in the way of resources (relationships, ideas) to get a good start on Act 2. You'd lose your office and a few months of salary, and need to find new investors, but this doesn't seem as severe as "game over".

It seems like 85% of startup time is figuring out what works and what doesn't, so you can "kill" the code (i.e. shunt it out of view, and then use it as a reference in a comprehensive rewrite, possibly in a different language so there's no doubt as to your new code being yours) and your cost is only the 15% of the time necessary to implement the ideas that you now know will work.

<comment><USER13> Because the lawsuit would include you, the defendant, personally, and not just your shell company?

[quick legal advice: if a trick sounds too easy, it probably won't hold in court]

<comment><USER11> _Because the lawsuit would include you, the defendant, personally, and not just your shell company?_

I don't know if this would work, having never had to do it, and it's extremely unlikely that I ever will, but then I'd hire someone to put severe pressure on decision-makers at the plantiff and make it very clear that they don't want to dance this way. Hiring a "pro negotiator" of this sort is expensive, but cheaper than losing a company, a livelihood, and having future wages garnished.

When legal action becomes unaffordable and favors the rich, people will resort to illegal action. And I don't fear death enough that I'd let someone disrespect me in such a way without taking his own fall.

 _[quick legal advice: if a trick sounds too easy, it probably won't hold in court]_

This I doubt, given that the vast majority of white-collar crime never leads to an indictment, and the penalties are so minor relative to the rewards that it persists in spades. (This is not to say I'd advise white-collar crime, the vast majority of which is utterly unethical and dishonorable scumbaggery. I'm only saying that the vast majority of criminals in our society get away with it.)

</comment></comment></comment></comment><comment><USER6> More discussion over at the original link from Jason's blog: <http://news.ycombinator.com/item?id=1175416>

</comment><comment><USER14> So I have a friend (it could be true) considering starting a business on the side and he agrees with all of these points. After reading this article, however, he realized that he did sign some type of agreement saying anything he does is property of the company, even if it was at home. At the time he wondered whether this was normal, but as it was the standard company contract, he signed it.

How should he handle this situation?

<comment><USER15> Talk to a lawyer familiar with those issues in your state. It depends on what he signed and your state's laws. No matter what, it's still best to disclose it to his employer, just like this article suggests and patio11 also suggests: [http://www.kalzumeus.com/2010/03/20/running-a-software- busin...](http://www.kalzumeus.com/2010/03/20/running-a-software-business- on-5-hours-a-week/)

</comment></comment><comment><USER16> What if I am a developer in the day job, but I don't code for the the startup, and the technology we use is totally different from my employer, will there be a IP concern?

<comment><USER17> As the article points out, you just can't work on your startup while at work at your day job. So if you're not answering emails, blogging, coding, testing, whatever, than you should be fine :-) Also check your non compete, some employers get a little crazy about it and may try to claim ownership of anything you do, even in your off time. Of course IANAL.

</comment></comment><comment><USER18> This is a repost of Jason's post from his blog. Here's the HN discussion on that post. <http://news.ycombinator.com/item?id=1175416>

</comment><comment><USER19> Number one thing that should be on the list - find a co-founder!</comment>


Why Your Links Need a Hover Effect - <AUTHOR> http://uxmovement.com/buttons/why-your-links-need-a-hover-effect/ <comment><USER2> Your links need to NOT have a hover effect if they interfere with the ability to see (or _click on_ ) underlying content. Stubhub is horrendously bad in this respect -- in their zeal to hover a (meaningless) average price for a section at you, they make it impossible to click on that section.</comment>


Spring Hadoop 1.0.0.M1 seems to have a bug... - <AUTHOR> http://ramblingsoullt.blogspot.com/2012/03/spring-hadoop-100m1-seems-to-have-bug.html

<comment><AUTHOR> anybody else playing around with it ran into a similar issue?</comment>


Good Math, Bad Math - <AUTHOR> http://scienceblogs.com/goodmath/

<comment><USER2> I've been reading Mark Chu-Carrol's blog since i first seen it on news.myspace/mathematics. He is absolutely brilliant. He has a good style of teaching mathematics and mathematical concepts. I wish he would compile a book from the posts on his blog.</comment>


Bill Gates says it's time to redirect solar and wind subsidies. Is he right? - <AUTHOR> https://www.technologyreview.com/f/614331/bill-gates-says-its-time-to-redirect-solar-and-wind-subsidies-is-he-right/ <comment><USER2> He's been a big proponent of nuclear in the past. Does he still have a stake in TeraWave?</comment>


Walmart's new gaming PCs struggle with the basics - <AUTHOR> https://www.theverge.com/2018/12/10/18131156/walmart-gaming-pc-overpowered-17-plus-laptop-review <comment><USER2> At the end of the day, Walmart PC's are roughly about as good as you expect to get at Walmart: Cheap, and checking off the boxes, but not going above and beyond by any imagination.

You'll probably see a lot of them as parents' gifts to kids, who don't know what they're buying but just need something that runs Fortnite.

<comment><USER3> When they were first released they were not at all cheap, while being noticeably factually inferior to solutions from many other systems integrator's.

They did however adjust the pricing subsequently to be competitive price-wise however still with inferior components. So better than it was but still not great.

(the DTW3 is $2100) "Markup on this thing is completely insane, even for a system integrator. Incumbent competitors like iBUYPOWER offer an RTX 2080 and i7-9700K at a cheaper price of $1700, but also include brand-name PSUs, motherboards with Z-series chipsets, and 3200MHz memory in multiple slots. For the same price, Walmart uses unbranded PSUs without any efficiency ratings or certifications, 2400MHz garbage-bin RAM, and an H310 chipset with half the bus transfer speed as baseline. The Overpowered DTW3 and DTW1 (and presumably DTW2) are criminally incompetent in their components selection." Source: [https://www.gamersnexus.net/hwreviews/3401-walmart-gaming- pc...](https://www.gamersnexus.net/hwreviews/3401-walmart-gaming-pc- overpowered-dtw3-not-worth-it-review)

</comment></comment><comment><USER3> Gamer's Nexus did really great coverage on the PC tower versions. Both a written and video version: [https://www.gamersnexus.net/hwreviews/3401-walmart-gaming- pc...](https://www.gamersnexus.net/hwreviews/3401-walmart-gaming-pc- overpowered-dtw3-not-worth-it-review)

My favorite part is where he ordered (and paid for) the $2100 DTW3 but received the $1400 DTW1.

<comment><USER4> I think it's interesting that while people criticized the Great Wall PSU choice a lot, Gamers Nexus say it's "fine" for usage</comment></comment>


Rails is (still) a Ghetto  - <AUTHOR> http://www.rubyrailways.com/rails-is-still-a-ghetto/ <comment><USER2> From tfa: " _I hear you, dear creme-de-la-creme Rails (core) member, I know you don't give a shit, and you think this is all prude babbling - because your hourly rate is more than some of us earn in a day, and you'll be sought after even if Rails will have a much worse image than it has now. But 99.9% of us are not in the 'circle of trust' and would be happier if Rails would not be constantly associated with a ghetto._ "

I feel a lot of misplaced entitlement coming from that article. Open source developers build a framework and give it for free to other people. Other people use the fruits of their work and complain if the developers do non code-related stuff they don't agree with.

Besides, some people should watch some porn, just to know the difference between the images of the presentation and the label they give it. This isn't porn people.

The main issue I have with it that people go to a presentation that was titled "Perform like a P0rn Star" and afterwards "feel offended" or "uncomfortable". I just don't get that. If someone would say this in Europe the first reaction would be: "so why did you go and see it?" It's not like there isn't any other couchdb information on the net. There were also multiple other talks at this event at the same time slot.

I also understand the position of the core team. What if I write a code- framework and distribute it for free? Should I watch my words so I don't offend people, who might know some people who work with my code? This is just insane. Open source is a gift for everyone, and everybody is free (not) to use it.

</comment><comment><USER3> I'm not a rails developer but from an outsiders perspective, really who cares. And the people who are bothered remind me of the same people complaining of late night cable tv. The title of the seminar was called "Perform like a p0rn star"! That should be your first clue that it wasn't going to be the same dry stuff. It's not like they were rickrolled or anything. They gladly attended a seminar with pr0n prominently in the title and then get all offended with the imagery.

It would be like if vegetarian orders a meat lovers pizza and is devastated by what shows up.

</comment><comment><USER4> I think this points at a general problem with developers.

Developers assume that just because "it works" then non-code issues are irrelevant.

In truth, people choose frameworks and languages not just because of the code and career opportunities but also because of the community. This goes for developers _and_ management.

There is nothing wrong with that - software development is as social as any other human activity. A good community is helpful, welcoming and tolerant. Compare for example the Lisp and Python communities - Lisp has definitely been hurt by an elitist, unwelcoming community, whatever its technical merits.

After this presentation and related comments across the blogs, the Ruby/Rails community comes across as arrogant, sexist and immature (as do its leaders). This does a completely unnecessary disservice to the technology.

</comment><comment><USER5> Personally I have no problem with porn images in a presentation, but they are a bit distracting.

Nevertheless, professionally I would never pull a stunt like this, or even consider it because of the risk of offending someone. What makes it worse though is that the offender will not apologize or even try to see the other side of it, which is then magnified by the core team members backing him up on it.

<comment><USER6> _"professionally I would never pull a stunt like this, or even consider it because of the risk of offending someone."_

I find this a pretty craven position to take. You are always going to offend _someone_ unless you offer only the blandest of commentary. Do you really want to let your speech and actions be guided by the lowest common denominator?

 _"What makes it worse though is that the offender will not apologize"_

Because he feels he has nothing to apologise for? What do you want, a fake apology?

Hey, you didn't call me Sir. That offends me. Apologise.

 _"or even try to see the other side of it"_

There is a limit to how far you can go trying to "understand the other side". Sometimes the other side is just bullshit.

Imagine you give a talk about evolution. It "offends" some young-earth creationists. Are you really going to try to "see the other side"?

 _"which is then magnified by the core team members backing him up on it"_

Kudos to them, they didn't have to step into the ring, but I'm glad they did.

</comment></comment><comment><USER7> Could someone explain what the phrase "Rails is a Ghetto" means?

I know what a ghetto is, but don't really get what the implication is here.

<http://en.wikipedia.org/wiki/Ghetto>

<http://en.wiktionary.org/wiki/ghetto>

</comment><comment><USER8> Link to the presentation, only suggestive images, no explicit images or nudity. [http://www.slideshare.net/mattetti/couchdb-perform-like-a- pr...](http://www.slideshare.net/mattetti/couchdb-perform-like-a-pr0n-star)

</comment><comment><USER6> Give me a break. I have seen worse pictures on the side of a bus shelter.

Who cares if a couple of wowsers get their panties in a bunch? Society suffers when everyone has to tiptoe around some deranged minority's wacky list of things to be outraged about.

No-one important that I know about has left the community because of this or any other contrived pseudo-scandal. Rails' popularity has not waned; rather the opposite. I could not care less if a small number of easily-offended prudes are scared away by a mild show of skin. In fact, it seems like a good thing.

What was that PG said .. "offending the right people"? Sounds like the right people have been offended here.

<comment><USER9> | _I have seen worse pictures on the side of a bus shelter_

So? That makes it any less wrong?

| _Society suffers when everyone has to tiptoe around some deranged minority's wacky list of things to be outraged about_

Do you have evidence about this? I think that's quite the contrary. Surely free speech is important, having personally experienced the aftermath of a communist regime, and not being allowed calling a turd for what it is surely sucks. But this is a different story.

And I think that deranged minority you're speaking of are the women.

| _I could not care less if a small number of easily-offended prudes are scared away by a mild show of skin._

What ever happened to manners? Personally I don't care about looking professional. I don't like the term, because "professional" means working for money, and I happen to enjoy what I do.

But this isn't about being professional or not. This is about respecting other people. It's about showing courtesy to others, such that the others can do the same for you. I don't know in what society you live in, but I'm fed up with the racist, antisemitic and generally foul language in the one I live in. Maybe you've been spoiled? ;)

<comment><USER6> _"So? That makes it any less wrong?"_

No, it means that it is self-evidently common and of questionable "offence value". In other words, the burden is on you to prove wrongness, since it seems to be just fine everywhere else.

 _"I think that's quite the contrary."_

OK, let me get this straight. The contrary of what I said is:

 _Society prospers when everyone has to tiptoe around some deranged minority's wacky list of things to be outraged about._

Surely you are not seriously asserting the above. If you are, I can't be bothered arguing because you are either a troll or .. probably incapable of understanding no matter how much I explain. If you are not saying that, please restate.

 _"What ever happened to manners?"_

What has this got to do with manners!?

 _"This is about respecting other people. It's about showing courtesy to others, such that the others can do the same for you."_

I'm sorry pal but I have no idea what you are talking about. I do not see how this presentation had anything to do with "respect" or "courtesy". Of course I am in favour of those things.

No, this is about a small minority _choosing_ to find offence in the utterly mundane and then demanding heads roll to quench their self-righteous outrage. Fuck those people. Makes me _want_ to offend them.

 _"I don't know in what society you live in, but I'm fed up with the racist, antisemitic and generally foul language in the one I live in."_

Rather orthogonal to my original comment, don't you think? If you don't like where you live, maybe you should consider moving.</comment></comment></comment>