Является ли Google Go безопасным для языка?


14

эта страница http://golang.org/doc/go_faq.html пишет:

хотя в Go есть статические типы, язык пытается заставить типы чувствовать себя легче, чем в типичных ОО-языках.

Так что мой вопрос в том, является ли он безопасно набранными с помощью обобщений (например, C #) или свободно набранными (например, javascript) или необязательными (например, строгий параметр в Vb.Net)


@JamesMcNellis означает, что в случае сбоя типа это может быть только потому, что я выполняю приведение типов (любое другое действие не должно вызывать исключение типа)
Pacerier

1
@ davidk01 Java скомпилирует (1 + "boo"), и Java довольно безопасный тип. Это выражение имеет определенный статический смысл, потому что язык перегружен + для объектов String языком, и все примитивные литералы могут быть подняты типом для обернутых объектов, которые затем могут быть превращены в строки.
Трикси Вольф

Ответы:


26

Тип безопасности не является черным или белым типом безопасности или нет. Это больше спектра, и некоторые языки могут быть более безопасными, чем другие (и наоборот). Тем не менее, я думаю, что вы думаете о C # против Javascript, скорее всего, статическая типизация (где проверка типов происходит во время компиляции) или динамическая типизация (где проверка типов происходит во время выполнения) - конечно, это о чем идет речь в FAQ.

Google Go имеет статическую типизацию, но из-за ряда функций он «кажется» динамически типизированным. Например, вам не нужно явно отмечать ваш класс как реализующий какие-либо интерфейсы. Если сигнатуры методов вашего класса совпадают с сигнатурами интерфейса, тогда ваш класс автоматически реализует этот интерфейс (разновидность утиной типизации). Это полезно для расширения встроенных классов и классов в сторонних библиотеках, потому что вы можете просто настроить интерфейс так, чтобы он соответствовал методам стороннего класса, и он автоматически его реализует.

Безопасность типов - это фактически другая «ось» системы типов. Например, C - это статически типизированный язык, который не является безопасным для типов - указатели позволяют вам делать практически все, что вам нравится, даже вещи, которые могут привести к сбою вашей программы. Javascript типизирован динамически, но также безопасен для типов: вы не можете выполнять операции, которые могут привести к сбою вашей программы. C # в основном безопасен для типов, но вы можете явно пометить области кода, которые unsafeделают и делают вещи, которые больше не являются безопасными для типов.

Google Go также безопасен для типов в том смысле, что вы не можете возиться с типами и приводить к сбою программы (нет прямого доступа к указателям).


Если вы не используете «небезопасный» пакет, в этом случае вы можете аварийно
завершить

Вы можете возиться с типами и иметь доступ к указателям. И да, вы можете легко разбить вашу программу, сделав это.
18:00

4

Это безопасно напечатано в том, что тип никогда не будет неправильно истолкован, но неправильный тип может вызвать панику в программе.


я не понимаю, значит ли это, что нетипичный безопасный код действительно может быть скомпилирован? (что невозможно в C #, если мы не используем динамику)
Pacerier

Выполнение утверждений типа по типу похоже на вызов метода для динамического типа
dan_waterworth

хорошо, так что вкратце у него нет такого типа безопасности c # позволяет?
Пейсер

Это происходит, если вы не делаете утверждения типа.
dan_waterworth

5
@Pacerier: Совершенно возможно запускать опечатки в C # без динамики: просто вставляйте приведение повсюду (как правило, это и есть утверждения типа).
sepp2k

-1

Гоу типа карты не потокобезопасный, она статический типизированные. Он также не имеет наследования типов, общего программирования, утверждений, перегрузки методов или арифметики указателей, и по уважительной причине.

Безопасность типов и безопасность памяти являются долгосрочными целями, здесь во лжи проблема.

Тип безопасности представляет накладные расходы, в килобайтах и ​​мегабайтах, что является приемлемым. Go разработан с MapReduce и «Большими данными», exobytes петабайт данных, что представляет проблемы производительности с безопасностью типов, проверка типов (бокс / распаковка) создает накладные расходы и отнимает циклы от обработки.

Безопасность типов может быть ограничивающей в подтипировании и полиморфизме, а также при типизации утки (приведение объекта к объекту), это создает опасности, а также пространство, в котором такие языки, как Go, приносят большую пользу. C ++ и Java не заменяются Go, это новый язык, помогающий распределенному программированию и массивно параллельной системе.

Большое утверждение Брюса Экеля - «Go имеет гораздо больше смысла для класса задач, которые C ++ изначально предназначался для решения», является дискуссионным. C ++ - очень эффективный язык, и реализация MapReduce в Boost очень эффективна.

Примитивы параллелизма - это будущее. Безопасность Тип всегда был очень спорный вопрос и Go, может быть, первый язык для решения этой проблемы в 20 лет, или с тех пор Алголь.


3
К сожалению, мне нужно больше репутации, чтобы -1 этот ответ. Безопасность типов - это не издержки, накладные расходы во время выполнения определенно не измеряются в байтах, и у go есть бокс / распаковка в смысле Java. Статическая типизация позволяет компилятору выполнять больше оптимизаций, чем динамически типизированный язык. Уменьшить карту нет ни здесь, ни там, то же самое с безопасностью потоков.
Элофф

Идея Голанга о том, что вы утверждаете типы с использованием пустого интерфейса в качестве общего шаблона, чтобы избежать реализации обобщений в качестве языковых возможностей, безусловно, не является чем-то, что я бы назвал «безопасным типом», и хотя это может сделать языковую спецификацию простой, когда проблема возникает (и будет), это оставляет сложность на тарелке человека, которого теперь оставляют решать проблему с помощью крана воздуховода, который Голанг называет функцией. Это, конечно, не похоже на язык, который был разработан за последние два десятилетия, потому что есть языки, которые гораздо лучше относятся к безопасности типов.
tsturzl
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.