Hacker Newsnew | comments | show | ask | jobs | submit | BonoboBoner's comments login

Interesting concept let me see his method..scrolling.. oh it is about marketing his app.

Unless you invest the money you get from the credit card, isnt his approach just min/maxing your cost to get money?


You published it? You should have gotten a "micro-docker"-like hashtag trend going and then pitch your idea to VCs. The main "Lighter than Docker" startup would be valued at around 5-7 billion right now.

-----


Just a quick interjection:

Something that one smart developer can do in 100 lines on any interpretter is never worth billions of dollars.

Someone who can do it, on the other hand, is certainly worth hundreds of thousands of dollars, annually.

Meanwhile, so many people continue to marvel at what can be done with an interpretter and a turing-complete language. Yet, the last thing we need is yet another turing complete language.

Unfortunately, the problem with turing machines, virtual or otherwise, is that they're so good at faihfully reduplicating themselves...

-----


"Something that one smart developer can do in 100 lines on any interpretter is never worth billions of dollars."

100 lines maybe not, but docker is pretty lightweight glue riding on existing technology that did most of the heavy lifting. The valuation IS lopsided because it sort of did a "name grab" around the underpinning technology (sort of like "AJAX" was "XMLHttpRequest") and packaged it in a way that made it a more useful (some) and more importantly, talked about in a way people could understand, mostly giving it a name and describing some common practices was what happened.

The original idea was definitely clever though, and it is getting people who didn't adopt immutable systems before to start to understand immutable systems, even if the future is not actually going to be Docker. Yet, Docker is getting the press versus the higher level software that needs to exist to drive Docker.

While this makes it very hard for other projects to get VC attention, I think that's maybe a good thing for them if they don't know it - you want to bootstrap if you can anyway, and I hope many of them do.

While this isn't a super robust implementation or anything, I think it's important to show that Docker is more or less glue around existing concepts, and that there's still room to make better things.

Don't get me wrong, immutable systems are GREAT. Docker deserves points for getting people to understand them, and the ideas of private registries and Dockerfiles (though also not original) are good parts. Microservices? Not really neccessary for most people, that's more of a human problem. It sort of conflates immutable with microservices and makes you hop out of the norm to do the basics, but ok, sure, that's somewhat like a celebrity actor advocating for environmental causes. Still a good thing.

But is it a giant leap forward? Not as much as people think, compared to AMI builds, and you see folks running Docker on top of EC2 in cases (yes, they boot faster - but AMIs gave you immutable and things like Packer allowed redistributable images; stacking images is kind of sketchy if you don't control them all). But it's enough to make people use them, and that's a win, and someday the management software for it may be smart enough to make it feel as easy and powerful as that (fingers crossed for ECS?).

The 100 liner at least has the advantage of reminding people when people say "Docker is great" they mostly mean "I like this immutable systems thing and describing systems in text", and the other properties of Docker, and reminds people that if they can do better and try to make a better thing, they should also still try.

-----


https://sandstorm.io/ ?

-----


> mobile is the predominant method of browsing for a huge number of sites all over the world.

That is not an excuse to give up on high information density on the desktop, just because your headings have to be ridicoulessly big for mobile.

-----


So true. I hate it when CMS administration areas are rewritten to be responsive and end up wasting a huge amount of space on the screen. A CMS admin area is a power user , that most people us on their computer.

Yet characteristics such as high information density and very accurate mouse interaction are all thrown out of the window, because of how the admin looks like on a phone.

How is it responsive to ALL devices, when mobile first enforces such restrictions on a design.

-----


Am I the only one that is not a fan of the new syntax? There is so much duplication and lack of clarity.

-----


Does it run Crysis? Apparently now Linux can.

-----


Thank you for making the mouse a thing in a keyboard driven world. As someone who grew up with gaming and learned IT as a result I never was able to fully give up on the mouse during my daily workflows. I admire people who can use VIM etc only by keyboard, but my muscle memory just says: mouse.

Thanks for establishing something that embraces this.

-----


You sound like a Windows admin living in a Linux/BSD world.

I struggle to do everything with Powershell, but almost everything I do has a mouse input. I use a gaming mouse for system administration - a Razer Naga Epic with the 12 thumb buttons.

They're a 3x4 array; I bind them to:

  Row One
  1. F5
  2. Up arrow
  3. F2
  Row Two
  4. Left arrow
  5. Down arrow
  6. Right arrow
  Row Three
  7. Tab
  8. Delete
  9. Backspace
  Row Four
  10. Enter
  11. Spacebar
  12. ESC
I can do the work of 2-3 admins, and I'm faster than poorly-written scripts.

-----


You should use whatever works for you but this strikes me as very bizarre I have to admit. I started out with a mouse as well and I can see this being something I would have attempted if I hadn't just put my head down and forced myself to get used to keeping my hands on the keyboard.

-----


As I said, it would be nice to be able to do everything with Powershell (or even Cygwin), but the every module isn't available for every version of Powershell, and the last 2 versions of Powershell don't work with some older (but still supported) versions of Windows.

Want to control you audio from Powershell? There's a cmdlet[1] for that. But it only works on Powershell 4.0 and higher. And PS 4.0 is only available on Win7, (not Win8) Win8.1, and Server 2008-2012.

So on my gaming PC, where I thought putting Win8 Enterprise from my MSDN would be a good idea, I can only change the volume via mouse, or keyboard volume buttons.

[1] https://github.com/cdhunt/WindowsAudioDevice-Powershell-Cmdl...

-----


You're not able to upgrade your gaming PC?

-----


Because of my infinite foresight in installing the Enterprise version, my upgrade path requires a full reinstall.

Everything works fine so it's not a very high priority - I'd rather be Minecrafting - either playing the game or adding to the server.

-----


Just want to echo the dead comment:

ossreality 6 minutes ago [dead]

lol, what are you talking about, this isn't mouse-enabled?

-----


I'm only slightly ashamed to admit I like using a mouse. I get that some people can work faster with all-keyboard controls. I use both. I also like GUIs for certain things. The only thing I don't like GUIs for is when there is some repetitive thing that I have to do 50 times a day and would require 3 or 4 clicks or menu selections - for those I'd always rather have a single command. Sometimes I make those into shell scripts that I can click with my mouse though!

-----


Might already be familiar with it, but if you aren't, you should check out sikuli script [1] for when you have a repetitive GUI task you have to perform that can't be directly scripted. I've used it to script some really complex workflows through GUI's

It's also just weird and interesting to program something to move through a GUI as fast as is possible

1: http://www.sikuli.org/

-----


Wow. Never heard of it, but this must be the most amazing software idea I've seen in a while. It's gonna be a playful day :P

-----


Hahah, awesome.

Yeah, getting the scripts to run and be robust is definitely an art sort of thing, but I've used it to create what amounts to a CLI's for legacy apps that you could only interface with through GUI's.

It's also fun to run across stuff like "Oh, the developer of this platform wasn't expecting me to be able to respond to a window within 20ms of it popping up on the screen."

Be interested to see what you think, if you have time to leave a comment

-----


Didn't have all the time I wanted today but played with 'hello world' samples and it's a fun new way of scripting for me. I don't have an immediate use for it but next time I feel something needs automation I'm definitely going to give it a go.

-----


That's great, we have an app that can't be tested with Selenium, Sikuli looks promising.

-----


> I'm only slightly ashamed to admit I like using a mouse.

I wish that you weren't even slightly ashamed. Anything can turn into a senseless religion, also supposed productivity.

-----


lol, someone's gonna be disappointed trying fpp for the first time

-----


How about an opt-in attribute to enable ordering then?

<table sortable >...</table>

-----


Is the compiler faster these days?

-----


Compilation speeds are largely dependent on the type of code you're writing. At London's Scala Exchange last year, Odersky claimed he can get 10k lines/second (10x slower than javac, but still not bad) out of scalac by writing simple imperative code, but libraries that make heavy use of the type system and implicit scope can be as slow as 1 line/minute.

I consider it fair to expect the compiler to be slower when it's doing more heavy lifting, but it would definitely be nice to see the exponential blow-up on the tail curbed in future.

edit: To clarify, the numbers above were what Odersky claimed; I haven't verified them. The 1 line/minute was claimed of trying to build Shapeless - I've never seen anything approaching that in the wild.

-----


> 1 line/minute

I get that that's an upper limit, but that's still pretty shocking. Is there an overarching reason for this type of performance? Examples of this style of code?

-----


Code with many implicit parameters and higher-kinded types is hard to compile, as the compiler needs to solve essentially a Prolog-ish unification problem. Scalaz is a popular library written largely in this style (e.g. [1]). (FWIW I've never seen 1 line/minute.)

[1] https://github.com/scalaz/scalaz/blob/series/7.2.x/core/src/...

-----


The one line per minute was observed when trying to compile a query over an HList backed record with more than 300 columns. The problem was a polynomial increase of the size of the implicit search tree. This is due to the way implicits are used in shapeless HList library. Slick has a different approach which is much faster, but slightly less general.

The gist is that once you have [edit: recursive] typeclasses or implicits your search can become arbitrarily large and slow. There's nothing that can be done about it by the compiler except arbitrarily pruning the search tree. Or otherwise put, you should factor in implicit search complexity when designing your libraries.

-----


OCaml and Haskell offer very similar functionalities and their compilation times are lightning fast.

The main reason why Scala is slow is because the compiler is poorly written. Take a look at the articles from Paul Phillips, one of the Typesafe cofounders who left the company in frustration, he's probably the person who knows scalac the best and he says the code base is basically hopeless.

Note that 1/3rd of Martin's presentation is about Dotty, and that's basically where he spends most of his time these days, he hardly contributes to Scala any more [1].

[1] https://twitter.com/odersky/status/574665768484339713

-----


I can't speak about OCaml, but Haskell doesn't have subtypes. That's where a lot of the complexity of Scala comes from as well as being a source of annoying bugs:

    def f(x: Int) = if (x % 2 == 0) { x } else { None }
(This compiles, but the type of `f` is not `f: Int => Option[Int]`.)

[edit: the bug is not in the scala compiler, the bug is in my code - I almost certainly did not want `f` to have type `Int => Any`. My phrasing, now edited, was misleading. ]

-----


That is not a bug. That is subtype inference working correctly. If you (mistakenly) expected the return type of f to be Option[Int], say so, and you'll get a compile time error telling you about your mistake:

scala> def f(x: Int): Option[Int] = if (x % 2 == 0) { x } else { None } <console>:7: error: type mismatch; found : Int required: Option[Int] def f(x: Int): Option[Int] = if (x % 2 == 0) { x } else { None }

-----


    scala> def f(x: Int) = if (x % 2 == 0) { x } else { None }
    f: (x: Int)Any
Which is expected. The only shared type between both branches of the `if` expression is `Any`.

-----


This is correct given Scala's limitation: the only common supertype between Int and Option is Any.

A language that supports union types (e.g. Ceylon) will type this expression as Int|Option[Int], which is as specific as you can get.

-----


I believe Ceylon will actually further refine Int | Option[Int] to simply Option[Int].

Option[Int] is simply an alias to the type Int | Null, so Int | Option[Int] would become Int | Int | Null after replacement, which simplifies to Int | Null since Int | Int is equivalent to just Int.

-----


> OCaml and Haskell offer very similar functionalities and their compilation times are lightning fast.

It took only one sentence to show that you never used OCaml or Haskell, so I'm not sure how serious the rest of your claims should be taken.

-----


OCaml compiles pretty fast, especially if you target bytecode. Haskell on the other hand... is still faster than Scala, but not "lightning fast".

-----


> OCaml compiles pretty fast, especially if you target bytecode.

Yes, but OCaml doesn't "offer very similar functionalities".

Haskell is quite a bit slower if you consider that you often have to compile not only your own code, but also the sources of your dependencies in the beginning. Additionally, you have to fight with Cabal, which tends to be very unpleasant due to the lack of any reasonable support for exotic things like "versions". Then you might discover hacks like "sandboxing". Hours not spent coding.

-----


Every turing-complete typesystem can take an unbounded time to compile. Scala is one of those languages with turing-complete typesystems.

-----


I'm not sure that's a sufficient explanation. Idris and Haskell (with extensions) also have Turing complete type systems. I've never seen either even approach performance like 1 line/minute in real code.

-----


It's quite easy to get extremely slow type inference in expressive typing systems. This code

let f0 = fun x -> ( x, x ) in let f1 = fun y -> f0( f0 y ) in let f2 = fun y -> f1( f1 y ) in let f3 = fun y -> f2( f2 y ) in let f4 = fun y -> f3( f3 y ) in let f5 = fun y -> f4( f4 y ) in f5 ( fun z -> z );;

took at least 3 months (!) to type-infer when I ran it on my 2008 MacBook using the standard Ocaml compiler. I have not tried since. Type inference algorithms have horrendous worst-case complexity. Fortunately that worst-case complexity usually doesn't matter in practise.

-----


I never seen 1 line/minute in Scala either, but that's not the point.

Theoretically, there is nothing stopping you from writing code which will never finish compiling if you have a Turing-complete typesystem.

-----


I've written a lot of Scala and I don't think I've seen anything as slow as even 1 line/second. Odersky was talking about Shapeless, which is an edge case in that it is a home for all the type-heavy calculations that scalac can compile but isn't currently optimised towards.

edit: reworded for clarity

-----


Computing a type level factorial can take more than 1 minute :)

-----


Here is a proof that the Scala type system is actually Turing complete:

https://michid.wordpress.com/2010/01/29/scala-type-level-enc...

I can't comment on the details, I'm more of of Clojure guy.

-----


I think you got that wrong by a factor of 10. I get between 500 and 1000 lines / sec on my laptop. It depends on the code style. The more straightforward the code the faster the compile. Still with incremental compilation it means I wait rarely more than a couple of seconds.

-----


Thanks Martin, unfortunately it's past the point where I can edit my original comment or I'd go back and fix it. As I recall you said it off-mike in Bill Venners' talk, otherwise I would have fact-checked it!

Anyway, details aside I thought it was a great illustration of the impact on compiler performance that code complexity can have.

-----


I do a lot of scala development and the compile times are fine since we have many projects but each project is fairly small (microservices). Incremental compilation is essential for reasonable compile times. We use maven with zinc.

-----


Apparently there is a faster incremental complier in sbt these days, but I can't seem to find any info online about how the compiler performance has changed over time.

I get the impression that compiler preformance is being worked on, and is improving over time.

-----


I didn't use scala in the older days, and started only recently, I used Java previously. And I'm quite ok with the times. Sometimes it does slow down a bit, but most of the time for most cases I think it's alright.

-----


Faster? Yes. Fast? No.

-----


If you ever need web scale, there is always nosql to fall back on Kappa

-----

More

Applications are open for YC Winter 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: