Re: [dev] Let's talk about Go, baby
On Sun, Jan 27, 2019 at 3:57 AM Anselm Garbe wrote: > I > wouldn't recommend the cgo approach at all ;) I came to that > conclusion almost 10 years ago already, when some people started > writing WMs with Xlib in Go (cgo'ed xlib.go or whatever it was called > at the time) and realized that it sucks. Indeed, CGO is not a "simple" solution. I too once had to write a LevelDB interface to Go, and it wasn't a pleasant experience... On the other side Rust's solution is a little bit simpler in this regard, and as a bonus, it already includes a library `libc` which exposes everything the native C library has to offer, therefore calling a `libc` function is hassle free. However to the date, except Rust's approach, I can't say I've seen any language that handles nicely the C interfacing, most solutions resembling Java JNI's as you've mentioned. And still on this topic, has anyone programmed in Erlang, and wanted to interact with the OS? I ask because they have two ways, one the JNI way, and another very UNIX-y in nature: just write a C program (or whatever) and communicate with it over stdin/stdout. (I know that the second way isn't rocket science, but its used by default in a lot of places, which I can't say for any other programming language out there.) > > On the other hand comparing the two languages (as in syntax and > > features) is not enough; one has to look at their ecosystem, better > > said the tooling, documentation, and third-party libraries (and > > dependency management tooling). > > Yeah and these ecosystems are actually something I pretty much > dislike, specifically in Go as well. It really feels like a autocratic > environment. I really prefer how 'free', diverse and lean the C > ecosystem is. Only ecosystem is probably which compiler and which > target you wanna use. Some people might be inclined with Rusts or Go's > readymade environments, but it feels too much like a JDK to me (sorry > for the comparison). My issue with C-s ecosystem, which contains only the compiler and linker, is how people manage library dependencies? Sure you install these libraries via the package manager (hoping that the same library version, or compatible) is available in other distributions / OS's, however how does one handle: * libraries that aren't available in the package manager? (many projects just embed these libraries;) * how to deploy such applications when on the target one doesn't have `root` rights and the application requires some library which isn't installed? (I remember writing wrapper scripts which `LD_LIBRARY_PATH`, or patching the executable to use `$ORIGIN/lib`;) > > * Go's approach (until lately) was, how to put it, "non-existent"; > > you would have a `src` folder where you've let `go get` checkout your > > dependencies at whatever version their `master` branch was at, hoping > > for the "best"; **there is no concept of version** (therefore there > > are a lot of competing "vendoring" tools;) > > * Rust's on the other hand went the Java / NPM / Ruby / Python way in > > providing a centralized repository, explicit versions, explicit > > dependencies, etc.; > > Go's approach does give you the freedom to invent version handling on > your side. I kind of prefer that there is no centralized or > recommended straightjacket for versioning or dependency management. > At leat I personally would probably dislike how it is mandated and > prefer my own way. But here is the issue: have you found a working solution for this version handling in Go? I'm still yet to find such a solution. In my case whenever I start a new Go project, I spend about 1-2 hours copy-pasting some wrapper scripts that allow me to have my `sources` folder, but then "reconstruct" the mandated `/pkg` folder structure... Go sure doesn't provide a straight-jacket for dependency handling, but it surely does provide one for your project structure... Therefore I would say in today's environment having a dependency manager is a must, and I would say that: * (to date) Go has a very primitive dependency manager which only identifies the required libraries and checks-out their master branch hoping for the best; (they are working for something better;) * Python has `pip`, `virtualenv` and one has to cobbler them together; however when the requirements are installed you don't have an automatic way to get exactly which libraries are installed, and most importantly at which version, so that your co-workers have exactly the same development environment; (they are too working on this;) * Ruby / NodeJS (npm) / Rust have a very complex dependency system which have both optional dependencies, development only dependencies, the "dependency version lock file" (which solves the previously mentioned item with Python); * Java has Maven which, besides the dependency management, is really a `make` replacement; Therefore, given how "suckless"-less many libraries are -- in fact many are just plain crazy, for example in the NodeJS w
Re: [dev] Let's talk about Go, baby
Hi, Guys, why bothering with an obvious troll fed on google go propaganda??? come on... -- Sylvain
Re: [dev] Let's talk about Go, baby
Hi Ciprian, On Sat, 26 Jan 2019 at 13:35, Ciprian Dorin Craciun wrote: > * I would skip C if it doesn't require too much OS-related > interaction; in fact if I do need OS interaction, Rust is a better > alternative than Go, due to Go's goroutine runtime which, as a > previous poster noticed, doesn't play nice with the standard C > library; When considering Go, it surely is a bad idea to incorporate any libc bypass. Either plain Go and using its own syscall abstraction inside or sticking to plain C altogether ;) If someone uses libpng or whatever from inside a Go program, the devil will be drumming. I wouldn't recommend the cgo approach at all ;) I came to that conclusion almost 10 years ago already, when some people started writing WMs with Xlib in Go (cgo'ed xlib.go or whatever it was called at the time) and realized that it sucks. The only comparison to cgo I have personal experience with is JNI -- it suffers almost the same issues, but has the advantage that the JVM is hooked ontop of C's runtime and syscall implementation, so there are no surprises by running into concurreny problem due to independent syscall abstractions in the same process concurring with each other. > On the other hand comparing the two languages (as in syntax and > features) is not enough; one has to look at their ecosystem, better > said the tooling, documentation, and third-party libraries (and > dependency management tooling). Yeah and these ecosystems are actually something I pretty much dislike, specifically in Go as well. It really feels like a autocratic environment. I really prefer how 'free', diverse and lean the C ecosystem is. Only ecosystem is probably which compiler and which target you wanna use. Some people might be inclined with Rusts or Go's readymade environments, but it feels too much like a JDK to me (sorry for the comparison). > * Go's approach (until lately) was, how to put it, "non-existent"; > you would have a `src` folder where you've let `go get` checkout your > dependencies at whatever version their `master` branch was at, hoping > for the "best"; **there is no concept of version** (therefore there > are a lot of competing "vendoring" tools;) > * Rust's on the other hand went the Java / NPM / Ruby / Python way in > providing a centralized repository, explicit versions, explicit > dependencies, etc.; Go's approach does give you the freedom to invent version handling on your side. I kind of prefer that there is no centralized or recommended straightjacket for versioning or dependency management. At leat I personally would probably dislike how it is mandated and prefer my own way. > (For example in Go, I'm yet to find a good way to fork a library, > patch it, publish it under my own GitHub account, and still be able to > use it without changing all the imports to the "forked" location...) Hmm, I don't really get what the problem is here. Just maintain all dependencies you rely on on your side and good is. Never rely on dependencies maintained by someone else. How would you prevent those dependencies to start behaving 'funny' at some point, if you don't maintain them? At least in my stali experiment I came to the conclusion, that this is the only way to do things right. You have to maintain *all* dependencies in your side, otherwise something will break sooner than later. > And lastly there is a hidden pitfall with Go, which Rust solves it > "better", in the case of high-performance use-cases: heap-based > allocation of what "seems" to be a stack-based allocation (especially > in the case of buffers). > > Go's compiler tries its best to use stack-based allocation, however it > throws the towel whenever it encounters a interface. For example say > you want to implement a simple tool that computes the > cryptographic-hash for the input stream. You'll just use the `Hash` > interface, declare a buffer of "enough" size, and loop through > read-hash. Unfortunately because we use the `Hash` interface Go's > compiler can't keep the buffer on stack, but instead it allocates it > on the heap. However one allocation is not that bad, unless you've > decided to declare the buffer inside the loop (just before the read), > instead of outside the loop; in the former case you'll end up with as > many allocations as there are iterations... In Rust on the other > hand, being explicit about allocation, you don't have to "hunt" for > such places in your code. Interesting example. This is why I like C more than golang, because I know exactly what happens. I can't hide the fact by some implicit language features how something is allocated and where. > > Besides this it's the hipster environment of Rust that is putting me > > off. > I am truly curious what contributes to this "hipster" perception? > (I myself find that the old web site was "better" than the current > "color-fest" site... However if you look past that I find it quite > "serious looking", or at least as "serious" as Go's ecosystem...) I don
[dev] a new suckless scheme interpreter
Here is a pretty complete and working scheme interpreter in 1600 lines of C. It was used to bootstrap a full scheme compiler. To use it in applications would probably require some extra hacking but that's what keeps it from getting bloated https://github.com/rain-1/single_cream/
Re: [dev] Let's talk about Go, baby
On Sat, Jan 26, 2019 at 9:46 PM Anselm Garbe wrote: > > What are your concerns about Rust? > > The language itself is certainly better than C++ or Java and avoided > many mistakes (like exceptions and going to far with OO). On the other > hand the typesystem isn't great and much more complex than golang's > approach. Although I follow this mailing list from the "shadows", I would like to contribute on the topic of Go and Rust as "saner" programming language alternatives. First of all I've programmed both in Go and Rust and, if I need a "native" executable, I can say this: * I'll resort to Go if it's a prototype / one-off project or if it is heavily concurrent; (although if I can get away with a Python script I'll do that;) * on the other hand I'll look towards or Rust if the project is more "involved" (i.e. more complex, or with high-performance requirements), but not too concurent; * I would never resort to C++ (which can easily be replaced by Rust); * I would skip C if it doesn't require too much OS-related interaction; in fact if I do need OS interaction, Rust is a better alternative than Go, due to Go's goroutine runtime which, as a previous poster noticed, doesn't play nice with the standard C library; On the other hand comparing the two languages (as in syntax and features) is not enough; one has to look at their ecosystem, better said the tooling, documentation, and third-party libraries (and dependency management tooling). I would like to touch especially on the third-party libraries and dependency management: * Go's approach (until lately) was, how to put it, "non-existent"; you would have a `src` folder where you've let `go get` checkout your dependencies at whatever version their `master` branch was at, hoping for the "best"; **there is no concept of version** (therefore there are a lot of competing "vendoring" tools;) * Rust's on the other hand went the Java / NPM / Ruby / Python way in providing a centralized repository, explicit versions, explicit dependencies, etc.; All in all, each has its strengths and weaknesses, and I would say Go's approach better resembles the UNIX world in which you'll have to maintain a coherent development environment. However in the current development landscape (with frequent chances) I am always amazed how the whole things still works... (For example in Go, I'm yet to find a good way to fork a library, patch it, publish it under my own GitHub account, and still be able to use it without changing all the imports to the "forked" location...) Regarding the type systems you can't actually compare them: Go is to Rust, as C is to C++. (However please take into account that I've developed a large-ish (for a single person) Rust-based project and **never** had a segmentation fault / null-pointer-exception. I can't say the same about Go.) And lastly there is a hidden pitfall with Go, which Rust solves it "better", in the case of high-performance use-cases: heap-based allocation of what "seems" to be a stack-based allocation (especially in the case of buffers). Go's compiler tries its best to use stack-based allocation, however it throws the towel whenever it encounters a interface. For example say you want to implement a simple tool that computes the cryptographic-hash for the input stream. You'll just use the `Hash` interface, declare a buffer of "enough" size, and loop through read-hash. Unfortunately because we use the `Hash` interface Go's compiler can't keep the buffer on stack, but instead it allocates it on the heap. However one allocation is not that bad, unless you've decided to declare the buffer inside the loop (just before the read), instead of outside the loop; in the former case you'll end up with as many allocations as there are iterations... In Rust on the other hand, being explicit about allocation, you don't have to "hunt" for such places in your code. (The previous is not a "made-up" story. I encountered this in a real project which involved writing a high-performance HTTP server in Go... The solution let's say was not that pretty...) > Besides this it's the hipster environment of Rust that is putting me > off. I am truly curious what contributes to this "hipster" perception? (I myself find that the old web site was "better" than the current "color-fest" site... However if you look past that I find it quite "serious looking", or at least as "serious" as Go's ecosystem...) > the main ideas that resulted into Go > are clearly footprints of Bell Labs. Sometimes I would say that perhaps in Go there is too much "Bell Labs" heritage... (For example the `Dial` function name... What's wrong with `Connect`?) > In Rust I do miss this influence > -- there seems more influence in Rust from the 'functional' > programming folks - which have also worsened Java dramatically since > the Java 6 days (lambdas, weird container/collection programming > paradigms etc.). I do acknowledge that sometimes "functional pipelines" see
Re: [dev] surf
Yeah, that is the problem. Thanks! Unfortunately, it seems that XQuartz doesn't support Retina displays properly. > On 26. Jan 2019, at 21:08, Greg Reagle wrote: > > On Sat, Jan 26, 2019, at 15:58, Igor Rubel wrote: >> I've just installed surf using MacPorts. >> >>> surf https://www.apple.com/ >>> Can't open default display >> >> How can one solve that? > > Hi. My guess, and it is just a wild guess because I don't even own an > Apple/Mac (although I have used them at work before), is that surf is > expecting an X server and that you are not running an X server. My > understanding is that MacOS's native/default display system in not X11. The > solution would be to install and run an X server. >
Re: [dev] surf
On Sat, Jan 26, 2019, at 15:58, Igor Rubel wrote: > I've just installed surf using MacPorts. > > > surf https://www.apple.com/ > > Can't open default display > > How can one solve that? Hi. My guess, and it is just a wild guess because I don't even own an Apple/Mac (although I have used them at work before), is that surf is expecting an X server and that you are not running an X server. My understanding is that MacOS's native/default display system in not X11. The solution would be to install and run an X server.
Re: [dev] surf
Do you have an X server running? Like xquartz? Run it from a terminal inside the environment of an X server. Ben > On Jan 26, 2019, at 12:50 PM, Igor Rubel wrote: > > Hello! > > I've just installed surf using MacPorts. > >> surf https://www.apple.com/ >> Can't open default display > > How can one solve that? > > > Regards, > > I. Rubel >
[dev] surf
Hello! I've just installed surf using MacPorts. > surf https://www.apple.com/ > Can't open default display How can one solve that? Regards, I. Rubel
Re: [dev] Let's talk about Go, baby
On Sat, 26 Jan 2019 at 06:27, Siraaj Khandkar wrote: > On Jan 25, 2019, at 20:18, Anselm Garbe wrote: > > C89 (or C99) clearly remains the preferred language for suckless > > software. However, when forced into typical day job developments to > > fund your well being, golang might actually be the sanest option on > > the table -- in order to avoid worse options such as Rust, Java, > > Kotlin, Scala, Ruby, C#, Swift etc. > > What are your concerns about Rust? The language itself is certainly better than C++ or Java and avoided many mistakes (like exceptions and going to far with OO). On the other hand the typesystem isn't great and much more complex than golang's approach. Also I dislike the distinction of raw pointers (unsafe) and various types of references. Besides this it's the hipster environment of Rust that is putting me off. In contrast - even if golang suffers the same to some degree and is heavily sponsored by Google, the main ideas that resulted into Go are clearly footprints of Bell Labs. In Rust I do miss this influence -- there seems more influence in Rust from the 'functional' programming folks - which have also worsened Java dramatically since the Java 6 days (lambdas, weird container/collection programming paradigms etc.). When looking at Rusts' experiemtal features such as future, intrinsics etc. I have the feeling that adopting it might lead to a big regret in the mid term, which is why I would stay away ;) Best regards, Anselm
Re: [dev] Let's talk about Go, baby
On Sat, 26 Jan 2019 at 03:55, Cág wrote: > Anselm Garbe wrote: > > However, when forced into typical day job developments to > > fund your well being, golang might actually be the sanest option on > > the table -- in order to avoid worse options such as Rust, Java, > > Kotlin, Scala, Ruby, C#, Swift etc. > Implying C is such an obscure language that can never pay your bills. No implication here. But demand for plain C developers is considerably lower these days with the exception of the embedded/IoT and kernel space. And often plain C is subsumed with C++ unfortunately, as it is widespread misleading that C++ includes C ;) -Anselm
[dev] [dmenu] [patch] Use slow path if stdin is a tty
Hi,
This is a simple patch to prevent from being locked by having dmenu
waiting on fgets to read from a tty with the keyboard already grabbed.
cheers
>From d579ee3221be1bd3fb5c1cf9c9bf55a2da68882c Mon Sep 17 00:00:00 2001
From: dok
Date: Sat, 26 Jan 2019 15:49:15 +0100
Subject: [PATCH] Use slow path if stdin is a tty
If stdin is a tty and dmenu is ran with the fast option then it's
impossible to close stdin because the keyboard is already grabbed.
---
dmenu.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/dmenu.c b/dmenu.c
index 5c835dd..6b8f51b 100644
--- a/dmenu.c
+++ b/dmenu.c
@@ -6,9 +6,7 @@
#include
#include
#include
-#ifdef __OpenBSD__
#include
-#endif
#include
#include
@@ -754,7 +752,7 @@ main(int argc, char *argv[])
die("pledge");
#endif
- if (fast) {
+ if (fast && !isatty(0)) {
grabkeyboard();
readstdin();
} else {
--
2.20.1
Re: [dev] Let's talk about Go, baby
On Jan 25, 2019, at 20:18, Anselm Garbe wrote: > >> On Fri, 25 Jan 2019 at 09:54, Nick wrote: >> Anybody else enjoying Go? Or hating it? Have I become lazy and >> trendy in my middle age? > > Nice try. > > C89 (or C99) clearly remains the preferred language for suckless > software. However, when forced into typical day job developments to > fund your well being, golang might actually be the sanest option on > the table -- in order to avoid worse options such as Rust, Java, > Kotlin, Scala, Ruby, C#, Swift etc. What are your concerns about Rust?
Re: [dev] Let's talk about Go, baby
Anselm Garbe wrote: However, when forced into typical day job developments to fund your well being, golang might actually be the sanest option on the table -- in order to avoid worse options such as Rust, Java, Kotlin, Scala, Ruby, C#, Swift etc. Implying C is such an obscure language that can never pay your bills. -- caóc
