freekh

Actually I have been thinking that I wouldn't mind doing some kind of civil service from time to time (at least). I often have some sort of 'next big idea' and enjoy spending time thinking about it while doing chores. If I could do it more often (even whole days/weeks) and if it was a more common thing to do, I think I would done more of it. On the other hand there's nothing really stopping me right now so maybe it just some hipster/hippie/retro wannabe fantasy I am tricking myself with :)

Edit: clarity

Oh, and I don't think I am afraid if something doesn't work (like node in your example or what not) with the barebone ubuntu on windows as long as the minimals: drivers, etc etc work... I am pretty used to tinkering and figuring out those things and I really enjoy that barebone speed. Willful waste makes woeful want, my mom always said :)

EDIT: idiom

Honestly: don't know... :) I suppose when looking for a new fancy (and expensive) gadget I would like it to work like I want it to out of the box. I can admit it is not a rational thing: I would have to install stuff either way, but it makes me _want_ it less... I know it doesn't make sense, but I believe that is it... :)

Me too, but to be honest I am not quite sure what I don't like about Mac OS X anymore. At work I got Arch with i3 which is (extremely) addictive, but at home I have Mac OS X (and I use for work too). I don't really have any specific problems (compared to Arch :) with Mac OS X. Still I was thinking to put Arch on it, but I don't want to tinker to be able to watch netflix after a long flight in that 'weird' network which the wifi driver version X.Y doesn't like :) Windows felt weird after getting used NIX-ish systems so it was out of the question.

I have tried to figure out why I want a non-mac for my laptop and concluded I just like change... :) I was almost settled on that dell xps with ubuntu, but if the Surface Books get thunderbolt 3 and this before the autumn I am pretty sure I can't resist anymore...

EDIT: typo

What? This is sick!? I can't wait for this to happen! Maybe I am gonna get one of those Surface Books after all... though I am gonna miss my i3 setup... I wonder if X (or wayland! or wayland...) can run as well... Native Emacs FTW :)

Not sure I can say I always write clean code but when I do, in non-trivial cases, I often start to write a comment, delete it and replace the code I wrote with something that does not need a comment... I suppose it only works for people who (think they) know(s) what good code looks like, but (I think) it works as a good guiding principle (for me).

Maybe worse is better also applies to editors :)

Pretty cool demo! Maybe they got inspired by what this guy did a while back with 3 kinects: https://www.youtube.com/watch?v=Ghgbycqb92c?

Just wrt the let/match/Ok/Err == ugly comment: I don't know Rust very well and I haven't looked very closely at the code in question, but why would Rust force you to wrap almost any function call with let/match/Ok/Err, though? I am assuming the issue at hand here is when you call function that returns a Result (if that's the name of the parent of Ok/Err)? Couldn't one let the return values 'flow up'? For example: if a function starts returning Results and you don't handle it on the level above, you start returning Results too... Also, I suppose there's ways of flattening results to avoid having nested Results (I would guess and_then does that based on its signature?)? In this scenario, you could argue that one now replaces match with map at every function call where you do not actually handle the Err and that this is ugly too, but the alternative is hoping that the caller happens to have read your source code (or have checked exceptions), which is, arguably (to be diplomatic), the case for unchecked-exceptions. Then what happens if you change the code and so on and so on...

This way lets you achieve something similar to checked-exceptions, and in addition to gain composability of Err (and the like), without adding another language construct (which a language without exceptions would have to do). Got a great deal of experience in other languages that does this, and it's worked out pretty good so far for at least for me once you get the hang of it (i.e. functional coding).

Where I am sitting, that would be a wise choice for Rust, at least if I am understanding it correctly, as it tries to be a safer alternative to other system languages. However, arguably (:), it is OK in dynamic languages or similar that aims trades in correctness for conciseness and, arguable (again :), speed of development to simply have unchecked-exceptions.

Also, it is possible I misunderstood your comment and/or how that code was ugly, in which case I hope the downvotes/replies won't be too harsh :)

EDIT: typo/clarity

I suppose this is slightly OT, but wrt to the Amish apprenticeship , I have started teaching my 15yo nephew programming and, as of late, I have been thinking about ways to get him to do a couple of months of apprenticeship with me. Right now, I can tell he's struggling even with pretty basic notions. I think it is partially due to him not being proficient enough in english (he speaks and writes norwegian, french and spanish fluently tho so I don't blame him), so googling around and finding answers seems hard for him. I dont live in the same country as him so I don't really know where it stops clicking for him (and he doesn't have a lot of 'screen time' to do research because of his parents, which is a good thing I suppose, but not for teaching him programming). Also he's more of an entrepreneur type than a hacker type so his patience gets in the way for him to deep dive: he just wants to see his project happen, he doesn't really care how (I suppose that's normal for a 15yo though). Therefore, getting him to read a book, or doing some structured course is not going to fly (I think). Also I am pretty strict trying to teach him the "'real'" ''"basics"'': in JavaScripts example functions, scoping, events, the DOM, - not just how to glue together stuff. He's the one that asked me to help him out though, and he also said he wanted to really understand it (which is why I am trying to be strict) so there's innate motivation driving him. He asked me how to do a autocomplete (a list that pops up under an input box), so that's what we're building. (Tips are welcome by the way :)

To get back on the topic: writing this got me thinking that, maybe in a 100 years from now, the Amish will be the turn-to lisp/fortran/c/cobol? consultants :)

EDIT: typos

Looks real cool. Congrats! Wonder if some of the utils like the shell would be a cool Rust project for me :)

Is it just me, or is the return missing in the `function` (or am _I_ missing something :)? Not important of course, just pointing it out...

Awesome news! Great initiative EPFL! :)

Puh! Wikipedia also states: 'Type safety is sometimes alternatively considered to be a property of a computer program rather than the language in which that program is written; that is, some languages have type-safe facilities that can be circumvented by programmers who adopt practices that exhibit poor type safety.'.

In (some) Java _programs_ you would circumvent modelling your domain correctly because it would be too cumbersome to use, therefore Java _programs_ tends to be less typesafe... I suppose that is how I use the term and heard it used in my everyday life, e.g. 'this code is more typesafe than that' and so on and so on...

I guess I should have made it more clear that this how I used the word 'typesafe' (though your definition of it is more correct) and underlined that I meant Scala/Java _programs_ not the language (nor the type system) itself.

Still, it is correct that type inference (rather obviously) doesn't have anything to do with type systems.

EDIT: language, clarity

Yup :) The comment is valid though: you don't get more type safety because of type inference. Thus saying it gets more typesafe is probably wrong...

Hmmm. Yes, you're right. Typesafe is probably the wrong word to describe this according to you and wikipedia :)

The problem I tried to describe though is how feasible/typical/normal? it is to catch more or less (type) errors on compile time... Like here, where I basically my point is that it is too hard to use Java's type system to it's full extent because it becomes too cumbersome to actually use it on the callsite.

I hope this goes through!

A while back, I was trying to explain in what ways Scala is more typesafe than Java for a friend (which was one argument to why I prefer Scala so much), and ended up realizing how important type inference is in this regard.

The reason was this: quite often type signatures correctly modelling a domain ends up being pretty hard to read. In a good and proper API, this happens in particular whenever something is composable and is, in fact, composed (if one can say that). I suppose one can say that, for Scala, it took a bit of time before people figured out how to do this properly, rather than just hacking the type system, but I feel that the ecosystem is more or less there now... YMMV though...

As an example: in something like Slick (a functional-relational mapper) in Scala you end up with monads to model your SQL query. One advantage this has is compile errors whenever you're doing something wrong (i.e. more typesafe), but the types that a SQL query representation ends up with will necessarily be pretty hard to read and practically impossible to write (you could have a Query of a long chain of other types for example if you're querying multiple columns). In this example, somebody writing the query might not care about the type of the query. They will care about what the query will end up returning when executed though. I suppose it will lead to trouble when you can't read the type signatures well enough and try to figure out the compiler error, but I reckon it's better to have an error, than to see it fail runtime (at least in my world :). It's easier and safer to do maintenance too, since the compiler and IDEs can know how things should work.

In any case, you could conclude that, in a statically compiled language where you do not have type inference, you'll end up trading in preciseness in the model of the domain, in order to have readable code from the callsite. In turn, this leads to less typesafe code.

One challenge that Java will have even when implementing this though, is how to move the entire ecosystem to something that is indeed more typesafe. This only works if the APIs are doing this right.

EDIT: typos, language and less parens

Maybe it was valueclasses you heard were not possible on the jvm? I think those are indeed possible on the CLR but not on the jvm. PS: yes I know scala has value classes, but sometimes those have to be instantiated.

Parallel? :P

Wow! This is truly incredible!

Wow! This is incredible!

Is Rust Postgres async?

Was expecting something more than this from Apple - the vision seems to be the same as what google had for google wear. Hardware wise it is not much of an increment either (my opinion only of course). Then again, I didn't really get excited over the iPad either and that was a huge success.

Setting that expectation aside, I would be fine with something simpler if it:

- it was classy looking: thin and round, steel and real/sapphire glass - ideally something that looks like one of those simple swiss clocks from the 1960s

- had an e-ink screen

- had a gps, which I can turn on and off

- had bluetooth notifications in case my phone is near

- had bluetooth audio support; and

- had spotify support. And here I mean that I want to be able to play music which has been synced to my watch over bluetooth, a cable or while docked.

- had heart-rate monitor would also be a plus of course.

- has enough battery for at least about a week, unless I am using the gps (for 2-3 hours), in which case it is fine if I have to charge it afterwards.

Want to use it as a regular watch (with the occasional message/calendar notification and perhaps even daily weather updates), and as a music player and as a gps for when I am running/biking.

Pebble almost have it, but their watches are way too ugly (my view only of course), too large for my wrists (so says my partner at least) and they don't have the extras that would make me really want one. I guess Spotify would have to be a partner as well, but I have Spotify on my radio so I guess it is only a small step to something like this as well.

Should be possible with todays technology though I am not really into HW. In terms of processor-power it really only needs to keep track of time, draw the watch face every second, draw the notifications/menu/..., handle user input (could be buttons not capacitive) and play music (which probably is the most resource intensive thing, but an easy match for any modern SOC). So for processing, battery shouldn't be a problem. An e-ink screen is thin and does not require much power either. Bluetooth 4 LE chipsets are very power friendly I think, so I would imagine that should be fine as well. They are also fast enough (1 mbp/s) for syncing notifications and even for the occasional sound track sync (I don't mind waiting 5-10 minutes for an album). The gps doesn't really have to give me directions, only log my position and would be used only when I am running/biking, and as I said, should be possible to switch it completely off.

The battery could be in the (detachable) wristband - I think I have seen quite thin and flexible polymer batteries around on the internet (though I am not sure if they are thin/flexible enough). Could also have different looks on the wristbands so you get one leathery-looking (for normal usage) and one plastic looking (for sports) like apple did (liked that part though it is hardly innovative).

SEEKING WORK

Full-stack, Scala, Play, Slick, builds (sbt)

Former Scala/Play trainer

Remote or near Stockholm, Sweden

Contact: my username at gmail dot com

Github: my username