In case you're interested, word creation is a pretty interesting topic in linguistics. The wikipedia page on this -- they call it "conversion" [1] -- seems like a good starting off point for someone interested in the subject.
I'm sure this is going to increase the competition for these roles, but heads up that the `icims.com` links weren't working for me, so you may need to use https://careers.microsoft.com/us/en/job/590350/Software-Engi... , which seems like the same position.
Yes but initiated (and automatically suspended) based on a web request. Azure's is from (and billed from) container pull start until terminated (by you).
Aah, thanks for the clarification :) the top voted comments on this article now indicate that as well, so hopefully no one else will have the same confusion.
Re. a recommended alternative to quick and dirty bash scripts, do you think golang would do? I've barely dabbled with the language, but its default packaging (a single, static binary) and build system (`go build x`) seem well suited to rapid setup, deployment and testing, which is presumably what you'd want in this scenario.
Many people use go for such things. I simply don't like go, it's too crude (too C), and the packaging system is. Well, it's not Cargo.
But probably for deploy scripts, go with a static binary (hosted on, let's say your GitLab instance - using the GitLab HTTP API with a token to wget/curl it) is nigh unbeatable in end-to-end development and deployment time.
Aah, makes. I'm not a huge fan of it for similar reasons, but the appeal of a language that's quick, dirty, and relatively acceptable by coworkers is strong.
May I ask where you invested your time in learning Scala (e.g. reading the red book, studying type theory, syntax + stdlib + collections, etc.)? I found I could read simple Kotlin in a couple afternoons, and after a couple weekends, I felt pretty comfortable with it. The only difficult concepts to wrap your head around, I'd say, are type safe builders [1] and coroutines [2], but you certainly don't need to know those to be productive in the language.
To answer your specific question, however, if you're doing Android development it's worth it :) otherwise, it's up to you/your specific situation.
AFAIK, it's popular on Android because it provides e.g. Java 8 stream-like functionality without needing support for that baked into ART, which is something. Additionally, it supports compilation to Javascript [3] and early support for JVM-less execution ("native") [4]. No new abstractions or ideas, though; the language designers were aiming to make something that formalized current best practices, not lay down new ones.
Beyond that, it's nothing that you couldn't cobble together without the standard Guava + Commons + Lombok + Quasar/EASync etc. libraries and plugins that you'd use on every project written in Java, as well as that terseness you mentioned that makes people excited (see Kotlin data classes [1] vs Lombok data classes [2], if/try returns values and destructuring [5], coroutine support for lightweight threading and generators [6], null safety w/o optionals and smart casting, etc. [7]).
In my opinion, it's hard to know what value those features provide without actually trying them out yourself. If you want to be certain that you're not missing something, I'd suggest writing up a little script to try out some of its features.
edit: Just noticed the other responses on this thread. It's also very useful for starting fights with Scala developers, apparently.
Why does a window manager developer have to support specific graphics hardware in Wayland? Isn't abstracting away that kind of detail the first responsibility of a windowing system and/or framebuffer manager?
Wayland does not have the "window manager" concept. The compositor (which, for the lack of a better term, well, composites windows) implements the display server protocol as well. It creates and hands off surfaces to the clients, and those clients directly render their contents there. So it's somewhat akin to a window manager + some display server parts.
(Note: I have written very little Wayland-related code, and quite some time ago, so do not put too much faith in the explanation below).
Managing device-accessible surfaces is very obviously hardware-specific, so it was abstracted behind a number of mechanisms. One of these is the GBM API, which is implemented (classically) by everyone except NVIDIA, and is the API that sway is going to use.
NVIDIA's proprietary drivers do not support GBM, and NVIDIA is pushing for its own solution called EGLStream. EGLStream does solve several problems that GBM has, but it seems to me that what makes it most attractive to NVIDIA is that it is theirs (it is an open standard but has only one serious commercial implementation, on a single vendor's devices, so at this point it might as well be closed). If you are curious, there is a wider discussion on the topic here: https://lwn.net/Articles/703749/ .
This is very useful context, thanks. I hope things standardize quickly, because having to worry about whether your terminal emulator is compatible with your desktop environment is compatible with your graphics card and kernel seems like it'd be a huge step backward for the Linux desktop. Xorg has been something I haven't had to even think about for the better part of a decade now, and that's the way it should be.
As GP has written: sway is a compositor not a window manager. Wayland compositors are like X11 server + X11 window manager. They use kernel interfaces directly.
This [1] is the article they're citing. Note that a cursory search turns up similar claims from back in 2013; it might be worth waiting for someone with more experience and less bias to express their opinions before dumping your captcha-related stocks.
[1]: Conversion (word formation), https://en.wikipedia.org/wiki/Conversion_(word_formation)