Pisces III: A dramatic underwater rescue - <AUTHOR> http://www.bbc.co.uk/news/magazine-23862359 <comment><USER2> It's amazing that, in the right context, curling up in a fetal position and remaining very quiet can seem heroic. I'm sure that Hollywood will add some embellishments in their retelling: [http://www.newsandstar.co.uk/news/jude- law-ewan-mcgregor-lin...](http://www.newsandstar.co.uk/news/jude-law-ewan- mcgregor-linked-to-cumbrian-man-s-sub-rescue-film-1.1081252)

</comment><comment><USER3> This is incredibly terrifying and at the same time a testament to mans desire to live and ingenuity to survive.

I wonder what OH&S would think about the situatin today.

<comment><USER4> This was in the 1970s, a time when there was a lot of pioneer work in subsea exploration and technology. Researchers and companies were really pushing the envelope of what was possible to do under water. OH&S today would give most companies an F for their safety procedures. A lot of workers died and suffered permanent injury during these years.

On the other hand, this was all unknown territory. A lot of the knowledge regarding safety under water hadn't been discovered yet. In contrast to the space exploration of the 1960s, the private companies exploring the sea bottom didn't have the budget to put safety first. Research into the biological effects of unfamiliar breathing gases and decompression was focused exclusively on survival, not long-term sustainability. Etc. Even governments were implicitly pushing for quick development, as large parts of this exploration was a gold rush. The judicial considerations about to whom resources belonged, were to a large extent determined by the technological capability to harvest them. An example is the oil pipeline from the North Sea to West Norway, which was built in terrain which was at the time "impossibly deep" to work in. For the Norwegian government, building this pipeline was a key move in getting the ability to sell their oil on the open market.

The modern notion of workplace safety was to a large extent developed during these years. In Europe, the Norwegian offshore unions and the then-new Law of Work Environments (Arbeidsmiljøloven) were instrumental in this development. Even today, these initiatives are among the most strict in the industrialized world when it comes to questions of workplace safety.

</comment></comment><comment><USER5> >I wasn't in the best condition anyway as I had just suffered three or four days food poisoning from a horrible meat and potato pie.

>"It turned out it was the Queen Elizabeth II, which had altered its course from America to stand station with us in response to the mayday. But because it was so formal, we'd assumed it was the Queen. Then the message came 'sorry boys, wrong lady'."

This is why I love reading/listening to the BBC.

</comment><comment><USER6> This article has a pretty good picture of what a Pisces submersible looks like:

[https://en.wikipedia.org/wiki/Pisces_class_DSV](https://en.wikipedia.org/wiki/Pisces_class_DSV)

And this reference from the above article shows a cut-away diagram of the vehicle, with people inside so you can get a sense of the size of the crew compartment:

[http://books.google.com/books?id=1X1hL2LFT0AC&pg=PA84&lpg=PA...](http://books.google.com/books?id=1X1hL2LFT0AC&pg=PA84&lpg=PA84&dq=rescue+of+Pisces+III+submarine&source=bl&ots=HM7zS7E4Eb&sig=Uv5Z3LxSvFt5x-sb9WsPuc48bLk&hl=en&ei=QV_2TM- sN9K1ngeu6ZijCQ&sa=X&oi=book_result&ct=result&resnum=1&ved=0CBYQ6AEwAA#v=onepage&q=rescue%20of%20Pisces%20III%20submarine&f=false)

</comment><comment><USER7> Do you really need a submersible to lay cable? Could be they have on an espionage mission to tap someone else's cable?

</comment><comment><USER8> > the men had only 12 minutes of oxygen left when they were finally rescued

Jesus, you seriously think we'd believe it's been 3 days then it goes down to 12 mins to death.

Life is not hollywood, please stop trying to make it that. It's kinda interesting as it is.

<comment><USER9> It's a direct quote from one of the survivors:

> _" We had 72 hours of life support when we started the dive so we managed to > eke out a further 12.5 hours. When we looked in the cylinder, we had 12 > minutes of oxygen left," says Chapman._

<comment><USER10> Sometimes unusual coincidences like that actually happen. Improbable doesn't mean impossible.

I'm reminded of the first time I watched Das Boot. I knew very little about the movie going in, aside from the fact that it was considered a classic. I enjoyed it a great deal, but thought they overdid it with some of the obviously artificial drama. Afterwards I was surprised to find that the stuff I thought was obviously fake had actually happened to the real submarine the story was based on.</comment></comment></comment>


Built a portfolio site — is it good? Feedback? - <AUTHOR> http://www.hunterhorsley.com/projects.html

<comment><USER2> Just negative feedback, i hope that is what you want ;-)

\- Clicking a video/slides breaks your navigation, perhaps a modal/dialog instead \- Try variation (text interchange left and right)

For the rest, yeah, like it :)

<comment><AUTHOR> Yup. Super helpful. Like the variation idea.

As far as the modal, could you point me to a tutorial on that if you know of one?</comment></comment>


A River of Warblers: 'the Greatest Birding Day of My Life' - <AUTHOR> https://www.nytimes.com/2018/05/31/science/warblers-canada-migration.html <comment><USER2> story about 700,000 warblers and the only picture is of a single warbler? Come on NYT!

<comment><USER3> Sorry for the amp article but this link has a video and some more information.

[https://www.google.com/amp/s/www.atlasobscura.com/articles/b...](https://www.google.com/amp/s/www.atlasobscura.com/articles/biggest- warbler-migration-tadoussac.amp)</comment></comment>


Three Months of Go, from a Haskeller's perspective (2016) - <AUTHOR> https://www.barrucadu.co.uk/posts/etc/2016-08-25-three-months-of-go.html <comment><USER3> I worked with Michael on the same project, after also working with Haskell previously. On the whole I agree with the pros/cons stated in the article. Having said that, my conclusion would be a bit different: I would err on the side of Go for the majority of commercial projects.

The article mentions the impressive worst case pause times of Go's GC. Since then we have performed some additional benchmarking. The conclusion was: it is impressive, but there are still a couple of issues that break the sub 1ms claims. We blogged about this here: [https://making.pusher.com/golangs-real- time-gc-in-theory-and...](https://making.pusher.com/golangs-real-time-gc-in- theory-and-practice/). It's hard to guarantee low latency in all cases...

Michael also mentions that there is nothing like ThreadScope, or at least nothing that's easy to find. The latter is true. There is an impressive runtime system event visualiser which can be opened with `go tool trace` [https://golang.org/cmd/trace/](https://golang.org/cmd/trace/). You can see a screenshot of this in the GC blog post I linked to above. Unfortunately the only documentation is this Google Doc: [https://docs.google.com/document/d/1FP5apqzBgr7ahCCgFO- yoVhk...](https://docs.google.com/document/d/1FP5apqzBgr7ahCCgFO- yoVhk4YZrNIDNf9RybngBc14/edit) which is tricky to find, and could be more in- depth.

I'm in the middle of writing a blog post on how to use this too. Watch out for it on our engineering blog in the next month or two. [https://making.pusher.com/](https://making.pusher.com/)

</comment><comment><USER4> It is, I think, going to be very difficult to enjoy writing code in a less powerful language when you are exposed to languages that hold awesome power.

In fact, this has been the basis for much writing on Lisp too. Paul Graham has written entire essays along the same lines.

If you work in a job that forces the use of a less powerful language than what you've been exposed to, you can, I think, go through a sort of depression. You simply long to use the tools that you know hold much more power yet must resign yourself to the tools you have.

You can overcome the problem by being present in your work. The language might be ugly. It might be totally underpowered with limited means of abstraction and a type system that snmacks you and, sometimes, your client over the head. What you can do is, despite that, commit to writing great software with the tools you have. Commit to improving your work. Perhaps expand the ecosystem with tools borne of insights from your adventures with high-powered tools.

You will have a much more enjoyable time in most languages this way. Perhaps except MUMPS but there might be hope.

<comment><USER5> I don't know how to ask this without it sounding offensive, and I don't intend it that way. But do these "hardcore" haskellers enjoy writing programs at all? Like are there any well known open source apps that people actually use written in Haskell? There are tons of hobbiests and it has a following but what are the examples of its greatness?

I ask as an old SML guy, I like the math theory, I like the promise of better, more accurate and reliable software, I think you can do some beautiful things with algebraic types but I've been dumbfounded by the lack of great examples out there. Ada suffered/suffers the same fate, it has this "academic" pedigree for robustness but not many examples that you can get your hands on. so much expressiveness that doesn't seem to result in much expression.

<comment><USER6> Haskell is actually less expressive. It is a functional abstraction on top of what is essentially a procedural machine and with all abstractions placed on top of lower layers you can only lose functionality as you go up rather than gain. You could say assembly language is the most expressive language out there.

The great thing about Haskell and other functional programming languages is that the functional style forces the program to be created in a form that is modular and elegant. Programs become modular and composable and re-composable in the functional world because the programmer has No Choice but to build his programs in an elegant way. It's hard to explain this to a typical programmer who hasn't dived deep into functional programming but code reuse, modularity and elegance are significantly higher in functional programming languages than in procedural.

This elegance, beauty and forced organization comes at a high cost though. And the cost is thinking in a way that is outside the normal paradigm of what humans are use to. I know a lot of haskellers think that humans can be taught to think in both ways equally, I disagree with them and believe that it is far Easier for a human to think about an algorithm procedurally than it is for him to think about it functionally.

If you have several tasks to execute, what is your first thought on how to plan out those tasks? A task list (aka list of functions) or a series of composed tasks placed in a single sentence (aka expression)? The answer is obvious: humans think about the list first because procedural programming comes more naturally.

This I believe is the main reason why Haskell or lisps haven't taken over the programming world. Functional programming is just HARDER. It takes me 10 times longer to hack out a simple program in haskell than it does in python because haskell doesn't allow you to 'hack' together a program. In haskell the application has to be an elegant diamond or the thing won't even compile! Python allows me to hack something together quickly which is both a good and a bad thing because as we all know hacking together software is quick but easily leads to unmaintainable software.

<comment><USER7> I don't understand the downvote. The main argument looks valid:

> If you have several tasks to execute, what is your first thought on how to > plan out those tasks? A task list (aka list of functions) or a series of > composed tasks placed in a single sentence (aka expression)? The answer is > obvious: humans think about the list first because procedural programming > comes more naturally. This I believe is the main reason why Haskell or lisps > haven't taken over the programming world.

<comment><USER8> It's overly simplistic. For example, Haskell's do notation allows asynchronous programming in a linear "task list" (to use your phrase). Yet most popular imperative programming languages do not; one must instead use callbacks.

As to whether programming with expressions is fundamentally harder, I'm not so sure. Since Fortran, most languages have supported arithmetic expressions over primitive numeric types, since they are certainly _not_ easier with an imperative approach (MOV, MOV, ADD, PUSH). Haskell allows one to easily take this further using arbitrary objects and algebras, for example, expressions with drawing primitives, parsing grammars, financial contracts etc. With a small amount of syntactic sugar, you can even make expressions that look exactly like imperative programming (Haskell's do notation).

<comment><USER8> Forgot to mention that I didn't downvote either, despite disagreeing with much of the post.

</comment></comment></comment></comment></comment></comment><comment><USER9> > Go is just too different to how I think: when I approach a programming > problem, I first think about the types and abstractions that will be useful; > I think about statically enforcing behaviour

I see statements like this a lot from Haskellers and I think its overstated. Anecdotally, after going from Python to spending 3-4 years in Haskell then going back to a dynamic language (Elixir) I've come to the conclusion that how you think when programming is very much a learned trait that works for that language. It's neither good or bad, but it's educational nonetheless. Haskell and other languages like it forces you to have a very unique mindset that can overpower previously learned languages not like it. And it's in no way permanent.

After I stopped using Haskell I was like "ugh, I need types! wth!". I wanted to go back to Haskell only out of familiarity, but as I continued after a short while I wasn't even thinking like that anymore. The thought rarely occurred. I stopped thinking in Haskell and started thinking in Elixir.

<comment><USER10> I cannot speak for Elixir, but coming from the Erlang world, I'm sure it's a fine language that has sane defaults, much like Clojure.

However I switched from Python to Scala and besides the performance issues and the poor handling of async I/O that I had with Python, by far the biggest problem with Python was all the _insecurity_ while developing with it. It drove me insane, because we had a production system that always had problems due to how poorly Python's ecosystem treats errors.

Just to give an example, at that time we were using BeautifulSoup to do HTML parsing, a library resembling JQuery, except that BeautifulSoup can return nulls all over the place and no matter how defensive I got in my coding, null pointer exceptions still happened. And what was the solution for async I/O in Python? Monkey patching the socket module by means of Gevent or Eventlet of course, which didn't work for native clients (e.g. MySQL's) and if this wasn't problematic enough, you had to _guess_ what worked or not and when. The worst kind of magic possible.

When I switched to Scala, all of these problems vanished. This isn't about having tests either, because tests only test for the behavior you can foresee, unless you do property-based testing with auto-generated random data and in this regard static languages like Scala and Haskell also rule due to the availability of QuickCheck / ScalaCheck.

You see, my Python codebase got really bad because of fear of refactoring. Yes, even with plenty of tests and good code coverage. Because actually the tests themselves became a barrier for refactoring, because in a language like Python there is no such thing as information hiding and coupled with dynamic typing, it means that your tests end up tightly coupled with implementation details, will break on correct refactoring and will be hard to fix.

Nowadays when I'm doing refactoring with Scala, most of the time it simply works as soon as the compiler is happy. Some people bitch and moan about that compiler being kind of slow and it is, but the things that it can prove about your code would require specialized and expensive tools for other languages and that wouldn't do such a good job.

Going back to dynamic languages, there are also languages like Clojure, which get by with _sane defaults_. For example in practice Clojure doesn't do OOP- style dynamic dispatching most of the time and functions are usually multi- variadic and capable of handling nil values gracefully. This is not enforced by the language, being simply a hygienic rule accepted by the community. However, relying on such conventions requires (a) capable developers that (b) agree on what the best practices should be.

And the issue that people miss when thinking of the merits of such languages is that _smaller communities are always homogeneous_. So when giving as example a language like Elixir, if it hasn't drove you insane yet, well, you have to take into account that Elixir might not be popular enough.

So basically I prefer strong static typing because I'm not smart enough or wise enough to seek and follow best practices as often as I'd like and because I don't have much faith that other people in the community can do that either, especially after that community grows. The biggest irony imo is that Python is right now the anti-thesis of TOOWTDI.

<comment><USER11>
      > because in a language like Python there is no such thing as
      > information hiding and coupled with dynamic typing, it
      > means that your tests end up tightly coupled with
      > implementation details, will break on correct refactoring
      > and will be hard to fix.

Would you mind to provide more details about this point? I thought dynamic languages make testing easier, because you don't care about the type of the object as long as it works with the same API (if it quacks…). This also supposedly makes it way easier to mock objects. Now there you are basically claiming (unless I misunderstand your claims) the opposite.

<comment><USER12> "Dynamic languages make testing easier," paints a very broad brush. They have some very nice benefits, but also a lot of edgecases.

* An argument might be an int when you expected a float. This can be addressed by casting things with `float()` in every entrypoint, but it's more defensive to require a float and error out otherwise. Either way, problems only appear at runtime. * An object might be null and this only gets picked up at runtime - using Rust it's been very nice to have to explicitly say when things can be null.

I've found it can feel like luck when a complex Python program works correctly for real-world input, but it's also very powerful at getting something done. Tradeoffs.

<comment><USER13> > An object might be null and this only gets picked up at runtime - using Rust > it's been very nice to have to explicitly say when things can be null.

This point actually frustrates me greatly about C# 7. At some point, there was talk about non-nullable references being introduced into the language, which has been put on hold for at least another version. Personally, I think that feature should have been in the language since version 1. Every runtime error due to a null reference is one too many.

<comment><USER14> I have thought about creating a template struct with a single member that blows up if you try to insert null. Something like this:

      public struct NotNull<T>
      {
        private readonly T val;
        public T Value {
          get { return val; }
        }
        public NotNull(T v)
        {
            if (v==null)
              throw new Exception();
            val = v;
        }
      }

However you can still create a class FOO with a member NotNull<T> xxx and xxx may be entirely uninitialized. It can be then passed from one method to another until you try to read it, so it basically does not give any guarantees.

I thinks this is why they pulled non-nullable types from C# - they couldn't figure out what to do in this case. If I were them I would force the constructor of FOO to blow up on exit if xxx is not populated. That would help a little bit. Although it still causes problems if a method is invoked from the constructor.

So yeah, it's a tough problem. Maybe they could add a check when a field of type NotNull<T> is read to throw an exception? That way you're still possibly in trouble when reading a field, but at least you can be confident that if you receive a method parameter NotNull<T> you know it's not null.

<comment><USER13> I also thought about solutions like this for a while, but frankly, every option sounds like the attempt to fix a leaking dam using duct tape.

Things like this have to be implemented properly. The problem is that this ties into the core architecture of the platform, not only the language - references are basically the most important implicit primitive there is in the CLR (implicit because not even the IL handles them like the other datatypes).

I'm not very informed on the subject, but I suspect that without a proper way to declare locals and members non-nullable in the CLR, the matter would get rather complicated - there'd be no possibility to communicate the requirement through method signatures, for example. And since you could call pretty much any C# method from other languages, I'd expect various problems there.

Of course, one option would be to only handle the initialization and assignment checks in the C# compiler (I guess that would be much easier) and simply generate conditional ArgumentNullExceptions in every method, but I suspect that this would be a problem for performance reasons.

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> I started out liking Go. It looked like a fairly pragmatic language. As I got deeper into my evaluation project (simple api stuff) it felt more and more like cutting wood with a dull saw.

I started out liking Haskell too! But has I moved along with my small evaluation api project it felt more and more like I was trying to cut wood with gyroscopic laser saw. It worked but it was a lot of fan fair for sawing some wood.

Picked up erlang/elixir. Looked pretty decent. Felt like cutting wood with a Japanese pull saw, so I had to use the vise clamps that came with it. It cut some fucking wood.

~ Ron Swanson out.

<comment><USER16> My impression of Elixir and Erlang are that they are the only dynamic languages I'm aware of that seem to have dynamic typing for solid technical reasons. Many languages are dynamic just for user experience reasons. But the way the BEAM VM handles hot code swapping, concurrency, and memory management, etc, required using a dynamic language. (As far as I'm aware?)

<comment><USER15> I think it's because of the built-in nature of message passing in the language. It's just easier to send around messages to processes. Hot code swapping would be possible with other JITed languages (BEAM isn't a JIT).

Also since erlang has excellent pattern matching (even on binary data!) and a supervisor system (OTP) errors are easy to recover from. Erlang takes a very pragmatic approach of building tools that deal with errors by recovering from them instead of trying to exhaustively trying to prevent them.

</comment></comment></comment><comment><USER17> I hate to sound like the rust evangelist strike force... I really do. But your complaints are exactly what it would solve... Sigh I hate to say this I really do. But here goes...

So have you checked out rust?

<comment><USER18> How robust/mature is it as of yet? More importantly, how are compile speeds and how much of a priority are they to the compiler maintainers? I too find it quite promising in terms of "a language aiming for the benefits of Go with the expressiveness and added easier correctness of FP".

But "promising" doesn't mean I'd replace the few use-cases where Go currently shines for me (wouldn't recommend it for any-and-all development at all, but there are select cases where I currently absolutely wouldn't use anything else) as these are those few programs where I really want to write (and later, read) exactly step-by-step "almost machine instructions" and where the only "expressiveness" needed is already fully afforded by Go and quite well at that. Dev-related mostly bulk-file-processing-based custom tooling (not bad to fire off sizable amounts of automatic background transformations from one weird format to another on file-system events etc.) .... filters through which to pipe vast/continuous data streams with just-some-processing over it .... providing out-of-process certain "low-level, must be lightning fast" tasks and logic with IPC for a higher-level codebase .... it's a great tool for such cases, especially given how simple the syntax is. Ie. the basics are grasped very easily very quickly and you don't have to recall "its pattern matching syntax and quirks, its generics syntax and quirks, its etc etc". =) I'm perplexed when teams choose to express their entire domain model or startup in Go, however.. fair game, maybe I'm missing something there

<comment><USER19> > robust/mature

Needs more context. It's more mature for some things than others, like many young languages.

> how are compile times

Not Go, for sure, but not the worst either.

> how much of a priority are they

Getting them down is a high priority, but has taken some time to make a dent in. The last few releases have all posted speed ups, and "cargo check" in the last release helps. Incremental recompilation is coming, you can try its initial implementation on nightly today. There's a lot more to do, but users really want improvements, so it is and will continue to be actively worked on.

<comment><USER18> > Incremental recompilation is coming

Good to hear, when that is in place compile times matter a whole lot less

</comment></comment></comment></comment><comment><USER20> I don't think anything in the 'The Bad' is unfair, and they're certainly not written from a position of ignorance.

Those are things that suck about go; it's not specifically that they suck about go when compared to haskell; they just generally suck (particularly the type system stuff).

However, I don't think that the situation is _so bad_ I would go as far as to say, "Other than that, I will probably never choose to use Go for anything ever again..."

I maintain that while go might not give smart programmers the flexibility to express their FP dreams, it has a grungy practicality both for developing and maintaining code that is quite effective.

Introducing go and building applications with it in a team is easy because its quick to pick up for the whole team, regardless of background, its simple to use and its (relatively) difficult to shoot yourself in the foot in terms of distributing binaries or developing applications that run at modest scale.

When gogland (the IDE by jetbrains) comes out of EAP, it'll even have a modestly good professional IDE with integrated debugger (no atom, you don't count when your debugger never works on any platform).

...but hey, if you don't like it, don't use it.

Haskell is pretty great too.

<comment><USER21> The thing with Go, is that it is disappointing what Google is capable of in terms of language design versus what Apple and Microsoft have done in this field.

Sure there were languages with such type systems before, and we managed to deliver our work with them.

However I don't want to work in 2017 as I used to work in the mid-90's, when templates were an experimental feature in C++, or the only MLs we knew were Caml Light, Miranda and SML.

The world has moved on.

<comment><USER18> > is that it is disappointing what Google is capable of

Man, how long will this meme survive? Go only initially _originated_ with some Google developers, it's not in any way "Google's answer to Apple's and Microsoft's strategically-important and accordingly-subsidized-and- evangelized-and-invested-in languages". Just picture a handful of (previously "accomplished" in the field, as it turns out though) guys thinking "this company has a wide mess of Python etc scripts that should really be C programs, except for the problems this would pose"..

<comment><USER21> Those developers are being paid by Google and their actions within this context relate to the public image of their employer.

If Google wouldn't agree with their actions, or did not pay to increase the team size, they would be developing the language outside Google walls.

<comment><USER22> You may disagree but Google relationship with Go looks lot more distant as compared to C#-MS, Java-Oracle, Swift-Apple. Here Dart-Google looks more appropriate. Those Dart people always keep telling us about Adword's usage of it. Google organizes Dart's conferences whereas for GopherCon doesn't even have Google as sponsor.

Go looks far more independent from Google in branding, sponsorship and references from official Google products.

<comment><USER23> That being said Go is one of the four recomended language in google : java, c++, python and go.

</comment></comment></comment></comment></comment></comment><comment><USER24> I feel like some of the criticism is unwarranted, specifically:

> The tooling is bad

I feel like the tooling is really impressive, considering the age of the language. Remember that Haskell is something like 25+ years old. Go has done quite a bit in short time - I can only hope it will get better too.

> Zero values are almost never what you want

I've always felt the defaults to be spot on. Anyway, it's my responsibility to initialise these values, even on struct fields.

> A culture of "backwards compatibility at all costs"

I agree the current (package management) landscape is dire, but this should change, hopefully this year, with godep. As it is now, I have found success using glide for dependency management, so that's what I would recommend for now.

Apart from that, I can agree on a lot of things - I'm specifically annoyed by the whole generics thing, the way I interpret the people involved with the project is "it would be nice to have, but the implementation is awkward, so we won't admit to it being nice to have".

<comment><USER25> > Remember that Haskell is something like 25+ years old.

Yet, I'd argue that tooling is still one of the worst aspects of the language. The whole cabal/stack thing is a mess.

<comment><USER21> Yet, at least we can use proper versions instead of Git urls that are exposed in source code.

<comment><USER26> And yet I can be up and running and compiling with Go faster then Haskell every time, ready to ship production binaries if I want.

With Haskell the process for me has repeatedly been: "okay I'm going to follow this tutorial...okay I need to install it...okay cabal is complaining about versions or exceptions....okay let's try stack....okay this example needs some includes...okay I don't have quite the right ver..."

Then 4 hours later I remember that I can't deploy any of this to my servers, give up, and go back to waiting for someone to make a sane "get started" bundle for an FP language.

Haskell's package management might exist - but it sucks, and I'll take go get/govendor over pretty much anything currently out there.

<comment><USER27> >And yet I can be up and running and compiling with Go faster then Haskell every time, ready to ship production binaries if I want.

You can. Today. But leave that code in a repo for a month, and it will stop compiling, because some of your dependencies got updated.

<comment><USER26> Not any of my code (or any of the projects I know) - the solution of the vendor/ is not "smart" but it's simple and comprehensible. My dependencies are locked and explicit - if you can clone my repository, then you also get the dependencies. And no, I really don't care about wasted disk space measured in megabytes.

</comment></comment></comment></comment></comment></comment><comment><USER28> This article's comments on code generation and generics are a good exposition of what I don't like about Go: it seems internally inconsistent, as though there is one set of features for the Go development team, and a lesser set for everyone else.

The nice thing about Haskell and the Lisps is that they are consistently the same thing all the way down through every layer of abstraction, even at the bottom. There is no point where you reach the "magic" or "forbidden" layer where the paradigm changes and it turns into a different language.

The problem with Go is that the code we programmers get to write feels like a DSL on top of the "real" Go, which uses constructs and "magic" we aren't allowed to take advantage of.

</comment><comment><USER29> TL;DR: "Go isn't like Haskell, and that means it's not as good"

I get that we all have favourite languages, but it is not amazingly helpful to try and compare them like this, for me. I'm sure if you're a Haskeller and you're eyeing up Go, being forewarned might be helpful, but here's another idea:

Don't compare. Just use. Take it at face value. Figure out what becomes easy, what becomes hard.

I came at Go from 10+ years of professional Ruby development, and it was a tough punch to the stomach at times. I still think in Ruby more often than I think in Go. But I know the two aren't really comparable for most things.

<comment><USER30> I don't understand. How can they not be comparable? They're the same type of tool, built with the same goal (writing any kind of software). In fact, Go itself was born because its creators felt the current languages weren't good at handling the current computing environment - comparisons with other languages are the at core of its existence. Finally, why even choose Go if it's not because it has some comparative advantage? Might as well stick with what we already know.

<comment><USER31> They're not the same type of tool. Go is mainly aimed at distributed computing evironments and infrastructural tools. I really don't see a sensible Consul/Kubernetes/Docker alternative being written in Haskell.

<comment><USER32> I don't see why not, Haskell has green threads, channels, and everything that Go has. The only argument I can see made is that the laziness and current GC implementation aren't suited, and even then, those problems can be solved with strictness pragmas, and a different GC respectively.

</comment></comment></comment></comment><comment><USER33> The author states:

>"Strict evaluation is typically better for performance than lazy evaluation (thunks cause allocation, so you're gambling that the computation saved offsets the memory cost), but it does make things less composable. "

Can anyone tell me what a "thunk" is in this context and also why it causes performance problems? The article linked to in the sentence results in a 404.

<comment><USER34> A thunk is an unevaluated value. Better, it's an unevaluated piece of code that returns a value when it's required.

For instance, you can write

        x = [1..]

which gives you a list of all the positive integers. Because of laziness (which thunking enables), this line runs just fine. The compiler allocates a thunk for x, saying "okay, I know what x is now". But x is never fully evaluated (because we don't really have enough memory!): it's only evaluated as far as needed. Indeed, typing

        head x -- this is 1

makes the interpreter print the first element of the list. The rest is still in a thunk. In memory, we have something like

         [1,<unevaluated thunk>]

Now you can try doing

        head (tail x) -- this is 2

which evaluates the list only as far as the second element. Right now, in memory, the list looks something like

         [1,2,<unevaluated thunk>]

You can do similar things with basically any other datatype, enabling cool stuff like [1].

However, having to evaluate (or "force") thunks repeatedly in tight loops can obviously degrade performance: printing a Haskell list like [1..10] requires you to evaluate the first element, print it, then force the next thunk to print the 2, and so on. Comparing this to the equivalent in basically any other (strict) language, we see that a lot of indirection is removed, because the endless wrapping/unwrapping is replaced with a simple linked list of 10 elements. (I'm sure GHC is smart enough to optimize the thunking away in this toy case sufficiently.)

One might also say that a thunk is a "promise" (I'm not familiar with the JS concept of the same name, which I think is related to async things instead) to give you a certain value by calculating it only when you need it (if you do at all: a thunk stays unevaluated when you're done running the program, it's GC'd away).

[1]: [http://jelv.is/blog/Lazy-Dynamic-Programming/](http://jelv.is/blog/Lazy- Dynamic-Programming/)

<comment><USER33> Thanks for the great explanations. Cheers.

</comment></comment></comment><comment><USER35> I liked this conclusion: "Go is just too different to how I think"

It is in a way a mirror image of my experience with Go: It is not so much that Go is a great language, it has its fair share of flaws, _but_ it is quite compatible with the way I think.

</comment><comment><USER36> > GHC's garbage collector is designed for throughput, not latency. It is a > generational copying collector, which means that pause times are > proportional to the amount of live data in the heap. To make matters worse, > it's also stop-the-world.

This is pretty much unacceptable in today's world of low-latency (web) apps.

How active is GHC's development?

Would it be possible to _efficiently_ run Haskell using Go's runtime environment, i.e. by changing the compiler backend?

<comment><USER37> If you have not too much data in the heap, you are safe. Even if you have a lot of data there, you most probably fine too.

As an example, see here: [https://bazqux.com/](https://bazqux.com/) and the discussion is here: [https://news.ycombinator.com/item?id=5961570](https://news.ycombinator.com/item?id=5961570)

He was able to survive unexpected slashdot effect from being on the front page of Hacker news without even noticing it. He told me he went up one evening and found that there were tens of thousands of new users actively trying his site. So he added a couple of servers and went to sleep.

GHC development is very active.

And the answer to your last question is No.

<comment><USER36> Okay, but surviving a Slashdot effect is different from having a low-latency server of course :)

<comment><USER37> He didn't tell me that anyone complained about delays, etc.

I think delays weren't that noticeable then.

</comment></comment></comment></comment><comment><USER38> > There is no way to specify a version [of an imported package]

You can do this in your version-control system (e.g. git), via a process called "vendoring". It's ugly but, using one of the popular tools, quite workable.

<comment><USER18> > It's ugly

What do you find ugly about it?

<comment><USER39> You don't properly separate and deduplicate dependencies, you can end up with legal issues (if you ever decide to redistribute your source), etc.

One of the few dependency systems I've seen that work well is Gradle with Maven dependencies, using Java 9's versioned modules.

Proper versioning, proper dependencies, etc.

</comment></comment></comment><comment><USER40> Pulling no punches:

 _Other than that, I will probably never choose to use Go for anything ever again, unless I'm being paid for it. Go is just too different to how I think: when I approach a programming problem, I first think about the types and abstractions that will be useful; I think about statically enforcing behaviour; and I don't worry about the cost of intermediary data structures, because that price is almost never paid in full._

Wow.

<comment><USER40> The cost profile for data structures is different in Go, though, since it tries to stack allocate very aggressively. GHC, like Java and many other classical GC'd languages, tends toward heap allocation.

</comment></comment><comment><USER41> Good writeup, but not an unexpected conclusion. I'd be very interested to see a similar writeup by a Haskeller on Rust, since the two are closer in some aspects (static enforcement of behavior, strong typing, well designed concurrency), but different in other key ones (strict vs lazy, GC vs manual, etc).

</comment><comment><USER42> Haskell always makes me sad. In real-world apps you always need hacks. I do anyway. In an imperative language I can be proud when my code only has a couple hacks in it. With Haskell I just end up feeling nasty about my code if there's even one hack there, and it makes me like coding less. (For toy apps with no deadline Haskell is great; the above regards Haskell-at-work, as a freelancer).

<comment><USER43> For me it's quite the opposite: Haskell allows me to have local hacky sections that I can then hide in a module that exposes a safe API. Since refactoring is fairly easy with compiler assistance, I don't even have to break up my 100-line-long work-in-progress algorithm with temporary names until it works – and once I have a working solution, converting it to something readable is mostly manually extracting definitions and giving them useful names.

<comment><USER42> That's nice. I haven't used it enough in a hacky way to come up with a list of good hacking patterns. Like I said, I always feel dirty, like I may as well be writing C, and then go do something else. Someone needs to write a book " _REAL_ Real-World Haskell", with effective patterns for that kind of thing.

</comment></comment></comment><comment><USER44> Well the fact that pretty much no one uses Haskell anywhere should give you some hints about the language iteself.

</comment><comment><USER45> > But Go does have generics, for the built-in types. Arrays, channels, maps, > and slices all have generic type parameters.

Doesn't this mean you could implement a generic tree type if you fix the underlying data structure to be an array/map? (Not a go programmer yet, but honestly curious)

<comment><USER46> >Doesn't this mean you could implement a generic tree type if you fix the underlying data structure to be an array/map?

Nope. There are only a few functions that accept type parameters, and they must be called with concrete types, and they only work with certain aggregate types. For example, "make" can only be used to create slices, maps or channels, so you could create a slice of 10 bytes with "make([]bytes, 10)" but you cannot write "make(T)" or even "make([]T, 10)" where T is a type variable, and you also can't do "make(Tree)" where Tree is, e.g, some struct type.

<comment><USER47> I think it's better to not even think of them as "generic functions". Think of them as language keywords which happen to have the syntax of functions.

</comment></comment></comment><comment><USER48> I'll argue that Python PEP 8 was probably the precursor to gofmt.

</comment><comment><USER49> TL;DR:

> _I will probably never choose to use Go for anything ever again_

</comment><comment><USER50> Offtop: what kind of static website generator did he use? Looks clean, looking for something similar for my usage.

<comment><USER51> The author's site appears to be built using Hakyll [https://jaspervdj.be/hakyll/](https://jaspervdj.be/hakyll/), which is a Haskell static site generator. You can find the source for this particular site on Github: [https://github.com/barrucadu/barrucadu.co.uk](https://github.com/barrucadu/barrucadu.co.uk)

The "clean look" you refer to is mostly thanks to custom CSS though - <USER2> specifically related to Hakyll.

If you're thinking about building a similarly- _styled_ blog or personal site, you could start by studying the styles this author used on their site: [https://github.com/barrucadu/barrucadu.co.uk/tree/master/css](https://github.com/barrucadu/barrucadu.co.uk/tree/master/css)

</comment></comment><comment><USER52> When I look at a programming language, I look at the community and how it gets stuff done and projects that are noteworthy.

Something about Haskell strikes me as different. Despite the buzz about it, I don't see many projects for it other than shellcheck, pandoc and xmonad, and for two of those, there's better solutions around (sphinx, awesome/i3).

The other thing is the general flow I've see with Haskell programmers, many really tie down their identity do it. They see programming as a crossword puzzle for them to solve in short term, not as something other programmers have to read later on. They're not very empathetic to the idea the runways dwindling and you have to ship sooner rather than later.

In addition, I found that the Scala / Haskell developers I knew took golang to be quite the nuisance. They find gophers pesky. I think the reason why is years of Haskell teaches them to overengineer and complicate things needlessly. It's frustrating because they're not aware of it themselves and take offense, even blame you when you point it out to them.

Maybe I've just been unlucky. In 10 years, I've never had people who consistently failed to ship, been mean and arrogant as scala / haskell programmers. They take the slight criticism as an assault on their identity.

<comment><USER53> > Despite the buzz about it, I don't see many projects for it other than > shellcheck, pandoc and xmonad, and for two of those, there's better > solutions around (sphinx, awesome/i3)

I tried awesome for two weeks and had one crash. I've run XMonad for 5+ years and had no crashes. Just because they are supposed to accomplish the same things does not mean that they're equal. One is better and it's because of the choice of language.

It's very hard to take your post seriously when you include something like this in it and you don't bother to qualify it even in the slightest.

<comment><USER52> > One is better and it's because of the choice of language. > It's very hard > to take your post seriously when you include something like this in it and > you don't bother to qualify it even in the slightest.

I looked in your history and yup, you are partial to Haskell. Why do you feel a need to immediately judge. Why did you say "hard to take seriously". Why didn't you just ask politely for more details? In my opinion, you already had your mind made up. Just like the blog poster did.

> I tried awesome for two weeks and had one crash. I've run XMonad for 5+ > years and had no crashes.

That's your personal anecdote. There's no evidence that the language could have prevented the crash.

And that doesn't make the window manager "better", which is subjective. What are more people using? Awesome and i3. Primarily because they don't want to deal with Haskell when they could be doing lua or a simple config.

<comment><USER53> > I looked in your history and yup, you are partial to Haskell.

It's convenient that you have no post history to go through, since you decided that the nonsense you're posting shouldn't be tied to your real account.

Your bias is astounding, yet you go for the "your mind was already made up" card. I like Haskell but by no means am I tied to any single language and I'm not the one making posts about how all the users of a language seem to have undesirable traits.

Even better, you then criticize using "personal anecdotes", when that's exactly what you did in order to condemn the users of two languages. You half- dampen it by saying "Maybe I'm just unlucky", but the entire point of your post is "these two communities suck".

> That's your personal anecdote. There's no evidence that the language could > have prevented the crash.

Any ML-family compiler will catch more crap at compile time than any C compiler. Adding lua on top will not solve any of that. None of that is opinion. It's just how the languages are designed and how they use types. Adding automatic memory management to that makes the gap even wider and in short, that stops the vast majority of crashes that you can get.

C + lua is great for lots of things, but everything is a tradeoff and here the tradeoff is that you're very likely to get crashes. Good intentions alone can't prevent segfaults and most C software is proof of that.

<comment><USER52> If it were node.js, I highly doubt I'd have a person coming out of the woodwork with cleverly placed quotes as if it's a legal threat.

Then blaming me for being biased as if you don't already have a conclusion derived. This is the behavior I experienced - to me, this feels like projection and trying to bully me into silencing what I truly witnessed. It really bothers me and makes me uncomfortable.

I'm just stating my experiences. You wanna know why I use a throwaway? Because people bully and bludgeon anyone who doesn't praise Haskell and / or Scala. And it's been unique to those language communities.

At the end of the day, your reaction is predictable. I'm not reading too deeply into what you say because, like my prior experiences, I think you have your mind up, and in spite or proof given, you're going to be on the defense / offense.

> Any ML-family compiler will catch more crap at compile time than any C > compiler...

None of these things about language mattered since awesome and i3 had language as an _afterthought_ and focused on experience. xmonad literally has haskell mentioned as a feature, the token battlestation pic (which is pretty cool) even has a haskell book next to it. Xmonad even uses haskell for the configuration of it.

Look, not trying to take a jab at hobbyists. It's just I'm saying, in my experience, I found Haskell and scala "hobbyists" to be quite mean and it hurt my feelings alot, especially when I dropped, far more politely than when they ever spoke to me, the news they're not focused on business goals and work product and just refactoring stuff over and over. They kind of failed at bringing product vision to light, even basic things like defining requirements felt beneath them. Again, maybe I've just been unlucky.

<comment> nv-vn >You're proving my point. If it were node.js, I highly doubt I'd have a person coming out of the woodwork with cleverly placed quotes as if it's a legal threat.

The irony is that you came out to defend Go from any sort of criticism without any direct argument as to why Haskell is bad. Your post talks about the people who use it and criticizes them for criticizing other programmers, yet that reflects perfectly on what you are doing. And yes, I am also defending Haskell when I see your comment. I'm sure Node.js programmers would defend Node.js. Programmers care about their language choice as much as they care about their text editor/IDE choice, and it's something that we all love to argue about.

>At the end of the day, your reaction is predictable. I'm not reading too deeply into what you say because, like my prior experiences, I think you have your mind up, and in spite or proof given, you're going to be on the defense / offense.

So you haven't made up your mind already by criticizing Haskell before even evaluating it as a language? It's not making up your mind on it when you based all your judgements from personal anecdotes of Haskell and Scala programmers you've met before?

>xmonad literally has haskell mentioned as a feature

AwesomeWM lists Lua as a feature [1]. Maybe Haskell programmers care about that a bit more strongly, but both groups use their configuration language as a feature. Hyper lists JS/HTML/CSS as a feature as well [2]. Although I would argue the real argument between Haskell and other languages is safety -- just like Rust or Ada programmers would list those languages as a safety feature, Haskell programmers are inclined to do the same. It's pretty similar to saying "code has been tested extensively by our quality assurance team" or something "code has been formally verified," etc.

[1] [https://awesomewm.org/](https://awesomewm.org/) [2] [https://hyper.is/](https://hyper.is/)

<comment><USER52> It's my experience and opinion.

Also, I looked through your history, you're a Haskell programmer. Due to the context of my thread, I'd appreciate it if you disclosed your relation so others know.

> AwesomeWM lists Lua as a feature

It's a scripting language on top of that's used for configuration.

> It's pretty similar to saying "code has been tested extensively by our > quality assurance team" or something "code has been formally verified,"

The problem is Haskell developers aren't really getting enough shipped, especially relative to the advocacy I see of it. So how much does code correctness matter?

Look, let's say I want play FreeCiv. It being programmed in C vs Haskell vs Erlang doesn't mean much to me.

But imagine if FreeCiv lacked basic functionality or code documentation, and when people mentioned these things they'd get jumped by people who advocate it being programmed in an esoteric language who look down on those who program C as unsafe, inefficient, etc.

> So you haven't made up your mind already by criticizing Haskell before even > evaluating it as a language? It's not making up your mind on it when you > based all your judgements from personal anecdotes of Haskell and Scala > programmers you've met before?

Hugo vs Pandoc

Awesome/i3 vs xmonad

You want to know why these solutions got more popular than the their Haskell predecessors? They had devops like documentation and tooling down. They picked languages that were easier to read so the community could participate. The discussion was about how to ship features by a version release, not how to force the language to get a purely internal technical working.

Users can't see the internals, so they don't care. They want something that's there for them on time and reliably. In all these years to this day, there's been more advocating Haskell philosophically on forums than there's been real discussion about getting stuff shipped. Try saying that for node/go/ruby/python.

<comment> nv-vn I am not a Haskell programmer, in fact I am not very fond of the language and have only ever used it for a single project. I find the language interesting, but I disagree with many of the fundamental design decisions and it is never my first choice for a project.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER54> The author mentioned that code generation "introduces additional, non-standart syntax". One can say exactly the same about generics.

Most useful typesystems with generics are Turing-complete. Essentially they introduce own language for types with often very weired rules and syntax that one has to master on top of the basic language. With code generation I can program my types using the same language I use for code with less things to learn.

<comment><USER10> > _One can say exactly the same about generics_

No, it's the same language with a bigger vocabulary and grammar, on which everybody agrees.

And generics can be quite sane, as exemplified by the languages in the ML family, which have been around for decades.

Java also didn't have generics. They added them eventually, much later in version 5, but then due to backwards compatibility concerns they added them with invariance at the declaration site and complex wildcard rules at use site.

So the irony of this situation is that Go will add generics, it's inevitable for a (quasi) static language once it grows in usage and ecosystem. But when they'll do add those generics, they'll be broken due to backwards compatibility concerns, becoming yet another counter example for generics, picked up by the next Go / Java that will reinvent the wheels again.

<comment><USER54> The ugliness of Java generics comes from type erasing. It allowed to stay compatible with JVM. Go has no such restrictions and I do not see why a truly minimal generics in a style of Virgil cannot be added to Go at some point.

<comment><USER10> No, type erasure is actually an (unplanned) feature, because it didn't cripple the runtime for other languages.

On this one people miss the forest from the trees. dotNET type reification is about introducing runtime meta-data and checks, which you only need when your type system is not strong / expressive enough, which makes you want to do `isInstanceOf` checks. Well, guess what, needing to check that an instance is a List<int> is a failure of the language ;-)

This issue is also mixed with specialization for primitives. But that's actually unrelated because you don't need reification to do specialization. And actually you don't need runtime support either, as specialization can be compile time.

Also, in actual practice with Java, type reification is only a small usability issue. The real clusterfuck have been those wildcards for expressing use-site variance.

> _It allowed to stay compatible with JVM. Go has no such restrictions_

That's circular logic, given the JVM release cycle is tightly linked to Java the language and has had evolved in response to new features of Java.

No, the actual reason was to preserve compatibility with older code that weren't using generics (e.g. List vs List<int>) without forking the standard library in pre- and post-generics functionality (like .NET has done).

Go will have exactly the exact same problem.

<comment><USER39> Luckily, Java's generics are actually changing with Java 10 towards a more powerful system even.

It's disappointing how Go, in every way, is just Java 2 with a handful of additional libraries.

Simply using Java 2, adding some libs, and compiling with GCJ would net the exact same binaries, with far less work.

</comment></comment></comment></comment></comment><comment><USER55> I think comparing Go and Haskell are like comparing two incomparable different species -- a fish vs. a cat.

Why? Because Haskell is an interpreted language while Go is a compiled one. Interpreted language doesn't care much about performance as it isn't designed for that purpose, while in the other hand, compiled language does. As a result, interpreted language tends to be more 'elegant' and has lots of convenient features at the cost of performance. A concrete example is when you talk about preventing unacceptable data type in Haskell. They could make it so in Go, but the performance cost would be undesirable.

IIRC, I read that they designed Go to be practical instead of 'elegant', the reason is so that people can learn it easily, making it a good alternative for other compiled languages like C++ whose learning curve is hugeeee and ugly!

<comment><USER56> Haskell is a compiled language.

<comment><USER57> There is no such thing as a "compiled language" or an "interpreted language", as this is a property of language implementations: interpreters (GHCi, Hugs) and compilers (GHC, JHC).</comment></comment></comment>


Single stroke – Render images as a single stroke illustration - <AUTHOR> http://single-stroke.nazeh.me/ <comment><USER2> suggestion: have some example images ready on the page instead of requiring the user to pick one from disk.</comment>


Virgin Media stores user passwords in plaintext? - <AUTHOR> https://twitter.com/virginmedia/status/595135419152474112 <comment><USER4> I think the pitchforks may have been lit a bit early here. The password all support staff can see is for phone verification, and is completely separate from the online log in password [0]

However, Virgin don't seem to have clarified if and how the online log in password is hashed.

[0] -[https://virginmedia.response.lithium.com/portal/conversation...](https://virginmedia.response.lithium.com/portal/conversation/3957067)

<comment><USER5> Yeah, for the people confused, "authentication codeword" might be a better way to think of it. This is not the traditional password, this is akin to the phone support version of your mother's maiden name.

If I were to call up Virgin and say, "Hey, this is MattBearman, I want to add a phone to my account and an international calling plan," they need a way to verify that I am MattBearman. Instead of asking for personal information, they ask for an "account password" _which is not your online password and is only used for the purpose of identifying the caller_.

It has to be plaintext or encrypted; they're not going to give you a hashing algorithm to work out over the phone.

<comment><USER6> Well, in theory they could just tell the phone rep the unencrypted password and the phone rep could enter it into the system and the system could tell them if the hash matches. That's pretty much how it happens with most websites these days anyway. But I can see there's a big benefit in the rep being able to accept passwords which are obviously (to a human) the same, but would hash differently.

</comment></comment></comment><comment><USER7> So in short:

      - They're doing things correctly
      - They ask for a code over the phone to verify your account
      - Their Twitter guy refers to this as a "password"
      - Nobody reads anything on the internet, therefore everybody is concerned and fighty.

There's no indication of how _passwords_ are actually stored. This is all about the passphrase you tell the guy on the phone so that he can verify your account. It seems reasonable that that guy would need to be able to see that word on a screen so that he can compare it to what you say.

Still, it's good that people are still really angry about this, 23 hours after their support guy explained what's going on.

<comment><USER8> If the operator is only one that checks credential, it is still huge security risk IMHO. He/she can reuse this information to imitates one of the customers he got the credentials.

Here, the operator forwards you to a machine and you input your phone password, so the operator does not know your whole credentials.

</comment></comment><comment><USER9> Seems like we've moved from calling out companies for long standing bad practises to some kind of tribal behaviour where people are almost looking for a reason to call a company out for "bad security."

Let me be clear: Phone passwords are superior to phone pins, phone secret question/answers are superior to both, and the agent needs to be able to verify the secret question/answer set, and also the password. You CAN design it so the agent cannot see the whole password, but that means the agent cannot use common sense to account for differences in spelling, or interpretation e.g. "to" as 2, to, two, and too (plus "the third digit of your password" is hard for humans, we aren't designed that way).

People saying things like: "an agent cannot be trusted!" Are missing the point, that the entire system is built on agent trust. When you call you're purposely giving this agent access to your account, making the password useless, there's no proof they logged off when you hang up, there's also no proof that they aren't writing down your responses and will then relay it to another agent later.

A lot of people who whine about plain text in particular don't really seem to understand what it is that hashing even does. They seem to think things like: "if you get hacked, someone cannot steal passwords" (nope) or "then someone cannot sniff your password over free wifi" (nope). All hashing does is add time between the hack, and when the hacker can start using the stolen credentials, that's it. It is there to give the company time to detect the leak and to notify/reset, if the company fails to detect then it has done absolutely nothing of worth.

To be honest I find "HTTP offenders" (e.g. HTTP web-sites that redirect to HTTPS login forms, essentially breaking HTTPS's MitM protections) far worse than "plain text offenders." But none of this has anything to do with calling out security issues at this point. A bunch of people who don't seem to understand the technicals here feel like they're doing "good" by calling out companies for things that don't even make sense.

</comment><comment><USER10> Is this actually a password or something closer to a PIN? I don't know that there's anything wrong with not cryptographically mangling a PIN since there are so few combinations in the first place. I think the SOP in most cases (my bank, for one) is to use multiple forms of ID verification (last 4 of social, birthday, and PIN, e.g.).

Whoever runs their twitter also later claims that this account password is different than their online password, which seems to support that it's more of a PIN than global password. I'm not a Virgin employee or customer though, so I'm not sure if this is the case or not.

<comment><USER11> Correct, it's just a simple way to verify you're the account holder. Saves asking for DOB, address, account number which are more accessible.

<comment><USER12> Whenever I need to call Virgin to try and get some info, I need to:

      - Type in my account number
      - Wait for an agent
      - Get an agent. Give my name and account number
      - Explain my problem
      - Get transferred to another agent
      - <USER3>
      - Get an agent, give my account number
      - Give the third letter of my password (which got me confused, as I thought they were asking for my account password)
      - Explain my problem
      - Get transferred to another agent
      - <USER3>
      - Get an agent, give my account number

In the end, I talked to three persons, in the same company, and gave 4 times my account number, and one time my "password".

Can confirm, does not save time at all!

Note: this is for Virgin Media UK. Did not experience that with Virgin Media in Canada.

</comment></comment></comment><comment><USER13> So, it seems this only applies to the phone verification password and not the online account password. Can someone explain to me what the better alternatives are for phone verification? Is punching in a PIN considerably better? Banks ask for last 4 of social, which I don't think is something I would give anyone besides a bank.

Virgin's hardly the only one doing this. ADT reps ask for a password when verifying an alarm. At least its better than just asking for your name and address.

<comment><USER14> The advantage of punching in four digits is that your phone rep doesn't get to see/hear them. You've identified yourself to the system, not the individual.

<comment><USER15> DTMF isn't transmitted in secret. Of course they _could_ eavesdrop on what you entered through a keypad. Keying it into a machine listening to an unsecured phone line is the equivalent of sending it in plaintext and just as vulnerable as telling it to an agent on the other end of the call.

</comment></comment></comment><comment><USER16> This is an international thing - I'm with Virgin Mobile in Australia and the "Forgot Password" button sends me my password in plain text (which is, even better, only allowed to be numbers, and only 6 of them! Guessing 10^6 numbers doesn't take long)

This is known since at least 2013: [http://www.kitguru.net/gaming/security- software/jon-martinda...](http://www.kitguru.net/gaming/security-software/jon- martindale/virgin-media-stores-phone-authentication-passwords-in-plaintext/)

Edit: Others are saying this is for the "phone verification password", but my password is to log into the online account to pay my phone bill.

<comment><AUTHOR> Upload a screenshot to [http://plaintextoffenders.com/](http://plaintextoffenders.com/)

<comment><USER16> I had thought of that - my mail (even though from virginmobile.com.au) is identical to the UK one: [http://plaintextoffenders.com/post/4983474119/virginmobile-c...](http://plaintextoffenders.com/post/4983474119/virginmobile- co-uk-virgin-mobile)

And that one's from 2011!!

</comment></comment></comment><comment><USER17> "Administrators and/or customer service reps need to be able to see passwords for XYZ purposes" is a relative common requirement even nowadays, especially if those requirements were drawn up by non-technical people.

One part of me wishes that the governments of the world would just outlaw this kind of idiocy. On the other hand, I'm not sure if I'd like that much regulation. I certainly wouldn't want to be a developer in a world where I can get sued for using a non-NIST-approved algorithm or something.

Fortunately, "PCI-DSS" seems to be the magic word that can developers can use to beat sense into people's heads most of the time.

</comment><comment><USER18> I have a Virgin Media account authorisation password to identify myself as an account manager over the phone. Has nothing to do with any online login system.

</comment><comment><USER19> Incidentally, I just found out yesterday that Straight Talk (AT&T MVNO) keeps their _online_ passwords in plaintext. Restoring your password actually sends you the password by email.

I'm glad I never reuse a password.

</comment><comment><USER20> The end result of this is that I'm impressed with Virgin Media's quick responses on twitter.

</comment><comment><USER21> and they don't seem to get it even after people explaining it to them

<comment><AUTHOR> Even better, it appears that it will require legal motivation for them to change their behavior: [https://twitter.com/virginmedia/status/595241181065383936](https://twitter.com/virginmedia/status/595241181065383936)

<comment><USER22> You have to bare in mind that the people managing that social media account is probably only a few grades higher than your average call centre puppet who follows a script. While some of VM's responses could have been phrased better (within the confines of Twitters max character count), these people are generally there to answer end user rage about their router crashing and such like rather than this. Sadly information security is quite significantly more advanced - so much so that even IT professionals frequently get it wrong.

What should really be happening here is the discussion being escalated to their systems / security team and an official open letter published.

</comment></comment></comment><comment><USER23> So... this password... this is a password for what?

</comment><comment><USER24> Nothing new here.</comment>


Stellar just sent 100M Lumens (worth $5M USD) to 300k Keybase users - <AUTHOR> https://keybase.io/airdrop <comment><USER2> For those of you not on Keybase yet, here's the most important piece of information in the post:

 _" To qualify: you must have a Keybase account registered before this announcement OR if you're new to Keybase, you must connect your Keybase account to a GitHub or HackerNews account that was registered before this announcement. This is to prevent bot signups to Keybase."_

<comment><USER3> It fails to mention that Github and HN accounts must be older than January 1, 2017. This is what I saw in the app when I tried to join the airdrop: [https://i.imgur.com/ZOZ1rB7.png](https://i.imgur.com/ZOZ1rB7.png)

I hope that's an accidental omission and not an intentional dark pattern.

<comment><USER4> Not a dark pattern, an accidental leftover string from our testing. Any account registered before today qualifies. I'll deploy a fix to that shortly. Update: deployed, although you may need to restart your app to update the text.

<comment><USER5> Sucks you had the sign up date prior to the announcement. When I read the announcement I immediately signed up for a keybase, HN and Github account and then find out I cant be included because I signed up on 9/9/2019\. You would think that would be the incentive to at least give a little buffer for people to join in that were not aware.

</comment></comment></comment></comment><comment><USER6> I'm not sure it's a great idea to place a $20 bounty on breaking into anyone's Keybase, GitHub, or Hacker News account? And this bounty will go up every month, until something breaks?

The weak link here seems to be Hacker News since it's protected only by a password.

<comment><USER7> How does compromising a GitHub or HN account compromise the linked Keybase account? Yes, you can link to those accounts on Keybase, but the trust relationship is going the other way: Keybase is proving that you had access to those accounts (on a particular day).

<comment><USER8> I think the implication is that an unlinked and appropriately aged Github/HN account can be compromised to get 20 bucks by compromising and linking.

I'm sure if someone actually reached out to @malgorithms saying "hey someone stole my GH/HN account out from under me to get the 20 bucks" they'd resolve the issue.

<comment><USER6> That's assuming you would notice. I just linked my HN account to Keybase, then deleted the proof from my HN profile. The link doesn't seem to be revoked?

It seems like an attacker could do that, and I don't know when you'd first notice that your HN profile is linked to a Keybase account that doesn't belong to you? Particularly someone who doesn't use Keybase.

<comment><USER9> The link isn't removed on the keybase side but the next time it's checked it will be flagged as bad. Clients will check it automatically when you follow; otherwise, I believe what happens is the system will periodically check it and cache that data for some time (so that way you're not hitting the external services every single time you visit someone's profile).

I would assume the airdrop ensures the GitHub/HN proofs are up-to-date before sending the lumens.

</comment></comment></comment></comment></comment><comment><USER10> Can someone explain why this is particularly interesting?

Seems like every other coin/product giveaway to seed users on a platform, but I'm not super familiar with the Stellar network.

<comment><USER11> I'd normally be with you on this and I get the sensitivity to cryptocurrency (more-often-than-not-snakeoil) posts, but I think this is interesting because of the broader implications:

(1) Keybase is an interesting product -- on its own, it's a great product (I've been a user since before `kbfs`) that's well designed, its architecture and implementation is interesting and its features are practical/useful to a lot of us. I don't know that they've made public/private key cryptography accessible to everyone, but it's a far cry from every other attempt I've seen.

(2) At least, for me, I didn't understand the reason for Stellar's integration. A lot of people ran to "quick buck"/"another crypto-play", but it just didn't seem consistent with the way keybase had been operating up to then. There were already many shared technologies involved, along with a company that, thus far, has had me excited with every new feature announcement, I remember saying "not sure how good of an idea this is, but if it can be done, they're the ones that could probably do it".

And their purpose for the currency, from what little I (probably don't) understand, is _not_ to hold/trade but use it to purchase.

I hadn't touched the Stellar wallet feature, at all, because I didn't care to figure out how to put cash money into a crypto account "for no reason". I'm not a cryptocurrency investor (I've mined a bit). The thing of it is, I cared so little about it that I didn't even bother looking if there _was_ a reason to toss some funds in. Now I don't have to and they just bribed me to investigate, further.

I'm guessing this is mostly a marketing play. Hopefully I'll find some good reason that I want $20 in Lumens; if that's the case, then they saw what was needed to hack me.

<comment><USER12> I think the interesting thing about a cryptocurrency working with keybase is that it is a solid solution to the "am I sending this money to the person I think I am" problem. If I owe someone $20, I might or might not know their venmo name, or their bitcoin address, but I probably know their handle on github, hacker news, twitter, reddit, etc.

</comment></comment></comment><comment><USER13> Does this create tax implications for all HN users?

<comment><USER14> First - this will apply to HN users with a Keybase account who have opted in to the airdrop, not all HN users.

I am not a CPA, but I think there are two things involved here (for people in the US):

1\. This is a gift, but the value of it (about $20 right now) is less than the gift tax threshold. 2\. Lumens are probably (?) treated like bitcoin, which are treated like a security, not currency.

I think this means that yes, there are tax implications. You will be obligated to pay short- or long-term capital gains tax when you elect to 'sell' the Lumens, and the cost basis will be the fair market value of the Lumens on the day you receive them from SDF.

Again, not a CPA, tax lawyer, or anything like that.

</comment></comment><comment><USER9> I have a Keybase account with a wallet. I haven't actually used the wallet for anything, but it does exist. And I didn't receive any lumens.

If this surprise gift was for "each active Keybase user", how do they define "active Keybase user"?

Edit: Also, the desktop app didn't show anything about joining the monthly airdrop. I had to fire up the mobile app to see it.

Edit 2: After fully quitting the desktop app (including status item) and relaunching, the Wallet section finally shows an "Airdrop" entry. I shouldn't have to fully quit out of Keybase for this to work though.

</comment><comment><USER15> Sweet. Good tip.</comment>


Seeking Mediocre Ruby Devs - <AUTHOR> https://groups.google.com/forum/m/#!topic/rails-oceania/SXI_hN1pQoc

<comment><USER2> This is actually brilliant in terms of getting applicants. As someone who just started professional development work in 2012, I get sick of reading job descriptions that ask for a candidate who is perfect at what they do, or try to attract applicants with insincere language. The honesty in this posting is refreshing, and while I'm not looking right now, I think they'll actually get some pretty great candidates this way (who might not have the highest self- confidence).

</comment><comment><USER3> As an emacs user, I find this post incredibly offensive.

</comment><comment><USER4> I thought the title was pretty funny - definitely grabbed my attention. Good luck!

</comment><comment><USER5> One thing that caught my eye: Emacs users don't need to apply. While I'm not one myself I'd like to know what's the reasoning there. Did they manage to ge entrenched in vim?

</comment><comment><USER6> "Oh yeah, brogrammers, corporate types and emacs users probably shouldn't bother applying." ...

Who the hell can apply then ?

<comment><USER7> vim users, but of course.

vim 1 - emacs 0

</comment></comment><comment><USER8> This is an excellent approach. Extremely few people can be the bestest of the best, but luckily only extremely few companies actually need them. Cutting the bullshit is good for everyone.

I'd replace "mediocre" with "competent" though.</comment>


Ask HN: How do you convince your managers to allow time for refactoring? - <AUTHOR> How do you convince the business that there is a good case for refactoring and convince them that there is value in doing so? It seems like every single place I go to, business priorities are always urgent and there is almost never any push being done to refactor code. Have you managed to get buy-in if so, how? <comment><USER2> Maybe by quantifying the cost with a concrete example.

Take a particular convoluted piece of code from your codebase, preferably having a bug in it that exists in your issue tracker.

Show your manager this code, by scrolling through it (he/she does not have to understand it). Now you say: "We have this bug in this code, which cost me 4 hrs to solve. I had to debug, consult team members, etc. Now had we refactored this code before, the bug would already be eliminated and never reached the customer. Here I have the refactored code, which took me 2 hrs to create. Looks much cleaner, right? Even if the bug had remained in this code, I would have found and fixed it within an hour, and so would the next guy without having to bother other team members. When I refactored I even found yet another bug in the original code that hadn't been detected yet."

Refactoring turned out to be cheaper in any way, and avoids the hit to customer satisfaction if it goes into production.</comment>


OKombinator: Applying the YC recipe for startup success - <AUTHOR> https://medium.com/@letsokhi/okombinator-focus-on-growth-c4c14a4f90b5

<comment><USER2> _" With our business model (more on this later) our main <value proposition> is to help businesses deliver to their customers faster. At our <current growth>, <traction> means increasing the number of <deliveries> being made using OkHi and our <OMTM> is therefore the number of <deliveries> using an OkHi address per week."_

Less <jargon> in the sentences might be a good start.

</comment><comment><AUTHOR> Paul Graham says, "that growth is everything for a startup". We are taking it to heart and we are running a growth experiment modeled on YC's growth philosophy.</comment>


CyberFox and general Firefox forks - <AUTHOR> I'm in the process of switching from Chrome to Firefox and I'm wondering what FF forks are worthwhile. Default Firefox seems really bloated and clumsy nowadays (especially compared to Chrome), not to mention the Australis interface which I don't like much.<p>I've heard about Pale Moon, Ice Dragon, WaterFox. Currently I am testing CyberFox and it seems responsive and quite light on resources, and also has a portable edition. However, its webpage (http://cyberfox.8pecxstudios.com) doesn't feel particularly professional (typos like Dreamsceens, overall interpunction, grammar). These kinds of things always raise a red flag for me so I wanted to ask if you had any experiences with CyberFox, can you reccommend it etc.? <comment><USER2> I would recommend just downloading and trying whatever looks interesting. It is perfectly reasonable to have multiple browsers installed...anyone who runs Ubuntu desktop does anyway.

Good luck.</comment>


Here's what an Ashley Madison blackmail letter looks like - <AUTHOR> https://www.grahamcluley.com/2016/01/ashley-madison-blackmail-letter/ <comment><USER2> I agree with the article: It only makes sense NOT to pay.

There is absolutely nothing stopping them, after they receive $2K, from hitting you up again six months or a year from now for more money. In particular as they know you will pay blackmail, you make a better target than average. There's also nothing stopping other people from blackmailing you in a similar way, since the information is public and research is relatively easy.

My advice would be: Tell your spouse.

Then look at your online presence in general. Google yourself. If you have a public Facebook, Twitter, etc then maybe it is time to nix that. It won't stop them trying to blackmail you for being on the site, but it will limit the extended damage they can do with the information (e.g. calling your kids, calling your friends, etc).

Overall while I am no fan of adultery, I take an even dimmer view of blackmail.</comment>


US Healthcare Bill Requires Restaurants to Display Calories, But Will it Help? - <AUTHOR> http://singularityhub.com/2010/03/28/us-healthcare-bill-requires-restaurants-to-display-calories-on-menus-but-will-it-help/

<comment><USER2> I know this is just a single data point, but they've already instituted a law like this within King County. It has certainly changed the way I order when I'm out. Accuracy of the numbers notwithstanding, you can clearly see huge differences in calorie counts between different menu items, and I've personally steered clear of some of the more daunting ones that I might have otherwise ordered.

Once again, that's just me, and it doesn't really speak to the accuracy of the figures.

<comment><USER3> Ditto in NYC. You'd be surprised ( or at least I was ) to find out that certain salads are quite the calorie bombs while other dishes ( ex. pasta bolognese ) have far fewer calories than you'd think.

<comment><USER4> I was thinking the same thing about NYC (though I don't live there) as I remembered reading that a study found it did have an impact on people's eating habits: <http://www.gsb.stanford.edu/news/starbucks.html>

</comment></comment></comment><comment><USER5> Of course, if the problem turns out not to be food calories but food composition, the only thing this will do is push more useless information into people's faces. Making it more prominent won't make it more useful.

Personally, I would take this as further condemnation of the calorie counting approach to health in the first place. Our ancestors did not need it, and there's nowhere in the human body to input raw calorie counts into our satiety mechanism. This is the classic hacks piled on hacks pattern, instead of fixing the root problem.

<comment><USER6> But every nutritionist says "calories in, calories out"; that effectively counting calories and eating less is the only sure way to lose weight.

<comment><USER4> On the surface, yes, less calories eaten than burned will result in losing weight, but only following this rule on the surface is dangerous.

* Do you get enough of the necessary nutrients? * Do you eat so little that your body starts to reduce it's metabolism? * Do you have exercise program that continues after you stop a reduced calorie diet to rebuild the lost muscle tissue (your body burns both muscle and fat tissue when compensating for the missing calories)? * After the diet do you return to normal eating habits, or eat a diet that is balanced against your physical activity?

</comment></comment></comment><comment><USER7> I believe this will just keep the moderately health conscious people being health conscious but will leave the ignorant unchanged and continue to make poor food choices. Take McDonald's packaging for example. They have been putting nutrition information on their packages for some time now but do you think that deters Joe Blow from ordering his super duper extra large king size Coke and fries?

Do you really need nutritional information hitting you in the face to realize that deep fried chicken that you're going to eat is bad for you?

It's not as if they use this information to decide between a hoagie and a salad. They use it to decide if they should get the huge hoagie or the one a couple of inches smaller.

<comment><USER8> Having it on the package is a little different though since you don't find out about the calories until after you order. When the counts are before you make the decision it may have a more profound effect.

<comment><USER7> Yes I know, seeing it on the package after you order it couldn't possibly stop you from repeating the same mistake and avoid ordering it the next 100 times.

<comment><USER9> I think you're giving too much credit to memory. Even though I've looked at the nutritional information on my fish sandwich the last three or four times I ordered it, I honestly cannot give you even a rough estimation of the calorie count -- nor would I be able to have an informed opinion the next time I'm in line and trying to decide between the fish and a big mac.

On the other hand, having that information displayed _prior_ to ordering not only makes it readily apparent, but it also removes the burden of forcing the consumer to be constantly carrying around past nutritional information in their head.

<comment><USER7> Do you really think that either are a healthy choice? You're comparing two poor choices with each other and both will likely have the same outcome if eaten regularly. No nutritional label is going to change that.

Also, you're making the assumption that people can make a proper choice after reading a nutritional label. I could show someone that is less informed the nutritional data for various pieces of fish (that hasn't been breaded or deep fried) and they would think the fat and cholesterol content means that it's horrible for you when in fact fish has been shown to be beneficial.

<comment><USER9> _Do you really think that either are a healthy choice?_

No, not necessarily.

 _You're comparing two poor choices ..._

Of which one is most certainly less poor. Granted, neither might be optimal, but if you've reached the point that you're reading the nutrition information, chances are you've already chosen where you're going to eat. Are you saying that making the slightly healthier choice would somehow be sub-optimal given the situation?

 _Also, you're making the assumption that people can make a proper choice after reading a nutritional label._

Yes, and that might be the wrong assumption when given the choice between apples and oranges; however, when contemplating a large fry vs. a medium fry (or a large anything vs. a smaller version of the _same thing_ ), the proper choice should most definitely be clear.

</comment></comment></comment></comment></comment></comment><comment><USER10> I think it is a fine idea, but I don't think it will be effective. Has the average person become heavier or lighter since the introduction of the Nutrition Facts Label on packed food was introduced in the 90's? The issue is the length of the feedback loop and the power of momentum. I saw some other stat that showed even after heart attacks only 30% of people changed their lifestyles.

</comment><comment><USER6> Maybe it will help people who think ordering a large caesar salad is healthy.

</comment><comment><USER11> It'll force some restaurants to rethink their menus.

</comment><comment><USER12> I'm still buying the cheeseburger...</comment>


Five Neglected Computer Science Classics - <AUTHOR> https://medium.com/@kwindla/five-neglected-computer-science-classics-e0aefd24bf8e

<comment><USER2> Glad to see a list that doesn't just rehash the same books/papers. The Purely Functional Data Structures suggestion looks like a great read

</comment><comment><USER3> Five good reads (okay, one that I've read and four that I now definitely will), and the beautiful prose I have come to love over twenty years of reading this particular author.

</comment><comment><USER4> I'm excited to read the Synthesis paper, I haven't seen that one before.</comment>


Ask HN: Do I need an ABN to do a one off consultancy gig? (Australia) - <AUTHOR>

I'm trying to find out some information about my responsibilities with regard to a one off consultancy gig. I expect the income to be less than $20k, and I don't expect to be doing any work after this (at this stage).
Am I going to need an ABN? Will I need a business name as well? Do I need to pay tax, and if so, will it be company or personal income? Any Australian contractors or consultants around to offer advice?
Thanks <comment><USER2> The easiest thing to do is apply for a sole trader ABN. The application takes a few minutes and usually you'll get your ABN immediately.

$20k will easily put you under the GST threshold and the requirement to file business activity statements (BAS), but remember to still charge the client GST.

<comment><AUTHOR> Thanks for the answer, I'm looking into sole trader structures now. To your knowledge, should I be paying personal income tax on the income, or company tax through the business?

Also, WRT GST, should I put a GST line item on the invoice, but not pay it? Is this specifically for the entity I'm charging?

<comment><USER3> You will be assessed to pay tax on income above $18k if I remember correctly. That said on lower levels of income it's quite likely you're expenses will neutralise any tax obligations. E.g. Keep records of costs such as maintaining a home office, driving costs, phone internet etc. Id say get an accountant but if this is your total work for the year you might want to put the time in reading information on e-tax. Make sure you read about deductibles before you start now so you can keep records.

</comment></comment></comment><comment><USER4> You could engage a contract management agency to do your invoicing, and to deduct your tax, super etc commitments. Companies like Entity Solutions, ADAPS etc offer this service at either a flat or percentage rate, based on length of contract, rate of income etc. Some even bundle in an accountant at the end of the FY to do your tax for you. For a one-off gig it might be easier than setting up your own structure. The other consideration is Professional Indemnity/Public Liability insurance -(usually referred to as PI/PL) - you can get your own policy, or again there are agencies willing to bundle you under their cover for a flat or percentage rate. Do your research and don't work without insurance.

<comment><AUTHOR> Thanks, I was wondering about whether or not I would need insurance. Do you think it's necessary for providing a proof of concept module for an existing piece of software?

</comment></comment><comment><USER5> Yes, you need an ABN. You don't need a business name or anything. Just register as a sole trader - your "business" is just your name then.

You have to declare & pay personal income tax on the income that you earn (not company).

GST is something you need to register for, however you do not need to charge or pay GST if you earn under a certain amount (from memory it is $75k).</comment>


135 years ago, today, Graham Bell made his first phone call - <AUTHOR> http://en.wikipedia.org/wiki/Alexander_Graham_Bell#Telephone

<comment><USER2> Isn't it amazing to go from the first phone call to communicating with machines on the edge of the solar system in not much more than a century?

What would Bell make of the Internet, I wonder?</comment>


Goodbye autoload  - <AUTHOR> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/41149 <comment><USER2> Including "[Ruby]" in the title would be nice.

</comment><comment><USER3> Note that this is from Nov 2011. Since then there's been a massive discussion about handling requires in a multi-thread environment. A lot of the problems with autoload comes from the fact that requiring isn't thread-safe, so if that gets fixed (global lock around requiring files) autoload won't be that bad anymore and might live on for another release.

</comment><comment><USER4> It is threadsafe in jruby (as of 1.6.6)[1]. It is a decent feature, and it would be great if matz would reconsider.

[1] <http://jira.codehaus.org/browse/JRUBY-3194></comment>


Ask HN: Are you using A.I. to solve anything around COVID-19?Where can I find it - <AUTHOR> <comment><USER2> People are for real -- But there's also a majority doing "AI" for COVID19 only to plaster on their resumes (Using CNNs or some other basic algos to detect COVID isn't that hard)

<comment><AUTHOR> Yeah, I get that. I was planning on exploring around drug discovery if at all for COVID. Not that I understand the drugs part of it, but data exploration around past virus + vaccines might help get some insights.

</comment></comment><comment><AUTHOR> I was basically looking at CORD-19 and open datasets around COVID, so was wondering if any of you are already working on anything, I would love to checkout your work. Thanks in advance!

\- Fellow Nerd</comment>


Final Startup School Speaker List (Evan and Biz now coming) - <AUTHOR> http://www.startupschool.org/speakers.html

<comment><USER2> Will the event streamed live for people who cannot make it there?

<comment><USER3> Looks like it- <http://www.justin.tv/startupschool>

</comment></comment><comment><USER4> I'm really looking forward to it. What a great line-up! It's an honor to be one of the speakers.

Anyone have any suggestions for topics they'd like me to address? I'll be incorporating a lot of Q&A into my talk, but I can seed the discussion with thoughts on a variety of topics. Let me know. Thanks.

<comment><USER5> It's also an honor to be one of the attendees. Really looking forward to your talk and hopefully meeting you too, Jason.

Many of us will probably never get into an accelerator or attract funding, but we are more than capable of starting great businesses funded by our customers. I think you may be best positioned to address our situation.

Last year, DHH's talk about the Fortune 5 Million resonated the most for me. I'd love to hear more along those lines.

Many of us have read "Getting Real" and your blog, but are always thirsty for more. Bootstrappers would love to hear what's worked best for you (and what didn't work so well) regarding marketing, development, scaling, and deployment.

I bet you have lots of great lessons to share. Looking forward to hearing them.

</comment></comment><comment><USER6> This is a very impressive list. I heard that previous events have all been great. I'm really excited to meet many of you.

I wonder how many of the Startup School attendees, like us, also apply for Y-Combinator this year?

<comment><USER7> If you haven't seen them yet, here are the videos from 2008: <http://www.omnisio.com/startupschool08>

<comment><USER8> Some of those videos aren't available :(

<comment><USER9> <http://www.youtube.com/user/startupschool#p/u>

</comment></comment></comment></comment><comment><USER10> I look forward to learning and exchanging ideas.

</comment><comment><USER11> PG: What are you going to talk about this time?

<comment><USER12> I don't think there's any value in killing the pleasant surprise.

<comment><USER11> It would be a pleasant surprise right now :-)

</comment></comment></comment><comment><USER13> What time does the whole event end?

</comment><comment><USER14> I'm looking forward to it.</comment>