thibran

> If you have any thought or insight on how to get over that...

It depends with which concepts someone is already familiar. To me the only really new concept was the lifetime and ownership one, all others have just a different syntax plus here and there some extra goodies. As example, when I saw the match keyword I thought "cool, Rust has a keyword for guards".

I learned Rust shortly after 1.0 was released. The real obstacle for me to overcome was to build a mental concept of what Rust is. Something that wasn't really communicated while reading the first pre-release Rust book.

You have to read a lot to get an idea of Rust, it should be the other way around – a common mistake done by almost everyone teaching something. Ideally the first chapter would be a buzzword free, Rust code free chapter about how Rust works superficially and why there is a need for yet another computer language. It should describe what kind of tools and concepts in Rust exist and which problems they solve. This is better than introducing somewhat complicated concepts/tools and trying to explain how they fit into the big picture at the same time.

Ideally there would be an introduction like this:

A program needs a structure, variables, control flow, tools... blablabla... this leads to some common problems [some easy examples] and [this] are some concepts Rust invented/uses to solve them.

In later chapters the abstract ideas would be "converted into Rust". Also don't go too much into detail. I don't think for example that a representation of the memory layout of a vector helps much. At first I just need to know there is a thing where I can put objects of the same type into, how it is implemented is not that important for a beginner. It's better IMHO to know how to do something right, than why something is right. This reduces the mental burden in the beginning of the learning phase. The why is something that you learn over time – or maybe you are not that interested and skip it forever, also a valid thing to do.

Overall the Rust community does a stellar job providing so much help in so many different ways – /r/rust on Reddit is really awesome – thanks for the book and your open mind to ask for feedback.

Rust is for sure not an easy language (but compared with Haskell also not that hard/time consuming to learn). The major stumbling block seems to me is, that the syntax looks some kind of familiar, which tricks you into believing that knowledge-of-other-language applies, but in reality Rust is a completely different beast.

For me there was a gap between reading the Rust book and applying the knowledge. While reading I thought "that's easy" but later on "oh shit, the compiler complains all the time". If you make it past that point – which takes for most non-novice programmers around three weeks – then Rust becomes a very powerful tool to you.

You always have to "deal" with lifetimes. The rules are not that complicated once you understand them. It boils down to:

* An object can only have one owner.

* When giving a reference away from an object, the reference has a lifetime that makes sure the reference doesn't outlive the owner.

* You can either have one mutable reference >>or<< arbitrary read-only references.

* An owned object must be denoted mutable to be mutable, otherwise it is read-only.

The longer I use computers the more I think having an OS-core plus separated user-applications is the way to go. As user I don't care/think a lot about the core, it should just work. Apps should be totally isolated from the base system and be up-to-date. Updating the base should never impact apps, updating apps should never break the base system.

Right now I use openSUSE Tumbleweed[0] and Guix[1] for applications. This gives me an up-to-date OS with the ability to rollback OS updates (thanks to openSUSE snapper and btrfs). Guix is a functional package manager with rollback support & reproducible builds, which allows you to have multiple versions of the same library installed so that different applications can make use of them. The above combination solves a lot of problems traditional packaging systems have.

I also follow to some extend the Snap[2] packaging world. I like the security idea Snap brings to the table, but right now the snap thing is still work in progress.

[0]: https://en.opensuse.org/Portal:Tumbleweed

[1]: https://www.gnu.org/software/guix

[2]: https://www.ubuntu.com/desktop/snappy

Those CNN and BBC news are too often just a long wall of uninteresting text, therefor I banned them just now from my RSS reader.

Go with Java first. Kotlin fixes a lot of Java flaws and provides many Java-compatible solutions to those. Without knowing the flaws, you probably would have a hard time understanding the solutions.

Thanks a lot. Shells have so many features it's easy to miss one.

Does fish-shell have an equivalent for '<()'?

> How exactly would this treat e.g.

    yt $URL/somefile

> Would the variable still be expanded? Would an asterisk glob be?

No. Pure should mean don't do anything from here on, just pass the arguments to the function.

> If I _did_ want it to expand something even though the function is declared "pure", how would that work?

If expanding should be possible in a pure context, then maybe by using a known syntax like:

    yt ($URL)/somefile

Eshell expands Lisp code when using (lisp-code-here) which is kind of elegant. So when in a pure context, you would have to switch to expansion-mode by using curly braces.

I seriously considered using eshell (I love Lisp and Emacs dired-mode), but ended up continuing with Fish.

Since I use the non-graphical Emacs (emacs-nox), I can easily start dired-mode in terminal by writing: emacs .

# First Topic

The idea would be to be able to write something like this:

    function yt --pure
        youtube-dl $argv
    end

The parser should stop interpreting arguments after the yt function call and pass the args as strings to the function as before.

Then such a call would be possible: yt https://www.youtube.com/watch?v=mqma6GpM7vM

# Second Topic

I wrote a little utility [1] to quicker navigate on the file system. Right now I have two commands:

    m  [folder]  // goto highest ranked folder
    mm [folder]  // list results for folder-keyword

I would like to be able to write 'm foobar' and then press tab to get a vertical completion-list. When the user selects a completion-list-item I would like to pass the result-path to the cd command. Some time ago I tried to write such a completion, but failed – that's why I still use a separate mm-function to list search results.

[1]: https://github.com/thibran/maybe

I think JSON might be a good choice here because it would simplify the interaction with the completion program for advanced completions. Passing all those flags – mixed with some other shell function calls – to the 'complete' program is a bit cumbersome. My dream would be to have something like 'complete -c maybe --json [maybe-flag-to-generate-json-output]' and handle everything inside the application.

    {
      "fish_completion_version": 1,
      "header": "optional, completion header",
      "orientation": "vertical",
      "on_single_result": "optional, choose-item or display-item",
      "arguments": [
        {
          "item",
          "description",
          "optional return value, if empty return item"
        }],
      "item_handler": "optional, name of fish function to call on-item-chosen"
    }

I know JSON is not something you want to assemble in a script, but all programming languages have support for it and it's easy to use.

Thanks for the awesome fish shell – my beloved default.

For improvements here are two things I wish where possible in fish:

* The ability via a flag to say that a fish-function should not interpret passed function-arguments. This would enable us to pass e.g. URLs to a function without quote them, which is somewhat anointing right now. So this change would be a nice usability improvement.

* I would like to be able to write dynamic completions, containing of a key-value pair. The key should be displayed and if the user selects a completion-item, the corresponding value should be passed to a fish-function from which arbitrary actions could be triggered. Maybe supporting JSON input here would be nice too.

Emacs has already some kind of buttons and search fields, check out M-x "customize" to see some of them.

Did a small test by searching for "fish shell for loop"

* qwant.com did not return useful results at the top

* google.com did okay, but answer was behind the first link

* duckduckgo.com displayed the answer at the top of the page

Write down ideas...

I'm very skeptical that this would work, because I have ideas about all kinds of topics all the time. My list would be so crowded and mixed that it would be hard to prioritize anything. At the end I would see on paper that there is too much stuff going on in my head, something that I already know...

How To Survive A Robot Uprising: https://www.youtube.com/watch?v=-G3RoBHMu-o

Does the appearance of quantum computers mean that the effectiveness of programming languages becomes secondary and that ease-of-use/expressiveness will be the most valued trait?

Its 2017 and I wait for my computer. I wait on Linux, I wait on Windows. This sucks hard. It is still complicated to search for stuff or to morph data from one representation into another. The web is even worse. And lets not talk about sharing data or other computer-resources with others.

When looking back at what people invented in the 80s till today, I hardly see much progress.

I don't care much about how much RAM an application takes, I care about speed. The next big OS should have a golden rule, never make the user wait. That's the ultimate goal which all OS's fail to address today.

What I want in the end is most times some text which is layout in a visually pleasant way, some images, some videos. I thought multiple times about writing a program which would fetch all data from all the websites I'm interested in, messengers, email-accounts and so on and store them somewhere – so that I could later view them (with whatever program) without any fucking delay.

justforfunc - www.youtube.com/watch?v=ySy3sR1LFCQ

Publishing software – especially close source software – for Linux has always been, and still is, a huge pain. Beside all the nightmarish things you have to do to package something.

https://www.youtube.com/watch?v=5PmHRSeA2c8&feature=youtu.be...

There is a third option nobody seems to talk about `git merge --squash` (a squashed commit bundles commits into one commit). Which produces like `rebase` a linear commit history, but preserves the single commits.

> I really do think applications should try to zero-in on a few standard configuration file formats

This is a non-problem when you use a binary object, which can be represented/manipulated in all kind of ways. It would even be possible to expose the configuration in an arbitrarily format on a mount-point in the filesystem using FUSE https://en.wikipedia.org/wiki/Filesystem_in_Userspace

Interesting to read someone else ideas about that topic, which I though myself quite a lot about. The basic building block of a better desktop OS is IMHO – and as the OP wrote – a communication contract between capabilities and the glue (a.k.a apps). I don't think we would need that many capability-services to be able to build something useful (it doesn't even need to be efficient at first). For the start it might be enough to wrap existing tools and expose them and see if things work or not.

Maybe by starting to build command-line apps and see how good the idea works (cross-platform would be nice). I guess that the resulting system would have some similarities with RxJava, which allows to compose things together (get asynchronously A & B, then build C and send it to D if it contains not Foo).

If an app would talk to a data-service it would no longer have to know where the data is coming from or how it got there. This would allow to build a whole new kind of abstractions, e.g. data could be stored in the cloud and only downloaded to a local cache when frequently used, just to be later synced back to the cloud transparently (maybe even ahead of time because a local AI learned your usage patterns). I know that you can have such sync-things today, they are just complicated to setup, or cost a lot of money, or work only for specific things/applications, also they are often not accessible to normal users.

Knowing how to interact with the command-line gives advanced users superpowers. I think it is time to give those superpowers to normal users too. And no, learning how to use the command-line is not the way to go ;-)

A capability-services based OS could even come with a quite interesting monetization strategy by selling extra capabilities, like storage, async-computation or AI services, beside of selling applications.

Code examples are missing on the linked page. Having a website about a new car without any pictures would be strange, same applies to less known programming languages.

brain dump part 2

Now that I spend some time thinking about Android, other things popped back to my mind.

# back-stack - For all the time I spend in Android I wished there where a tool to log/see the current state of the back-stack. I tried hard to have a correct mind-model of it, but too often the app behaved differently, so I did fallback to try-and-error which consumed a lot of time and was very frustrating. App navigation is too hard, there are too many places where you specify navigation bits and too many tools/code paths to implement it. I would suggest to move all navigation/back-stack settings from the activity/manifest into >>one<< separate file for all screens of the app where all navigation settings are displayed and all possible navigation flows are modeled – with the possibility for Google to later add a graphical representation, like done for the xml layout preview. As a plus, transition effects could be specified in that file too. I assume this would be a looooooot of work :)

# A code coverage tool like it exists for Go is super helpful. It highlights lines that are tested and which are not, take a look at Visual Studio Code, with the Go extension installed: http://i.imgur.com/7mvRjLC.png

# Bundle/Intent data - Passing data to another activity is too cumbersome. Maybe this is something that could be solve by annotations. I always wrote factory methods like newMyActivity(...) to have the code all in one place, but writing such code always felt like a wast of time. Implementing Parcelable (the auto-generation function was god send), is jet another boilaplate code piece you have to update as soon as something changes, so it helps not that much.

# Resource folder - This is an old complain but it holds. If you have a medium to big size app your layout resource folder grows way too big. Because it is not possible to create sub-folders you have to invent ugly long names. Maybe a per-activity layout folder would help here, without introducing too many folder-layers (those could later be auto-merged into a single folder by a tool).

# App resources - It is difficult to know if your app uses too much resources. There are resource-viewers hidden somewhere in Android-Studio UI (you have to know that they exist). I would wish if I would get automatically a warning, if something exceeds a common threshold, so that I can try to be a better citizen without spending too much time there. Optimizing resources is something to do later, if there is ever time for it (depends on your boss). As dev it would be easy for me to tell a tool (maybe in the manifest.xml) that my app should have low/medium/high disk/network/memory usage, but observing if that assumption holds is time consuming. If e.g. I would classify the app as low disk usage, but for some reason the disk is accessed all time, there is probably something wrong. Telling devs that they consume to many resources might be an easy way to improve battery-duration for all of us -> it's hard to do something right, when you don't know that you do it wrong.

# The Context object - I struggled for quite some time to learn all the wrapper-objects that contain a Context and should therefor not be kept in memory. I don't know what kind of advice I would give a new dev to circumvent the context pitfall, this is unexpectedly a hard one.

# Image zoom - When working with images I was surprised to find out that there is no flag which allows the user to pinch-zoom into it. Implementing image pinch-zoom took way too many lines of code and was way more complicated than it should have been (I don't know what the current state of this problem is, maybe it got solved in the meantime). If not, there should be really a simple way to get this feature, maybe it would need a new image tag, like zoomable-image or so, but it should exist.

# Image-to-full-size - There is the common pattern, that you have an image and when touched, it should be displayed fullscreen. As far as I know you have to hand-write that code. Attached to this use-case is effective image loading, like loading only the pixels into ram you know can be displayed, or ignoring the alpha channel... This image handling util could be extended by having the possibility to load the next image by fling-pushing the current image to the left/right. Right now you write a lot of boilerplate code and maybe miss quite a lot of optimizations if you don't read enough about the topic.

# LayoutInflater - The inflate() method was for a long time confusing to me, because of the attachToRoot param. It should be easy, for some reason it is not. Do a google search about the topic, people are confused :)

# Custom views - For years there was not much information on how to create custom views. Than there appeared an official tutorials about how to extend the View class. I feel like the docs miss here something. When I was in the need of a custom view I always extended a view-group container, not the View class itself, because it's much simpler and gets the job done. There should probably be more information about that kind of custom view, the we-extend-the-view-class is the most complicated and maybe also a very rarely needed use-case (btw, I never used canvas to do anything). https://developer.android.com/training/custom-views/create-v...

# Menu items - Should probably be handled by a builder too, instead of a couple of callbacks (there are too many activity-callbacks, leading overall to spaghetti-code).

# Multi-layout - I wonder if Google ever thought about having a multi-layout-container, which would depending on your display size, displaying/hiding different views automatically. On the left a nav-pannel, mid the content and on the right, optional content pages. Such a setup feels like a classic setup. You can code it yourself, which would take ~3-6 classes and a lot of glue code (and documentation look-ups therefor). I wonder why there is not something like this already (maybe there is, and I have just missed it).

# Video-cast for experienced Android developers - For Go there is JustForFunc https://www.youtube.com/channel/UC_BzFbxG2za3bp5NRRRXJSw which hits a lot of nails. Watching a grand master Go dev doing a code-review or implement a little gem gives you more insights into his thoughts and tooling than 10 blog posts ever could. JustForFunc is pure awesome, entertaining and has a really good time-to-value rate. Even after years of experience with Go, I learned quite a lot watching Francesc Campoy code.

I should probably also let you know that I loved the code inspection features of Android Studio. They really did make a big difference and helped me to keep my code clean (especially the resource files). For the value that inspections give you, they are IMHO a bit to hidden in the UI. Also Dagger2 did help a lot. The difference between code without and with Dagger2 is like day and night. Maybe Dagger2 should be pushed more. Ah, and Kotlin is awesome, sooo much better than Java. </brain-dump>

For me it is always difficult to see the groups in the permission groups, I would prefer the user part would have one color, the group part another... identifying if there is a r or w is not the problem. There should maybe be also between the groups a space, just to make the output more readable. Otherwise I would like to not see the file creation/change date at all, since most times it adds no valuable information. To get more verbose output - with date info, there could be something like exa -ll (make the output more verbose if there are more -l args present).

Just some ideas, maybe you like some of them :)

Hi lukasb,

my last Android dev job was two years ago, I try my best to give you some feedback. Lets start with expectations. I expect that tasks performed by the majority of Android developers are actively supported by Google and are as easy as possible, with as few code lines as possible.

# REST - A lot of apps consume REST APIs. REST is almost the standard way to communicate with the outside world. Therefor the Android framework should include APIs to consume and send REST-requests and parse JSON easily (a support-rest lib would be nice, too). Depending for one of the main use-cases on third-party software is not okay.

# SQLite - Android really needs a support-sqlite library. Right now you have to use SQL features of the lowest supported api level, which means you are stuck in the past (if you want to stick with the default).

# Permissions - https://developer.android.com/training/permissions/requestin... - Handling permissions for older and new devices is a nightmare. I would expect to be able to declare the need for a certain permissions in – lets say 10 seconds – but figuring out how to get the permission bits right took fare longer (maybe 1 hour) and if I had to do it again, it would probably need again one hour. Instead of half a screen of boilerplate code and an activity-callback like onRequestPermissionsResult(), it would be nice if there where a PremissionBuilder, which would allow to easily setup permissions (spreading code all over the activity to do a basic thing is not that great).

# Cache - https://developer.android.com/topic/performance/graphics/cac... - Almost every dev needs & should cache data to improve app responsiveness and use the network less... To my knowledge there is no easy >>general<< caching mechanism in Android (maybe support-cache in the future ??). There is LruCache, but using it means almost writing all caching stuff yourself. Okay, there is Glide for images, which should probably be part of Android, but beside of that, void :). What would I expect? An API which lets you declare how something should be fetched, how many bytes/how long it should be in memory and if and how it should be saved to disk. Caching is such a general problem, I wonder why it hasn't been solved long time ago (we don't need the perfect solution, we need a solution – since it's such a common problem I don't feel like its my job as app-dev to solve it, I can, but I shouldn't do it).

# Effects/Transitions - During my Android years creating custom effects was very complicated and frustrating. Opening Qt Quick Designer for the first time and seeing how easy it is there, I was kind of shocked.

# Outdated information/blog posts - When researching a topic it is very easy to come along outdated knowledge. This is a real problem, since you don't know what you don't know. Sometimes I did things, just to learn later that there is a newer/better Android API. Since Google has not much control over it, I would suggest that Google keeps track of their own blog posts/articles and move them after some time into an archive or put a big (orange) banner on top of them, telling the reader that the content is outdated. Managing the produced textual output might be boring, but it seems to be necessary. I don't know if any company has ever done something like this... but, it would be great.

# Android takes up too much time & attention - Its difficult to describe the cause, but overall I felt like I did fight way too much with the framework, even after years of experience with it. I never had the time to care about things like battery saving APIs and such. It's sad and I wish I could have spend some more time following best-practices. Overall I think Android has to become simpler, I assume most people don't spend a huge amount of time learning all the bits of a given topic, they just want to get things done. Fare too often you have to know hell of a lot of things in Android, write a lot of code, like for RecyclerView with a custom Adapter (most people probably need a custom adapter, even the example is already cluttered) https://developer.android.com/training/material/lists-cards.... ... it's just too much code for such basic functionality.

# Android Studio UI ... has too many buttons, even for things like copy & paste, back & forward and may other buttons, I doubt those are use that often (we are experts, not computer novices). I know I can customize the UI, but still I wish the default was less overloaded :)

I acknowledge the huge amount of work Google did to make Android better over the years and things got really better. The introduction of the support library was stellar, thanks! </brain-dump>

Google should do this for regular Android APIs. The frequency you have to look up special-android-things is stunning –> disrupts your flow = very bad

There are way too many things you have to keep in your head on Android to get things right (https://developer.android.com/guide/components/images/activi...). The approach Google took here - do what ever you want, we won't tell/force you, is pure wrong (I'm a bit exaggerating, but still).

Developers wasted millions of hours of dev-time and therefor money to figuring out how to do basic things, like saving application state when the device is rotated or another app comes to foreground (testing state-changes is also complicated). There were complains about how state-saving is handled, but Google ignored them for many many years. Every platform has good and bad points, acknowledged, but not having a clear-line, a way how things should be done, is to me indecisive leadership and a very big mistake I would not have expected from Google.

Last AndroidIO things got better with the introduction of so called "Architecture Components" (among other things a SQLite ORM and guide how basic things should be done, finally). I wonder what took them so long.

The default "simple" console text editor "nano" should be replaced by the much more intuitive editor called "ne" (a less known gem).

I would love to see uniform-function-call-syntax.

Turning: func (f Foo) name() string

Into: func name(f Foo) string

Callable like this: f.name() or name(f)

Extending foreign structs from another package should be possible too, just without access to private fields.

Other than that, if-as-expression would be nice to have, too.