> Note: If you are on Microsoft Windows without a UNIX like environment you might want to re-evaluate your life choices at this moment.
Great sentence! However, Powershell got quite mature. `cat -n` is definetly something you will be able to do in Powershell with a similarly lengthy command.
Of course. Get-Content puts every line of text into the pipeline as a .Net String object with a few additional attributes added on, including ReadCount which is the line number. For example:
I'm neither a sh nor powershell guru, but, it kinda feels like that Powershell was intended more as a scripting language, less as a commandline language. sh / bash / etc commands are more terse, but harder to read if they're composed into a shell script.
I mean I still can't wrap my head around [ being a command / executable usable in conditions.
The terseness of Bash etc. is a tradeoff. "cat" is short for "concatenate." It's common use to list a single file is more the exploitation of an ambiguous API than a feature...concatenation of one file is like the sound of one hand clapping. I mean "to display the contents of a file use 'cat filename'" is an example of how *nix terseness makes understanding dependent on oral tradition rather than clear written communication. Even the man page doesn't describe using cat to display the contents of a single file [1]. It is only implied via the stdin example once a person understands the abstract relationship between the terminal and files.
Since shell languages invariably end up becoming scripting languages (see: Bourne shell and resulting nightmare), Powershell targets being a good tool for both purposes.
When scripting and writing documentation, full commandlet names are encouraged:
It’s like | perl -pe ‘$_=join(“ “, $., length, uc)’, but with brand new syntax, so cool. PS also can help you build any non-mingw/make/sh based dependency, if you find one.
I agree that nl is better for line numbering, but have you really never used cat with arguments? One of the most common use cases is for concatenating files:
cat file1 file2 > combined-file
There file1 and file2 are arguments. What do you use cat for?
File system performance seems great for me, but I've only been seriously using WSL for the last 6 months or so.
That being said, there are some major performance issues with how certain programs map memory and, as a result, things like Haskell are an absolute pain to use.
Perhaps I've never hit the problems that go solves? I just don't understand why I'd learn it when it offers nothing new or unique and feels even more clunky to work in than alternatives.
Specifically for me, I know enough poorly-typed lanagues that I want to be learning and using languages that offer me a good type system to express my program in, and not just jump through hoops to get things to work with no large benefit or reduction in code (and do when I get a chance).
I get coroutines are cool, but they don't really seem to solve the problems I have with concurrency. They feel like baked-in message queues.
Go is my favorite language; it started out seeming unimpressive, but the more I used it the more I came to appreciate it. For me the charm is it's a very simple yet well-chosen set of features, combined with a very high level of engineering quality. I find myself spending more time solving the problem at hand when using Go than ecosystem or language BS.
My 2-most used languages prior to Go were C++ and Python, for reference. I've played with things like Haskell, but never to a high degree of proficiency. I imagine if you are a fan of fancier, stronger type systems you might find Go unimpressive. (I've also done a lot of personal elisp, as an emacs addict....)
> they don’t really seem to solve the problems I have with concurrency. They feel like baked-in message queues.
You’re right about the baked in message queues. But that’s actually one of the key ingredients to designing simple scalable concurrent architectures. Once you get the message queues right, it factors away the concurrency primitives you normally would have to work with, such as critical sections and mutexes. This is demonstrated in the two references below.
The message queue design is simple and yet crucial to making the simple scalable designs. Alan Kay said “The key in making great and growable systems is much more to design how its modules communicate.”
The two references below explain how Go approaches concurrency in a way that makes it easier.
1. Don't communicate by sharing memory. Share memory by communicating.
2. There’s an amazing video with Rob Pike explaining how to produce concurrent designs that are simple and scale. Message queues is one of the 3 major components.
Go is mostly an answer to the problems of C. Sadly Go is not able to replace C as the introduction of the Garbage Collection makes it unsuiteable for many use cases of C. Besides that, Go has solved a lot of issues you had with C and as a result the code is much easier to read, write and understand.
At the same time, C is most likely not the only language in the universe and the fact that Go can not be used for all the use cases you can use C for, makes it even more important to compare it to other languages.
And while I like Go very much, I can understand that language wise, there are mightier wizards out there. But Go's strength is not the language itself. The language is just a cleaned up version of C which many people appreciate, because they know the C syntax already. But the real streght of Go is its enforced simplicity in syntax and file structure combined with a more or less complete, cross platform toolkit and a nice performing build and execution process. The builtin concurrent execution is a bonus on top of that.
How many compiled languages do you know that ship by default with a cross platform compiler and compile with the speed of Go?
well, the ecosystem is usually the answer, Go is a simple language, which attracted many developers, which resulted in a large ecosystem
but there is also the issue of complexity developer used Go to create complex systems, because it is a simple language, it allowed them to focus on the solution
while, complex systems, might be simpler if they were built using complex languages, it seems most developer prefer to build complex systems using simple languages, rather than build simple systems using complex languages
complexity doesn't disappear you can only spread it around, to make it more manageable .. using a simple language and moving complexity to the solution, seems like a trade off many are willing to make .. so this is not necessarily a bad thing .. its a preference
if Go starts adding complex features, many developers will move or chose another language ..
> it seems most developer prefer to build complex systems using simple languages, rather than build simple systems using complex languages
According to TIOBE, 1% of programmers are using Go, whilst 23% are using Java or C++.
If that is to be believed, developers do not appear to prefer simple languages. Or, Java and C++ are simple languages. Or, language selection is not based on preference.
well while many question TIOBE, i believe a lot fewer will question the empirical observation that C# and Java are bigger in the job market than C++
C# and Java both are a lot simpler than C++
i would even argue that by adding more features into Java and C#, a door was opened to PHP, Python, Ruby and now GO
i still stand by conclusion, that most developer prefer to move complexity to the solution and away from the language
and to be clear, i saying that this is a preference and taste issue, i am not saying that one is better than the other, i am not even saying that developers who prefer complex languages have bad taste ... it is just the way it is ... others have expressed it in more length
Simple languages like Go just put the burden of complexity on the shoulders of developers, that end up implementing ad-hoc solutions for what other languages support natively.
Hence how we end up with factory-factory classes, aspect oriented programming, patterns and stuff.
On Go's case, how we now have n variants of code generation libraries or multiple solutions to sort out dependencies and vendoring.
GoSpring and GoEE, similar to Java 1.2 days, should be quite interesting to see.
In my case the advantages were that it was statically-typed, faster, and had better concurrency than my go-to language at the time (Python). But in the end, while Go had many advantages, there were too many factors that made writing Go frustrating and discouraged me from using it.
So if you don't need Go, I think the only reason to try it would be because it happens to be trendy at the moment. And that doesn't seem like a sufficiently compelling reason on its own.
Go solves a very specific problem: the limitations of Python, CPP, and Java within Google. That's it. Google maintains control over the constructs within it in order to standardize its (Google's) code. When only Google's code matters, there's no rationale for things like including generics and or consensus standardization via ISO.
That's not to say Go is bad. There can be a lot of overlap between the type of problems Google designed Go to solve and the types of problems other people and organizations often have. A lot of people write systems code. A lot of people experience the limitations of Python, CPP, and Java. Not everyone of course. I mean to me, the Go ecosystem looks so much like an "enterprise" decision that it would be mocked by the very people using it if Go came from IBM or Oracle.
In terms of Google's problems, one of the implicit problems with Java is that it is another language in the code base and requires tooling and maintenance. Less directly, there is also Google's relationship with Oracle in the context of the ongoing copyright litigation. Again, Go exists to address Google's problems which may or may not have some overlap with those of another organization or any particular individual.
At the minimum, the verbosity problem. We can argue that any language is less verbose and more concise than Java.
Go is inherently not a OO language and has some excellent functional constructs which makes it easy to approach and solve certain set of problems whereas in Java you are forced to do the OO way even if the problem at hand does not require that way of solving stuffs.
Finally, Go compiles to machine code and I guess it should be way faster than Java.
I don't believe a single second that Java is more verbose than Go. It's just that Go hasn't been buried under layers and layers of EE ...yet. In fact the whole "if err!=nil" boilerplate is the very definition of verbosity.
> Go is inherently not a OO language
Everytime you use interfaces you are doing OOP. And there is no choice but using interfaces when dealing with streams, which is 99% of what people use Go for.
> has some excellent functional constructs
No more than the latest Java. In fact Java has something Go definitely doesn't have which is pretty useful for functional programming: generics.
> Finally, Go compiles to machine code and I guess it should be way faster than Java.
I have a hard time buying that EE cruft will creep into Go -- it specifically guards against inheritance/factory/DI hell by offering a unique type system (enforcement of clean interfaces between packages).
If you try to implement Java-like design patterns in Go then you're going to have a bad time -- personally this is one of its strengths.
> it specifically guards against inheritance/factory/DI hell by offering a unique type system
Many people, including Google engineers (https://github.com/google/guice) see DI as useful tool, not hell.
But nothing prevents you to write your java code without DI if you don't like it.
DI is unquestionably, heavily used in Google code, including in Go code bases.
Nonetheless, GPs point seems to be more along the lines that the type system helps avoid the horrible spaghetti of design patterns that many a Java project ails from. I'm not entirely sure about how much of that difference is a matter of culture vs. language and would love to see GP expand on their thoughts.
> I don't believe a single second that Java is more verbose than Go. It's just that Go hasn't been buried under layers and layers of EE ...yet. In fact the whole "if err!=nil" boilerplate is the very definition of verbosity.
You don't have to believe anything. But when I download JDK source I can clearly see tendency to over abstract since very early days when Java EE wasn't even a thing. I have worked on many Java projects where code was rejected because it did not use enough 'design patterns'.
As a Java programmer the main win of Go I see that now I can write a few hundred lines of straight forward Java code in a single file which does some work. In past it would be dozens of class files spread over ten packages and 5 xml config files.
Slightly OT, but I really want to learn golang but the amount of available resources[0] makes it quite overwhelming. I don't want to learn simple stuff but also want to go along the basics and learn good coding practice and design patterns. Any recommendations? What's your favorite resource for learning golang that helped you the most?
[0]: https://github.com/golang/go/wiki/Learn
Honestly the Tour of Go on their site is pretty good for just diving into it. You can probably just skim the first few chapters just to get familiar with the syntax.
That we should edit wikipedia and add "gopher sort" to bogo sort's list of names?
Had planned more, each section getting more silly than the previous including a tangent where it evolved into Hello as a Service but for now, to be continued.
Lets say there's one core, or "hardware thread". Then the scheduler has no choice but to stick them all on the same thread. They are running concurrently but not in parallel.
With more cores, Go can schedule them to run in parallel.
Rob Pike has a great talk on YouTube titled something like "Concurrency is not parallelism" on this exact thing.
Yup, and in fact, Go will try its best to keep ownership of a single (hardware) thread, spinning no-ops on it to avoid a context switch in some situation. (or something to that effect)
Because instead of one special function (swap) it needs two (swap and compare), and the two refer to the same data. So, put that data in a struct and give it methods.
> It's ok to post stories from sites with paywalls that have workarounds.
> In comments, it's ok to ask how to read an article and to help other users do so. But please don't post complaints about paywalls. Those are off topic.
For Medium, this means just blocking or deleting the cookie.
I know how to workaround the paywall by blocking or deleting the cookie :-) But I wasn't aware of this entry in HN's FAQ. I disagree, but if this is the rule on HN, then I'll follow it. Thanks for your reply.
>I also think it's quite absurd marking personal articles as 'pay to read'.
Well, it's not a news outlet. Most things on Medium is "personal articles". The whole idea is to have content authors get paid for their musings, rants, essays, etc.
The reason we pay news outlets for content is for their editorial function: curating writers, picking and choosing worthwhile topics, polishing the output, etc. This editorial function has no implicit value, but neither does the content; the value is in the combination of strong content with good editorial technique.
My sense is that Medium isn't doing this, that they are instead just charging for content, which completely misses the point.
>The reason we pay news outlets for content is for their editorial function: curating writers, picking and choosing worthwhile topics, polishing the output, etc. This editorial function has no implicit value, but neither does the content; the value is in the combination of strong content with good editorial technique.
I don't think that's explicitly and consciously the case. Today that everybody can publish on the web, such curation might be especially needed, and payed for (to remove the noise).
But back in the day, we paid news outlets because that was how we got articles -- whether they were curated or not was a secondary concern.
People couldn't just buy paper and bare printing costs, handle distribution deals etc and distribute their own articles. So if we wanted articles we had to buy them in newspaper/magazine form. Curation came with that -- not as an inherent demand.
>My sense is that Medium isn't doing this, that they are instead just charging for content, which completely misses the point.
Not really. The whole point of internet distrubution, what was hailed as revolutionary, was the ability to 'skip the gatekeeper', publish directly to everybody, and grow your own audience.
Medium is still kind of a middleman, but they're not a gatekeeper, in the sense that the editor in chief of an old news outlet was.
Their whole point is giving people direct access to any content writer they like. If someone doesn't care for one, they can read others. No curation necessary, not only because you can discover yourself which authors you like, but also because Medium has infinite space for articles -- not the 100-200 pages of a newspaper/magazine.
It's the same deal with independent musicians selling their wares directly.
I feel like you said lots of stuff that is true but isn't a response to my point.
You said that back in the day we paid for news because of scarcity due to the costs of printing and distribution. That's true, but I'm not talking about back in the day, I'm talking about now. The value in the business model now is in the combination of strong content and editorial.
You're saying that Medium is a middle-man but not a gatekeeper. That seems true to me, but what I'm saying is: that model doesn't make much sense. The majority of value provided by content middle-men is in doing gatekeeping well.
I'm very interested in direct-to-audience models for creators. But it isn't clear to me that that's what Medium is doing... Maybe it is, but it's not how I think about it (yet), so maybe they need to talk that up more.
>You said that back in the day we paid for news because of scarcity due to the costs of printing and distribution. That's true, but I'm not talking about back in the day, I'm talking about now.
Well, if you're talking about now, then one needs to add that today don't generally pay for most of our news content. We get it for free. Only select outlets managed to make paying work (e.g. Economist, NYT and a few more).
We do however, today, have systems for bypassing gatekeepers, curation, and paying content creators directly: from YouTube vloggers and Medium authors, to Patreon comic makers, artists and so on.
>that model doesn't make much sense. The majority of value provided by content middle-men is in doing gatekeeping well.
Well, the majority of people don't seem to care for those gatekeepers anymore. Medium had millions of viewers without gatekeeping. Facebook has billions of eyeballs hooked on reading whatever crap stories and content is put out there (I mean, aside from personal feed posts).
So while there might be value in gatekeepers and curation, that's not really a much better business model than what Medium does.
>So while there might be value in gatekeepers and curation, that's not really a much better business model than what Medium does.
To add to this, this was the misguided idea that news people had, thinking it would allow them to survey.
That "Sure, we might now have 10000000 sources of free content, but because of that people will value our curation that separates the wheat from the chuff more, and pay us for that" (or, in a variation of this, our "professionalism" and "knowledgable meta-analysis of news").
Turned out not to be the case. 90% of the people are totally fine with those 10000000 random sources of free news, thank you very much.
It has turned out to be the case. Selling the combination of good content and good editorial through the internet is a successful business model. It just isn't a broadly successful business model. It only works for a few prestigious brands. Charging for print content worked for a lot more smaller and more obscure outfits like local news organizations, but on the internet, everyone competes with everyone, and those outfits can't compete with the big names. I personally think that's a bummer, but it doesn't mean that pay-for-content-and-editorial is a dead business model, it has just changed to the kind of model where a few well-known companies accumulate all the benefit.
Of course there are other successful business models too, which you and your parent have mentioned a couple of:
You can sell ads against "10000000 random sources of free news". Lots of people are doing this, but most of the profit accrues to the big advertising sellers rather than the content creators, but still, it does work. I would personally rather be one of the companies with enough clout to go the pay-for-content-and-editorial route.
There is also direct-to-customer, like lots of people do with Patreon or some people do by running their own subscription services (like Stratechery or Sam Harris). This seems like a really good model to me, but I think it's still pretty nascent and hard to make money with.
But what I've been saying in this thread is: what model is Medium going for? They have a pay-wall, so it isn't the second model (free news), but they don't seem to be doing editorial so I don't think it's the first model, and they also don't seem to be aiming at their creators building a person-to-person following, so it doesn't seem like the third model either.
I'm just not sure where they fit in, is all I'm saying.
Great sentence! However, Powershell got quite mature. `cat -n` is definetly something you will be able to do in Powershell with a similarly lengthy command.