Hello Go
medium.com
medium.com
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.
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.
Get-Content -Path TEXT.TXT | %{"$($_.ReadCount) $($_.Length) $($_.ToUpper())" }
For each line of text, this will print the line number, the length of the string, and the string converted into upper case.
PowerShell is very wordy, but very powerful.
I mean I still can't wrap my head around [ being a command / executable usable in conditions.
When scripting and writing documentation, full commandlet names are encouraged:
Get-ChildItem | Where-Object { $_.Name.Contains("evidence") } | Remove-Item
gci | ?{ $_.name.contains("evidence") } | ri
ls | ?{ $_.name.contains("evidence") } | rmWe need to start paying attention to this phenomenon.
nl(1)
cat file1 file2 > combined-file
sed {} file1 file2 > combined-file
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.
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 ..
Python is another example of a simple language + complex everything else
or at least a language that started simple
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.
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
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.
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....)
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.
What factors?
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?
There are other examples if you like.
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.
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.
What Java's limitations Go solves exactly?
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.
Java is also not interpreted for 20 years already. JIT compiler compiles jvm bytecode into machine code.
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.
AOT compilation is coming to Java.
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.
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.
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.
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.
What exactly prevented you to do this before?..
If I got a dollar for everytime someone had said that without any solid ground to stand on...
So let's do the authors work: What is the conclusion to be drawn here?
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.
I find it confusing when coroutines are interchanged between concurrency and parallelism.
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.
"Concurrency is not parallelism."
> Video: https://www.youtube.com/watch?v=PAAkCSZUG1c&t=3m42s
Chrome: Open Link in Incognito Window
FF: Open Link in New Private Window
These are the browsers I used generally.
Edit: I wasn't aware of the entry in HN's FAQ related to paywalls. See comments below.
> 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 also think it's quite absurd marking personal articles as 'pay to read'.
Anyhow the goal was to elicit a chuckle, so even if its not directly from the post I'll still count this as a success.
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.
My sense is that Medium isn't doing this, that they are instead just charging for content, which completely misses the point.
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.
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.
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.
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.