ceronman

I have a 4k thinkpad x1 carbon 7gen.

I would like to thank the Gnome community for this release! I can't wait to upgrade to Fedora 34 to use it.

I use Mac OS daily on my work computer and Gnome daily on my personal computer. Yes, I know there are a lot of Linux open source applications that are not very polished, but the quality in Gnome and its core applications is extremely high. There are even some things that Gnome does better than Mac OS.

Now, you might not like Gnome and that's perfectly fine. Fortunately, Linux is the land of choice and there is an alternative for every person. It baffles me to come here and read so much negativity! Come on! this is a big milestone for a community that has been working a lot to bring you something of quality for free! They have been doing this for decades already and they have put a lot of effort and love into this. How many open source projects fail to abandonment after just a few months?

Why is it that so many people in internet communities such as HN can't take a minute to appreciate the effort and instead the only thing that they are motivated to do is to nit-pick something and trash. Criticism is always welcome, there are even some appropriate channels to do it, but seriously why is this the only thing that you are able to say about a community driven product? Why is there only space for negativity? Why not a small "thanks" or "I liked that feature" before your criticism? They are bringing this thing for you for free, why can't you at least say something nice?

It seems to me that these are two orthogonal topics. One thing is how you represent tasks, either using OS threads or async tasks. And the other is how you structure concurrency. Maybe I'm missing something, but I think there is nothing preventing the use of those structured concurrency patterns using OS threads as the base for tasks. Then you get some nice benefits of doing this such as proper stack-traces and easier debugging.

The killer use case for async tasks is when you need hyper-concurrency, e.g. hundreds of thousands of concurrent tasks. In that case, as the article mentions, you can't use OS threads anymore. Of course there are some use cases requiring this level of concurrency, messaging servers come to my mind, but there are also many, many use cases were you need a lower level of concurrency, like a few hundred concurrent tasks max. In those cases I think using OS threads can work pretty well with less complexity.

I'm writing this from my Fedora laptop where Wayland works extremely well. I want to say thank you to all the developers behind it!

I know that the process of moving to Wayland has been slow and hard. It is definitely not an easy task. I know it's frustrating when something that used to work does not any more. I know the process is not complete and there are still a few things that might not work well. But for god sake, these people are volunteers. Stop bullying them with angry posts complaining about their work. You likely don't pay a penny for all this great software that you are using. If you think that X is better, just use it, and live with its unfixable issues. If you don't like distros moving to Wayland, contribute the packages to keep using X, maintain X, these guys are offering you the keys! Please stop shitposting about the work of people trying to make things better.

Apple breaks things all the time and they don't get half of the heat. And they charge a lot of money.

There is an important difference with Kotlin coroutines. In Kotlin you still have the problem of colored functions [1], those marked with `suspend` and the regular functions. You can't call suspend functions from regular functions and the world is divided in blocking and non blocking APIs (e.g Thread.sleep() vs delay()). And then you have to use things like `runBlocking` to bridge these two worlds.

If I understand correctly, Loom breaks that wall completely. You don't need to mark functions as `suspend`, the runtime is just smart enough to do the right thing. For example, if you call Thread.sleep() on a regular OS thread, then that will block, but if you run it on a light weight thread, it will suspend instead, allowing the runtime to use the OS thread for another task.

And there is one more thing: because Loom is implemented at the VM level, that means that when using Lightweight threads you get all the good things you typically get with regular threads: Proper stacktraces and native debugging and profiling support.

[1] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

I'm super impressed by those M1 CPUs. But it's so sad that the only way to get them is buying one of the few Apple options. I wish that Intel, AMD, Nvidia, Qualcomm et al catch up quickly. We really want competition in this field.

I think Starlark (formerly known as Skylark) [1] is a practical example of a Turing Incomplete language. As far as I know, this language doesn't allow recursion or even while loops. Only Python like for loops over bounded collections are allowed.

The language is very similar to Python so it's extremely easy to learn for many people.

This language is used as a configuration language for the Bazel build system [2]. Ensuring that scripts will run is a very nice property for configuration languages, giving a nice balance between flexibility and sanity.

I would love to have a similar configuration language but based on Clojure instead of Python.

[1] https://docs.bazel.build/versions/master/skylark/language.ht... [2] https://bazel.build/

I have been using Fedora with Wayland daily for over 7 months now and I it works pretty well.

I see that there are a lot of complains about Wayland here on HN. About input, screenshots and other stuff. But I have not experienced any of that. Input works perfectly and I have no problem with screenshots or screencasts.

Maybe it's that I have well supported hardware (Thinkpad X1C7) or is it something that I'm missing?

I was in a similar position a couple of years ago. I recommend the book "Core Java for the Impatient" by Cay Horstmann. The printed version is for Java 8 but there is a preview available for Java 11. It's a concise book but it covers all the important bits.

Regarding the "bite the bullet". I was also a bit afraid, but Java is a great language. Yes, it's a bit verbose but that's compensated by its amazing tooling, specially IntelliJ IDEA.

Workplace from Facebook.

The company I work for uses this for internal communication. Workplace is basically the same Facebook and Messenger, but tweaked for a private group of people.

The problem is that, because this is basically the same Facebook, it is designed to keep you "engaged". It uses all kinds of patterns to keep you addicted to your timeline and search for attention. Rather keeping you informed with the important topics, it distracts you with a lot of irrelevant stuff. The algorithm will always show you something that keeps you scrolling. Huge time waste.

The motto of this software is "Bring your company together". And it works exactly as Facebook's motto, "Bring the world closer together", in the sense that it does exactly the opposite. The software has all sorts of mechanisms to generate controversy. Because controversy is what ultimately drives more engagement. Reactions, memes, notifications. It makes you fight with your colleagues about silly things, and it makes it really easy to derail any sort of constructive conversation.

Imagine having to try a technical conversation in this platform and then people are allowed to "react" with an angry face or a silly animated GIF. No argumentation required. And those reactions will bring more reactions. And in those rare cases when some meaningful discussion actually happens, then the thread is quickly buried by the constant stream of new things.

If your company is considering this, avoid it like the plague.

Anecdotally, I've always preferred light mode. Specially for coding. First thing I do on a fresh OS install is to change the terminal to white background with black text. I definitely feel more eye strain on dark UIs.

I don't understand those who prefer Dark mode, but hey, if that's what you like, and it works for you, I'm all for having that choice on every program. Not all eyes are equal.

Although I read somewhere that weather Dark or Light background is better depends a lot on your environment. If you are in a very bright environment, next to big windows or intense artificial light, then Light is better. If you are in a darker environment then Dark is better. This matches my experience.

What I think it's definitely bad is constantly switching between Dark and Light. If I do that I get a headache very quickly. This makes Dark specially bad for me because even if I code in a Dark IDE, if I switch to the browser, the majority of websites use Light mode. And this switch causes me pain.

Yes this is exactly the one I was referring to. Thanks!

I once read a quote that was something like "You are only an expert in a given technology when you know when not to use it". Unfortunately I forgot the exact quote and the author. (If anyone knows please let me know).

This is such a nice quote that speaks a lot about what it means to be an experienced (senior) software engineer. Our field is such a dynamic one! New tools and techniques appear all the time.

It's easy to fall into the trap of thinking that newer tools are better. I think this is because in some areas of tech this is almost always true (e.g. hardware). But in software, new tools are techniques are rarely fully better, instead they just provide a different set of trade offs. Progress doesn't follow a linear pattern, it's more like a jagged line slowly trending upwards.

We think we are experienced because we know how to use new tools, but in reality we are only more experienced when we understand the trade offs and learn when the tools are really useful and when they are not.

A senior engineer knows when not to use micro services, when not to use SQL, when not to use static typing, when not to use React, when not to use Kubernetes, etc.

Junior engineers don't know these trade offs, they end up using sophisticated hammers for their screws. It doesn't mean that those hammers are bad or useless, they were just misused.

I tried WSL2 for about six months.

I'm really glad that MS is investing in this and it's an aspect that has been long neglected. If you're a developer, and unless you're using MS stack (.NET), the experience has been always subpar.

I have to agree with the author that the experience is not quite there yet. But a lot of progress has been done. And I hope the progress continues and maybe in the future I'll try it again.

For me there is not a single deal breaker, but it's just a thousand paper cuts. Removing those will take time. Some of the annoying things I encountered:

1. Overall slowness. It's not only startup, it's in general. Not only on heavy tasks like parallel compiling, but even for lightweight stuff, you immediately notice when you try a real linux.

2. Some config like setting up ssh-agent correctly are hard and different than a real linux. No idea why.

3. Windows Terminal development is quite fast, and sometimes things change or break. For instance, the background color of my terminal suddenly changed and I had no idea why. After some googling and modifying config, it was fixed.

4. The fact that it required to sign in for Windows Preview program. (I think this is not required anymore) but it was very annoying as it requires very long updates that require like a million reboots. No idea why Windows has to reboot so many times for a single update. Additionally, after every update there was always surprises. From the harmless Edge popping up from nowhere asking you to become default browser for the nth time, to some hardware misconfiguration. Nothing too bad, but annoying.

5. (This one very subjective of course) The windows UI overall is, how to say it, a mess. Font rendering is awful. The mix of old style UI with new style UI is horrible. Some settings will be in new style, some other settings will be in old style.

As I said, I might try again in the future. But now I switched to Fedora and I'm really really happy with Gnome 3 and good old real Linux. I still have the Windows partition just in case, but I haven't booted in a while.

I'm not that experienced with Go, but it seems to me that the equivalent Go code to

    var foo = await bar();

is

    foo := bar()

Go concurrency is much nicer because it doesn't have colored functions. You can use the same functions and library both synchronously and concurrently in millions of goroutines.

As others have pointed out, the big problem of async/await is that it splits the world in two kinds of functions that can't call each other.

For example, in Python you have this http client library called `requests`. It's very easy to use, but it is synchronous and you can't use it in when doing async/await. Instead you have to use a similar library called aiohttp. And it's like that for every single library or function doing any sort of IO, you need two versions of everything. Same thing happens in Node.js. You have `spawn` which is asynchronous and `spawnSync` which is synchronous. And so on.

And it doesn't stop with functions, this division goes across the language it self. For example in Python you have a `for` loop and an `async for` loop. Same in JS, you have `for` and `for await`. C# also has it's own `await forech` construct. It's like splitting the world for no reason.

The great advantage of Loom is that you don't need a parallel language, you can use the same http clients, database clients, filesystem libraries that you were using in a synchronous world, but now you will be able to use concurrently in millions of virtual threads.

As the article mentions, the whole reason why async/await was invented, is because doing concurrency with kernel threads is very expensive. They are slow to create and they use a lot of memory. Using Promises and an event loop you can run multiple concurrent operations in a single OS thread. This gives you the chance to achieve much more concurrency than running one operation per OS thread. The problem is that this changes the way you program a lot. Your code is not sequential anymore, your error handling is different, even some conditional operations are different. Async/await is just some syntactic sugar created to make this looks like the regular programming model. It makes the function calls look sequentials (by adding an `await` prefix), it makes the errors look like exceptions, it makes the for loops look like regular for loops. But this is just appearance. It's something that looks similar, but it's different, and that's why you can mix it with regular code.

Loom model is closer to Go and Erlang.

This is my favorite JVM project and I think it's going to be huge!

This model of concurrency is so much better than the async/await model used by many other languages. No more colored functions [1], or worse Completable<Future>, promises et al. Nice stacktraces, debuggers that work plus no need for thread pools anymore. I can't wait for this to be ready for production.

Only drawback seems to be when calling native code. I guess it's the same problem that Golang has. Good thing is that the Java ecosystem is not that dependent on native stuff, so I think it's a fair tradeoff to make.

[1] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

Yes, but this doesn't bother me at all. Getting used to the super key to switch windows is good enough.

Downloaded from Skype website, so I assume desktop Skype

I recently installed Fedora 32 and I am extremely happy with it. I was not a big fan of Gnome 3 for a long time, but now it seems that the project is mature enough. All the Gnome apps look gorgeous and very clean. The whole interface is responsive and quick.

I tried Windows 10 with WSL 2 for a few months, but the experience is far from being good. WSL is slow and the new Windows terminal needs a lot of polish.

Windows 10 it self is a subpar experience. The UI in general is a mess, all from explorer to control panel and settings. You often find windows and text that look awful on high dpi displays. And I'm not talking about third party apps, I'm talking about Windows itself and some MS apps like Skype. Windows also is not as responsive as I would like. Hitting the windows key to quickly open an app, which is the most repeated action by me, is sluggish.

The only reason I was using Windows was because my Thinkpad had issues with the microphone and speakers on Linux, but now that Fedora 32 is out with a new kernel, hardware works like a charm, so good byE Windows!

This is what he's replying to:

http://jasonrudolph.com/blog/2011/08/09/programming-achievem...

I love this kind of Books! In a much more general tone, there is "The Knowledge: How To Rebuild Our World After An Apocalypse" by Lewis Dartnell. This explains the first principles of a lot of things we take for granted in the modern world, from agriculture to food and clothing, medicine, chemistry and more.

This book about CS principles is a great complement to that!

Crafting Interpreters by Bob Nystrom is amazing:

https://www.craftinginterpreters.com/

Only caveat is that the book is not done, yet, but there is already a ton of content.

As a Java developer I'm really looking forward for Project Loom. I think it's a great approach that avoids the pitfalls of the two-colored functions approach.

However, Project Loom doesn't fit into the "zero cost abstraction" paradigm of rust. Project Loom requires quite a lot of support form the JVM runtime:

> The main technical mission in implementing continuations — and indeed, of this entire project — is adding to HotSpot the ability to capture, store and resume callstacks not as part of kernel threads. JNI stack frames will likely not be supported.

It also still require manual suspension so JIT compiled tight loops will likely still cause a problem.

Not for me. Got a 4K thinkpad and text does look quite bad. On Windows UI, on Chrome, everywhere.

In Python's standard library there is the unittest.mock module [1] which allows you to patch functions and methods. For example:

    with patch('requests.get', fake.get):
        definition = find_definition('testword')

[1] https://docs.python.org/3/library/unittest.mock.html

Use C.

Standardized since the 80s, it has had only minor, backwards compatible revisions in 99 and 11.

According to the TIOBE index, it's the second most popular language in the world. It works on almost any platform imaginable and it has decades of tooling available for it.

Of course it doesn't have any of the good new things developed recently, but if it's stability what you look for, then I don't see a better option.

I recently tried Firefox again and I liked a lot. Only drawback for me at the moment is the lack of hardware video decoding on Linux. I hope it arrives soon.

I'm writing this from my recently bought Thinkpad X1C7 after moving from a 2015 MPB. Here are some notes about my experience so far:

The hardware is fantastic. Build quality is great, the keyboard is great, the screen is great, the selection of ports is great. It's not cheap though, price is very close to an MBP.

The software part is not so great. I tried Windows for a short while, but it's just a disaster. It's slow and inconsistent. I tried WSL, but it feels so alpha for now.

So quickly I decided to move Ubuntu. Overall Ubuntu feels so much better than Windows, but the caveat is hardware support. Thinkpads supposedly have very good Linux support, however, the microphone and the fingerprint reader didn't work. After googling a lot I found a way of making the mic work by manually compiling a kernel. No solution for the fingerprint reader yet. And the volume controls don't work properly, there are a few workarounds, but none fixes the issue 100%.

Another issue on Linux is that none of the stable web browsers (Firefox, Chrome) have hardware video decoding enabled, so watching YouTube drains your battery. I'm now using a Chromium Beta build which seems to be the only alternative for now.

Using Linux requires you to google and apply a ton of small fixes to make some things better. Things like installing TLP to have decent battery life, hacking grub fonts so that they don't appear tiny on the 4k screen and stuff like that.

The hardware issues are quite frustrating, but I know those will be resolved at some point. My Thinkpad model is fairly new. The lesson here is: if you want Linux to work out of the box on your hardware, don't get the latest model.

On the positive side, I'm really loving Ubuntu and Gnome. I don't have plans to move back to Mac, even if they fix their crappy new keyboards. The fact that you can make Linux work the way you want is very rewarding even if it takes some time to google and hack around. But I understand that not everyone likes to do that.

For a mono-repo setup I find Bazel much better than those two. If you have few hundred projects or more, Maven is a pretty bad choice. Gradle is slightly better, but still much slower than Bazel.

But it's not just speed, Bazel does do true CI: you make a change in a a lib and then you can immediately compile and run tests on anything that depends on that directly or indirectly. I have not been able to do that with Gradle, forget about Maven.

Finally, if you use other languages, with shared artifact such as protobuf files, Bazel is simply amazing: change a proto file and recompile everything that depends on that on every language.