I would want to have something like Wikipedia that takes account of the user's context and knowledge to present transformed text that is customized for the user so it's easier to digest.
Could you point to where Linus said he doesn't like the design of systemd? AFAIK he's only disliked the binary logging (perhaps among a few other small things) but he liked it overall.
> I don't actually have any particularly strong opinions on systemd itself. I've had issues with some of the core developers that I think are much too cavalier about bugs and compatibility, and I think some of the design details are insane (I dislike the binary logs, for example), but those are details, not big issues. [1]
or
> I have to say, I don't really get the hatred of systemd. I think it improves a lot on the state of init, and no, I don't see myself getting into that whole area.
> Yeah, it may have a few odd corners here and there, and I'm sure you'll find things to despise. That happens in every project. I'm not a huge fan of the binary logging, for example. But that's just an example. I much prefer systemd's infrastructure for starting services over traditional init, and I think that's a much bigger design decision.
> Yeah, I've had some personality issues with some of the maintainers, but that's about how you handle bug reports and accept blame (or not) for when things go wrong. If people thought that meant that I dislike systemd, I will have to disappoint you guys. [2]
Both a quick Google away. To sum it up: Linus is okay with systemd. He just doesn't like its maintainers because they're straight up primadonnas. [3]
Their latest may well be that when logind do not find a functioning journald it will dump its output into /dev/kmsg, potentially swamping vital kernel output.
I remember seeing a video where he said he didn't care one way or the other about the technical merits and that it seemed good enough, but he did have serious concerns about the attitude of the developers about other people's technical issues when using it.
Given his stance against C++, he could use other languages or even write his own.
As someone that enjoys C++, in spite of its security flaws inherited from C, I see as a victory for the C++ community that a C++ hater like Linus is forced for pragmatic reasons as you say, to make use of it.
It can only serve one connection at a time, so if you're using it to serve a file download or have multiple users accessing it simultaneously it'll hang for all other clients.
No generics (parametric polymorphism), no algebraic data types. You should learn some Haskell or Ocaml even if you don't plan on using it in production. Go's type system is weak.
Edit: I don't think there's anything like type classes either but I'm not 100%.
I don't understand why all the ML-lovers have to bash Go for not being OCaml or Haskell or Rust. It's like bashing Python for not having static typing. Go is not one of those ML languages with a complicated type system. It has a simple type system. This is a feature for Go, just as dynamic typing is a feature for python. Neither is right or wrong or backwards. They're different design choices. If you don't like it, that's fine, don't use it. But it's not an inherently bad choice.
Yeah, I mainly want to get a feel for building a real system using a strict type system and algebraic data types. I've done some toys with them but nothing real yet.
I see the lack of algebraic data types and type classes as a feature, honestly. It means I can learn the things I need and start working in 2 days instead of in 2 weeks or a month.
I sometimes need generics, but not frequently enough to miss them.
You think Go's type system is weak. I think Haskell's type system is overcomplicated. So, there.
Even if it were true that it were overly complicated, that wouldn't change the fact that it's much more powerful than Go's.
“When I work at this system up to 12hrs a day, I’m profoundly uninterested in what user interface a novice user would prefer.” —Erik Naggum
Are you using visual basic because you could pick it up in 2 days instead of taking a month to learn Go?
It's easy to learn because it doesn't do anything interesting that you're not already familiar with. If you're not missing them, you're missing out on simple beautiful abstractions like map and filter. You're also missing out on type safe libraries for containers. It's not possible to write a generic container without casts to interface{}, which is a shame imo.
Bringing The Language Which Shall not Be Named to the discussion is a low blow. But I deserve it. My phrase about overcomplication was flamebaity and uncalled for, and I apologize.
> you're missing out on simple beautiful abstractions like map and filter
The thing is, in Go, those take almost as much space as a plain for loop.
I know, you will tell me "that's because Go's too verbose". I will grant that it's more verbose than Haskell.
But I am not doing maps and filters all the time in my code.
> It's not possible to write a generic container without casts to interface{}, which is a shame imo.
My point is that generic containers are the feature where generics are genuinely needed. And in those cases interface{} makes it possible. Not super-awesome, but possible. I actually like that the language doesn't bend over to fulfill something that looks almost like an edge case. It is not "programming with mathematics". It's still "moving bits around". But the bits can be moved with ease.
interface{} doesn't give you generics. The point of generics is to give you two distinct things:
1. You can write code that performs identical logic for a range of different data types, without having to know what they are.
2. That code can be checked for type safety.
interface{} gives you half of 1. You can write code that performs common logic and takes an interface{}, but then that code has to manually switch on type, or convert type before running.
Which gives you trouble with 2. Once you don't have a distinct type, you can't check for safety. All the compiler can do is check that an interface{} is passed in; which is a pretty weak guarantee. Meanwhile, in languages with generics, the you can write a generic method that uses the + operator and the compiler can check whether it works for numbers (OK), strings (OK), HTTP servers (uh oh, stop the bus!)...
Go's type system being weak is a factual statement. Haskell's type system being overcomplicated is an opinion.
One might prefer a weak type system over a strong type system, but that's a different discussion. The parent clearly expressed that he wants a static strong type system.
I'm not saying Go is a weakly typed language. I'm just saying that the statement "Go is a weakly typed language" is a factual statement that may be true or false. You were wrong in positing the claims "weakly typed" and "overcomplicated" as if they are somehow equally valid, because one is a factual claim and the other is an opinion.
In the most conventional definitions, Go is a strongly typed language. So this factual statement appears to be false.
As always, there is some confusion in this topic about dynamic typing vs static typing. There seems to be plenty of dynamic typing in Go, which in itself does not make its type system weak.
Go's type system being weak is a factual statement. Haskell's type system being overcomplicated is an opinion.
Calling one weak and the other overcomplicated are both completely subjective, biased statements.
And no, some random blog doesn't count as a citation: There are zero legitimate, agreed to sources that will back up your definition. Instead it's people painting broad strokes to bias the world towards their own beliefs.
Just as unreasonably I could say that Go has a Clarified Type System, versus the Conundrum Type System found in Haskell.
Are you aware that the notions 'weak' and 'strong' are actual terms used to describe type systems [1] ? Did you bother to look that up before going overboard and immediately accuse me of bias? I don't program in either Go or Haskell.
Now whether Go's type system actually has the property of 'weak'ness is very debatable. But whether it is true or false, it remains a factual statement.
You should read the first sentence in the page you linked. To make matters even worse, none of the "weak" notions even apply to Go, and I thought you were talking about something entirely different altogether given that Go is by zero definitions, colloquial or not, "weakly typed".
The post that set this off called Go's type system "weak". They were not saying that it was weakly typed.
It's a choice really: using a built-in exhaustive type system, or creating one manually with unit-tests. Unless you are happy with certain types of bugs.
One thing that Git does not do is to track files, for a good reason. Git was designed primarily to track content which means it can track code movement between files and be smarter about compression. It is not limited by architecture of a file system.
ZFS is not limited to your concept of a file system either. Any change is represented by the addition of a series of one or more blocks, which can be seen as direct equivalents to blobs in git. ZFS is copy-on-write, so you can always reference any particular content change regardless of what file it was called when you made it. Compression and deduplication are handled almost the exact same way as you'd expect.
